122 Cnug
122 Cnug
122 Cnug
User Guide
Release 12.2
Part No. E49154-10
November 2022
Oracle Incentive Compensation User Guide, Release 12.2
This software and related documentation are provided under a license agreement containing restrictions on
use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your
license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license,
transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse
engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is
prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If
you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on
behalf of the U.S. Government, then the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software,
any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are
"commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-
specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the
programs, including any operating system, integrated software, any programs installed on the hardware,
and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No
other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications.
It is not developed or intended for use in any inherently dangerous applications, including applications that
may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you
shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its
safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this
software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of
their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are
used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron,
the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro
Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information about content, products,
and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly
disclaim all warranties of any kind with respect to third-party content, products, and services unless
otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates
will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party
content, products, or services, except as set forth in an applicable agreement between you and Oracle.
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at
http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.
Oracle customers that have purchased support have access to electronic support through My Oracle Support.
For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.
com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.
Contents
Preface
iii
Building a Rules Hierarchy....................................................................................................... 3-5
iv
Define Payment Plans............................................................................................................... 5-8
Assign Payment Plans............................................................................................................. 5-10
Assigning a Payment Plan to a Role....................................................................................... 5-11
Assigning a Payment Plan to a Resource............................................................................... 5-12
7 Calculating Compensation
Overview of Calculating Compensation.................................................................................. 7-1
Two Types of Calculation.................................................................................................... 7-1
Two Modes of Calculation................................................................................................... 7-1
Phases of Calculation........................................................................................................... 7-2
v
Unprocessed and Failure Statuses....................................................................................... 7-3
The Calculation Process....................................................................................................... 7-4
Preparing for Calculation.......................................................................................................... 7-7
Rollup Summarized Transactions........................................................................................ 7-7
Accumulation and Splits in Multidimensional Rate Tables............................................... 7-10
Submitting Calculation........................................................................................................... 7-13
Resubmitting Calculation....................................................................................................... 7-17
Using Incremental Calculation............................................................................................... 7-17
The Notify Log........................................................................................................................ 7-20
Customizing the Notify Log Search........................................................................................ 7-20
Notification Log Triggering Events........................................................................................ 7-21
vi
Setting Up Payees...................................................................................................................... 9-2
Setting Up Resources for Team Compensation........................................................................ 9-3
10 Reports
Overview of Oracle Incentive Compensation Reports...........................................................10-1
Compensation Group Hierarchy Report.................................................................................10-2
Transaction Details Report..................................................................................................... 10-3
Attainment Summary.............................................................................................................. 10-3
Performance Detail Report...................................................................................................... 10-3
Commission Statement........................................................................................................... 10-3
Year To Date Summary........................................................................................................... 10-4
Earnings Statement Report......................................................................................................10-5
XML for Plan Visualization.................................................................................................... 10-5
Discoverer Workbooks............................................................................................................ 10-6
Calculation Batch Process Report.......................................................................................10-6
Compensation Plan Eligible Product Mapping.................................................................. 10-6
Resources Not Validated for Calculation........................................................................... 10-6
Resources with Pay Group Assignment Different than Compensation Plan Dates........... 10-7
Earnings Statement Report................................................................................................ 10-7
Transaction Details Report................................................................................................. 10-7
Formula Definitions........................................................................................................... 10-7
Resource Assignments Overview...................................................................................... 10-7
Transaction Status Report.................................................................................................. 10-7
vii
A Compensation Scenarios
Introduction.............................................................................................................................. A-1
Creating a Compensation Plan and Using the Plan Component Library............................ A-1
Scenario Management............................................................................................................... A-7
Common Compensation Scenarios Based on Formula Options..............................................A-9
Complex Compensation Scenarios......................................................................................... A-25
Compensation Scenarios Based on External Tables.............................................................. A-31
Glossary
Index
viii
Send Us Your Comments
Oracle welcomes customers' comments and suggestions on the quality and usefulness of this document.
Your feedback is important, and helps us to best meet your needs as a user of our products. For example:
• Are the implementation steps correct and complete?
• Did you understand the context of the procedures?
• Did you find any errors in the information?
• Does the structure of the information help you with your tasks?
• Do you need different information or graphics? If so, where, and in what format?
• Are the examples correct? Do you need more examples?
If you find any errors or have any other suggestions for improvement, then please tell us your name, the
name of the company who has licensed our products, the title and part number of the documentation and
the chapter, section, and page number (if available).
Note: Before sending us your comments, you might like to check that you have the latest version of the
document and if any concerns are already addressed. To do this, access the new Oracle E-Business Suite
Release Online Documentation CD available on My Oracle Support and www.oracle.com. It contains the
most current Documentation Library plus all documents revised or released recently.
Send your comments to us using the electronic mail address: appsdoc_us@oracle.com
Please give your name, address, electronic mail address, and telephone number (optional).
If you need assistance with Oracle software, then please contact your support representative or Oracle
Support Services.
If you require training or instruction in using Oracle software, then please contact your Oracle local office
and inquire about our Oracle University offerings. A list of Oracle offices is available on our Web site at
www.oracle.com.
ix
Preface
Intended Audience
Welcome to Release 12.2 of the Oracle Incentive Compensation User Guide.
This guide assumes you have a working knowledge of the following:
• The principles and customary practices of your business area.
• Oracle Self-Service Web Applications. To learn more about Oracle Self-Service Web
Applications, read the Oracle Self-Service Web Applications Implementation
Manual.
• The Oracle Applications graphical user interface. To learn more about the Oracle
Applications graphical user interface, read the Oracle E-Business Suite User's
Guide.
The Oracle Incentive Compensation User Guide contains the information you need to
understand and use Oracle Incentive Compensation.
See Related Information Sources on page xii for more Oracle E-Business Suite product
information.
Documentation Accessibility
For information about Oracle's commitment to accessibility, visit the Oracle
Accessibility Program website at http://www.oracle.com/pls/topic/lookup?
ctx=acc&id=docacc.
xi
Access to Oracle Support
Oracle customers that have purchased support have access to electronic support
through My Oracle Support. For information, visit http://www.oracle.
com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?
ctx=acc&id=trs if you are hearing impaired.
Structure
1 Introduction to Oracle Incentive Compensation
2 Oracle Incentive Compensation Command Center
3 Rules Library Management
4 Building Compensation Plans
5 Assigning Compensation Plans, Pay Groups, and Payment Plans
6 Collecting and Adjusting Transactions
7 Calculating Compensation
8 Payment with Payment Batches
9 Creating Resources, Roles and Groups
10 Reports
11 Sales Credit Allocation
A Compensation Scenarios
B Archive and Purge
C Compensation Plan Templates
Glossary
Integration Repository
The Oracle Integration Repository is a compilation of information about the service
endpoints exposed by the Oracle E-Business Suite of applications. It provides a
complete catalog of Oracle E-Business Suite's business service interfaces. The tool lets
users easily discover and deploy the appropriate business service interface for
integration with any system, application, or business partner.
The Oracle Integration Repository is shipped as part of the Oracle E-Business Suite. As
your instance is patched, the repository is automatically updated with content
appropriate for the precise revisions of interfaces in your environment.
xii
maintain information in an Oracle database. But if you use Oracle tools such as
SQL*Plus to modify Oracle E-Business Suite data, you risk destroying the integrity of
your data and you lose the ability to audit changes to your data.
Because Oracle E-Business Suite tables are interrelated, any change you make using an
Oracle E-Business Suite form can update many tables at once. But when you modify
Oracle E-Business Suite data using anything other than Oracle E-Business Suite, you
may change a row in one table without making corresponding changes in related tables.
If your tables get out of synchronization with each other, you risk retrieving erroneous
information and you risk unpredictable results throughout Oracle E-Business Suite.
When you use Oracle E-Business Suite to modify your data, Oracle E-Business Suite
automatically checks that your changes are valid. Oracle E-Business Suite also keeps
track of who changes information. If you enter information into database tables using
database tools, you may store invalid information. You also lose the ability to track who
has changed your information because SQL*Plus and other database tools do not keep a
record of changes.
xiii
1
Introduction to Oracle Incentive
Compensation
Overview
Sales jobs have a significant, measurable impact on the revenue of your business.
Keeping your employees motivated and happy is very important for the long-term
health of your enterprise. Oracle Incentive Compensation plays a part in determining
cash and other tangible rewards. You can use Oracle Incentive Compensation to pay
employees, partners, customers, and any nonemployee role.
A well-designed compensation plan directs employees to follow the goals your
company has set, while rewarding good performers and eliminating poor performers. It
effectively links performance to earnings. The goal is to create a positive sales culture
while controlling costs. For some companies, a fully featured application like Oracle
Incentive Compensation is better at managing incentive compensation than a system of
spreadsheets and manual accounting. If salespeople are confident that their
compensation plans are fair and accurate, then they can spend less time keeping track
of transactions and more time generating revenue.
Sales jobs vary tremendously within a company and an industry. For example, some
salespeople act as primary customer contacts and sell directly to them, and other types
of salespeople have an indirect relationship, or give support before or after the sale.
Good compensation plans compensate all of these employees fairly while costing the
company as little as possible.
• Product
• Market
• Customer
• Other
• Sales effectiveness: These measures can be based on product mix sold, customer
retention, price management, order size, and many other factors.
• Customer impact: These include customer satisfaction survey data and loyalty.
Compensation plans can have thresholds and maximums. A threshold is primarily used
to avoid paying compensation on the same sale, year after year. It may also indicate
management's establishment of a minimum performance level before compensation is
earned. Maximums, also known as caps, prevent overpayment of compensation.
You can use a commission matrix to resolve two conflicting objectives. This type of
arrangement pays more commission if the salesperson succeeds is meeting both goals.
For example, a salesperson may be asked to sell established products but also sell new
ones, or retain customers while adding new ones. Salespeople who are successful in
both objectives can earn a higher commission than if they achieve success in only one
objective. Oracle Incentive Compensation provides multidimensional rate tables to
accomplish this goal.
Use individual commission rates to even out commission payments when territories are
different sizes. Create the individual commission rate by dividing the salesperson's
target incentive amount by the unique quota sales volume for the territory.
Use bonus formulas if you want to pay for relative performance against a percent of
quota attainment rather than as a percent of actual sales production. Bonus formulas
can be step or rate type. The step type is more common, and is useful for equalizing
territories and providing varying payouts on quota performance. The rate type has no
gaps or cap, and is more like a commission program. It requires two calculation steps.
Bonus formulas can use hurdles, multipliers, and matrices.
Evaluate Performance
Executive management must periodically evaluate how the compensation plans are
performing and make adjustments to them so that the plans support your business
strategy. Managers should periodically evaluate their teams' performance, and adjust
the quotas or territories to maximize their salespeople's effectiveness. Reports in Oracle
Incentive Compensation enable managers to determine how well their salespeople are
performing. Other Oracle applications, such as Oracle Balanced Scorecard and Oracle
Financial Analyzer are also useful. These two applications can be ordered, but are not
shipped with Oracle Incentive Compensation.
For detailed information regarding the Incentive Compensation Administrator, see the
Oracle Incentive Compensation Implementation Guide.
The Plan Administrator:
• Creates classification rules and hierarchies
• Views reports
• Allocates credit
• Calculates commission
• Adjusts commission
The Compensation Analyst performs many of the jobs of the Compensation Manager,
but does not have permission to make assignments or create or pay payment batches.
Incentive Compensation Users (and their managers) can view reports relating to their
performance.
Some features of Oracle Incentive Compensation relate only to one or another of these
responsibilities, so this guide is designed to direct attention to sections that impact users
who need them. You can configure different responsibilities for your enterprise as
6 - Calculating Compensation
• Interval Settings: These are the time intervals used for Oracle Incentive
• Credit Types and Conversion Factors: These are used in the compensation plans
and reports.
See the Oracle Incentive Compensation Implementation Guide for complete implementation
information.
Plan Administrator
Plan Administrators create and maintain compensation plans, and the components of
those plans. They also create and maintain the rules and rule hierarchies used in
classification of transactions, account generation, and projected compensation.
Compensation plans are built in a modular way, which means you can reuse the plan
elements in other compensation plans. The Plan Administrator can control the effective
period of a plan or the plan elements by using start and end dates.
Oracle Incentive Compensation provides a 360-degree view of the compensation plans,
from which the Plan Administrator can create plans, create and view the plan elements,
and see to whom the plans are assigned and keep track of changes with a Notes history.
Compensation plans may be created using a top-down process. A compensation plan is
made up of plan elements, which themselves are created from formulas. Formulas are
sets of instructions that determine how the transaction information is used to calculate
the amount of compensation paid to a resource. Formulas are made from rate tables and
calculation expressions, which can be defined and reused within the application. Rate
tables are tabular information that establishes compensation percentage rates or fixed
amounts for different performance levels. Rate tables use rate dimensions, which define
its rate tiers by amount, percent, expression or string value. Calculation expressions are
either input or output expressions. Input expressions tell the application what
information to use from the transactions and how to match that information to the rate
table. Output expressions tell the application how much to pay resources.
Compensation plans are assigned to roles, and individual resources are assigned to a
role. You can customize a plan for an individual resource. For example, you might want
to pay a specific senior resource a special compensation rate based on unique
qualifications.
Plan Administrators are responsible for creating and managing the hierarchies of rules
in the Rules Library, which are used by Oracle Incentive Compensation to classify your
company's products and services, run transactions for compensation payment, and
generate accounts in General Ledger. The Rules Library also includes any other
hierarchies that you create, for example, customers.
If your enterprise decides to implement Credit Allocation, then the Plan Administrator
is responsible for setting up rules and rulesets for that process.
• Search Formulas
• Search Expressions
Scenarios
Scenarios are grouping of plans, or plan-role assignments, that allow you to compare
the compensation costs of a set of plans in a scenario with that of another scenario. So,
using scenario, you can compare results across different sets of data, and also across
different operating units.
• formulas
• rate tables
• rate dimensions
This focusses on the plans that you have created, and excludes plans that may have
been customized for a particular resource.
Individual resources can see only their own reports, but Incentive Compensation
Managers also have access to the reports of the resources that report to them. Managers
use the reports to monitor the performance of their directs.
Incentive Compensation Users can personalize the search and display options for their
reports, and can export them to a CSV file or publish them to Adobe PDF format using
XML Publisher.
• Minimize overpayment.
• Gain insight into the lifecycle of a transaction.
4. Process payments
5. Validate payments
• Paysheet Console: This dashboard provides visibility across payruns and supports
a flexible approval process. Financial directors and compensation analysts use this
dashboard to assess and review paysheets. You can see how paysheet processing is
progressing for current periods, review paysheets, and measure how outstanding
paysheets are assigned to analysts. Also use this dashboard to identify and drill into
unpaid commissions and examine unpaid transactions. See Paysheet Console
Dashboard, page 2-14 for more information.
• Refine results using recent refinements, failed job alerts, job clouds, or charts.
• Review job status charts to identify failed jobs, subsequent jobs affected, and the
context in the processing cycle.
You can analyze data using various metrics, charts, graphs, and tables.
From the Compensation Manager responsibility, navigate to the Recent Jobs dashboard:
Recent Job Alerts (summary bar) The Jobs with Errors metric displays the
number of jobs that failed. Click the metric to
view details of jobs and programs.
Job Status (tag cloud) This tag cloud displays the job status by
number of records.
Program Name (tag cloud) This tag cloud displays the program name by
number of records.
• By Phase:
• By Date (tab):
Recent Job Results (table) This results table displays details of recent
jobs such as the job name, the job status, and
the job type.
• Research disputes, understand the depth and breadth of the root causes and
provide appropriate resolution.
Lifecycle Phases
To determine how a transaction is processed in Incentive Compensation and to show its
status in a single glance, the Incentive Compensation Command Center uses lifecycle
phases. In the Available Refinements list, select Interface Processing and then the
Lifecycle Status refinement to know the status of transactions.
2. Calculate
3. Pay
4. The fourth phase is the single lifecycle status, which is the sum of all the three
phases (Collect + Calculate + Pay).
2. Calculate phase: The transaction is calculated and posted (CALC: Calculated >
Posted).
3. Pay phase: The transaction is approved and paid (PAY: Approved > Paid).
2. Calculate phase: The transaction is calculated and posted (CALC: > Calculated >
Posted).
3. Pay phase: The transaction is approved and paid (PAY: Approved > Paid).
This transaction is expressed as COLLECT: > CALC: > Calculated > Posted > PAY:
Approved > Paid
2. Calculate Phase: The transaction is calculated but not posted (CALC: ->
Calculated > Unposted).
This transaction is expressed as COLLECT: Collected > Loaded > CALC: Calculated
> Unposted
Note: Implementers can use the information provided in How Lifecycle Statuses and
Phases are Derived, Oracle Incentive Compensation Implementation Guide to understand
transaction processing.
You can analyze data using various metrics, charts, graphs, and tables.
From the Compensation Manager responsibility, navigate to the Quality by Phase
dashboard:
(N) Quality Management > Quality by Phase
Component Description
Processing Metrics by Value (summary bar) This summary bar provides metrics on the
value of commissions, transactions, and
paysheets.
Conversion Metrics by Count (summary bar) This summary bar provides conversion
percentages and the number of transactions
for key stages of processing.
• API Count
• Headers Count
• Lines Count
• Payments Count
Explosion Ratio from Collect to Calculate This summary bar shows the following
(summary bar) metrics:
Plan Element (tag cloud) This tag cloud shows the plan element names
according to the number of commission line
records for each plan element.
Results Tables
The Quality by Phase results tables show information about collecting and calculating
transactions. These tables also provide detailed information about payments, paysheets,
and payruns. In the Collect tab, the Interface Transaction option shows attributes of a
transaction as it enters a specific phase. The Interface Processing option displays
processing attributes of the Collect phase and help to understand how a transaction is
processed in a phase. This information enables you to validate each phase.
Use links in the following tabs to performs actions:
• Calculate: To update the transaction, click the Edit Transaction link to navigate to
the Update Transaction page.
• Paysheet: To view paysheet details, click the Paysheet Detail link to navigate to the
Paysheet page in Incentive Compensation.
• Payrun: To view payment summary, click the Payrun Summary link to navigate to
the Payment Batch Summary page in Incentive Compensation.
Processing Metrics The following metrics are based on the status of paysheets:
(summary bar)
• Unlocked: The number of unpaid paysheets, where the paysheet
status is Unpaid
Pay Metrics These metrics are based on the sum, average, or maximum of paysheet
(summary bar) amounts.
• Pay Total
• Earnings
• Held Amount
• Adjusted Amount
• Paysheet Average
• Paysheet Maximum
Payruns (tag cloud) This tag cloud displays the payrun name by the number of records.
Count (chart) This pie chart displays the paysheet distribution percentage per
paysheet status. The hover text for each segment on the chart displays
the number of paysheets in that paysheet status.
Value (chart) This stacked bar chart displays the sum of paysheet amounts for each
payrun, stacked by the phase of the pay lifecycle.
Paysheets Table This results table displays information such as the paysheet status, the
(results table) payrun name, the employee number, and the paysheet total.
• Monies in jeopardy
You can analyze data using various metrics, charts, graphs, and tables. From the
Compensation Manager responsibility, navigate to the Jeopardy by Phase dashboard:
(N) Quality Management > Jeopardy by Phase
Ready-to-Pay Metrics (summary bar) The Payments Paid metric displays the total
payments belonging to a paid payrun.
Transaction Type (tag cloud) This tag cloud displays transaction types by
the number of records for each type.
You can analyze data using various metrics, charts, graphs, and tables. From the
Compensation Manager responsibility, navigate to the Performance Evaluation
dashboard:
(N): Quality Management >Performance Evaluation
Plan Element (tag cloud) This tag cloud displays the top ten plan
element names according to the number of
sales representative period quota records for
each plan element.
Attainment vs. Quota (tabbed layout): The Period to Date tab contains the following
charts:
Period to Date (tab)
• Target Achievement Period-to-Date
(Sum), Period-to-Date Target Amount
(Sum) by Period, Plan Element,
Compensation Plan, Role, and Incentive
Type Code: This graph shows all target
achievements for the period-to-date
versus the target amount for the period-
to-date.
Attainment vs. Quota (tabbed layout): The Interval to Date tab contains the Interval-
to-Date Attainment (Sum), Interval-to-Date
Interval to Date (tab) Target Amount (Sum) by Period, Plan
Element, Compensation Plan, and Role
graph, which shows all the attainment for the
interval-to-date and the target amount for the
interval-to-date.
Each product represents a different type of sale for which an organization pays
compensation. Different companies have different products, because each sales
organization awards compensation differently. After defining your organization's
products, you can assign one or more of them to a plan element in a compensation plan.
Any resources that are assigned to roles that are, in turn, assigned that compensation
plan can receive compensation for transactions involving those products.
All products on the same plan element share the same quota and compensation rate
table. If products in a compensation plan have different quotas or are paid according to
different rate tables, you must create a plan element for each product grouping that
calculates the commission differently.
You can award compensation based on factors other than products or services sold. For
example: Your sales organization might have customer account teams, where
salespeople only receive compensation for sales to their assigned set of accounts. In this
case, each customer account is probably a separate Oracle Incentive Compensation
• Parent
• Child
Root node is the highest level of the hierarchy. You can place as many nodes under the
root node as necessary to meet your business objectives.
A parent node is a node that has at least one node that rolls up to it. A parent node
typically summarizes information concerning the nodes below it, referred to as child
nodes. An example of a parent node would be Western States and under it child nodes
called California, Oregon and Washington.
A child node rolls up to a parent node. A child node can roll up to only one parent
node. For example, under the parent node of California the child nodes could be called
San Francisco and Los Angeles.
You can create a new hierarchy under an existing hierarchy type, or you can create a
new hierarchy type and then build the hierarchy there.
The hierarchy determines the eligibility of other products. A transaction can be
classified with a product at a granular level, but by creating a product hierarchy, other
products are eligible for compensation as long as they exist higher in the hierarchy and
lie on the same ancestor path.
For example, sales representatives sell laptops and desktop computers and the
transactions are classified at the lowest level, the product name. In the product
hierarchy, the product All Computers exists higher than the Laptops and Desktops
products. The manager of the sales representatives does not have to list Laptops and
Desktops on her plan element but only All Computers, because it exists higher in the
hierarchy. She will get calculated compensation even though the transaction was
classified as Laptops.
2. Click Apply.
3. Click Details. The application provides a default root class called Hierarchy Base
Node. Start building a hierarchy by entering one or more root class names. When
you select the root name, a plus sign next to the name indicates you can click it to
expand and view the hierarchy that is part of the selected root. You can expand and
view any level of the hierarchy.
4. To add a child, select the parent product for which you want to add a child, click
the Add Child button, and select where you want the new node to appear. If you
select Add new node under selected node, The node is added as a child to the
selected parent node. If you select Add new node as root node, the node is added to
the hierarchy as another base node.
5. Select a new node type. Click Update to add the product to the hierarchy. Repeat
the steps to build your hierarchy.
6. Click Update periodically as you go and at the end to save your work.
Restrictions
Hierarchy deletes are cascading. This means that if you delete a node, all children of
that node are deleted along with it.
You can create as many product hierarchies as you need. However, only one product
hierarchy can be effective at a time. Use the interval dates to keep the hierarchies
separate.
You can import any portion of another hierarchy to become a child of your selected
node in the hierarchy you are building. See the Imports and Exports section.
• Account Generation
• Projected Compensation
• Credit Allocation
Classification defines the rules that are used to identify a product for each transaction
that the system processes as part of calculating compensation. Account Generation is
used to integrate Oracle Incentive Compensation automatically with Accounts Payable
and to classify transactions to identify Expense and Liability Accounts. Projected
Compensation is used to classify quotes, opportunities, and so on, for the Projected
Compensation API. A Credit Allocation ruleset is used when the credit allocation
functionality is active (see Sales Credit Allocation, page 11-1.
The Classifications page lists all rulesets that have already been created. To view or edit
a ruleset, click the link in the Name column or use the Advanced Search option.
Products must have been created (see above). Any necessary Attribute flexfields of the
CN_COMMISSION_HEADERS table have been defined (see Define Tables). These
flexfields become the attributes that are evaluated when determining an eligible
product.
When you create a new ruleset, the From and To dates cannot overlap the dates of
another ruleset. After you have named and assigned From and To dates to a new rule
set, click Apply to go to another page where you can build the rule set.
2. To add a rule, in the lower section of the Rules Hierarchy page, select Root from the
Add Rule column list.
8. When you are done building the rule set, return to the main rule sets page, select
the rule set, and click Synchronize. See Restrictions.
Restrictions
When you click Synchronize, If any rules do not have attributes, an error message
• Rate Tables are the part of a formula that determines the rate at which
achievements are compensated. Rate dimensions are the structural part of a rate
table to which values are added.
• Expressions are interchangeable, reusable parts that are used as input and output
expressions of formulas, in expression-based rate dimensions, and in performance
measures.
When you are building a compensation plan, you can always use pieces that are
previously defined. All you need to do is add another row and select the component
from the list of values. At each step, though, you can create the component you need by
clicking the Create button and following the process.
When resources have customized compensation plans the values are stored in the
CN_SRP_QUOTA_ASSIGNS table but the column names are the same as for the Plan
Element values above:
• Target => CN_SRP_QUOTA_ASSIGNS.TARGET
When setting these values for specific periods or distributing the amounts over a given
period, click the Distribute button at the bottom of the Plan Element Details page.
To use these values in an expression, select the following columns from the Calculation
Values list of values on the Calculation Expressions page:
• Quota => CN_PERIOD_QUOTAS.PERIOD_TARGET
When defining these values for periods that are specific to individual resources, use the
same columns as for the plan element but select them from the
CN_SRP_PERIOD_QUOTAS table.
• Quota => CN_SRP_PERIOD_QUOTAS.PERIOD_TARGET
There are numerous columns that derive their values from these column amounts. They
can be identified by the inclusion of an ITD or PTD flag in the column name, for
example, ITD_PAYMENT is the Interval to Date Payment (Fixed Amount).
You have the option of introducing seasonality into the achievement by using the
Distribute button on the Plan Element Details page. When you click this button, the
Plan Element Details - Distribute Variables page displays all of the open periods for the
plan element. You can manually enter the desired quota amount for each period to
create seasonality for the target, performance goal, or fixed amount distribution.
• Check the Allow Eligible Products Overlap box if you want multiple plan elements
to use the same eligible products. Use this option when you need to compensate a
resource more than once for a transaction. For example, you may have two plan
elements, with one used to calculate a monthly commission and the other used to
calculate a quarterly bonus.
• When you enter a sequence number for multiple plan elements, this tells the
application the order in which to process the plan elements. Sequencing of plan
elements is important when one plan element relies on the calculation results of
another. For example, with independent plan elements, the dependent plan element
requires that the necessary plan element be calculated first so that the most up-to-
date data is present. See Interdependent Plan Elements, page 4-27.
• When you click Apply to validate the compensation plan, it ensures that you have
entered the plan information correctly, and verifies the following:
• The plan has a name and start and end dates.
• The plan has one or more plan elements assigned with start and end dates
within the plan start and end dates.
• Each plan element that uses a rate table has contiguous tiers with start and end
dates within the plan start and end dates.
• Each plan element has at least one eligible product assigned, with start and end
dates within the plan start and end dates.
• If each of the above conditions is met, then the Status field shows Complete. If
the Status field displays Incomplete, the plan cannot be used to calculate
compensation. You must check the items shown above and fix any problems
and then Update the compensation plan again. Do this until you receive a
validation status of Complete.
• This page supports an optional descriptive flexfield, which you can configure to
your requirements. For more information on flexfields, see the Flexfields
appendix or the Oracle E-Business Suite Flexfields Guide.
• To view or change details for an already created compensation plan, select Maintain
Compensation Plans in the Navigator.
• You can navigate also to the Compensation Plans - Design page from the Search
Compensation page, by clicking a compensation plan from the list, or click the
"Duplicate" icon, associated with the plan.
• If you have clicked the "Duplicate" icon and navigated to this page, then Oracle
Incentive Compensation will create a copy of the compensation plan. See:
Maintaining Compensation Plan, page 4-7 (Copying Compensation Plan).
• Make sure to save the view with a unique name. If you are making changes to an
existing view, leave the name the same.
• You can set the number of rows that you want to display. However, you cannot
change the number of rows that are displayed in any view that is seeded data.
• Check the Default box if you want your new customized search to be the one that
displays compensation plans automatically when you open the Compensation Plan
page.
• The application allows for three levels of sorting. Choose the sort parameter order
on the left side and on the right side, select ascending or descending order.
• You can set the view to show table data when all conditions are met or when any
conditions are met. The second setting should be used sparingly.
• The five variables in the dropdown list--Contains, ends with, is, is not, and starts
with--enable further personalization. Views created using Is and Starts with
perform better than views created using the other variables.
• Description
• Start date
• End date
• Flexfields information
• You can change or restructure any aspect of a compensation plan. Because you can
assign the same plan to many salespeople, however, be aware of how the changes
you are making impact individual resources.
• When you change a compensation plan, the changes propagate to the resources
assigned to the plans. For customized plans, the resource receives all changes
except the customized plan.
2. Click on the Compensation Plan, which you want to download, to reach the
Compensation Plan Design page.
• Interval Types
• Split Options
These items are grouped under Earnings Rule because they affect the frequency and
nature (whether or not to aggregate) of transaction collection, and consequently how
earnings are defined and calculated.
When building a compensation plan, you can use any formula, rate tables, and eligible
products that you have already created. Or, at each stage of building the plan, you have
the option of creating a new component.
Formulas are based on the Commission incentive type of a compensation plan. Bonus
incentives, which are based on the Bonus incentive type, are additional compensation
based on aggregated transactions. Note: When you are defining the earnings rules, the
Formula list of values displays only formulas that match the incentive type value
selected in the Incentive Type drop-down list.
Warning: If you want to change the setup of plan elements for new periods, for
example, at the beginning of a new year, end date the existing plan elements--do not
delete them. When you delete a plan element by replacing it with a new one, you lose
the resource setup data.
Warning: Do not open a new window during a browser session and navigate to the
same page in the two windows simultaneously while you are creating a plan element.
Navigation
• Bonus: The plan element displays in the Bonus category of the Year to Date
Summary.
• Quota: The plan element name displays in the Quota category of the Year to
Date Summary.
• The commonly used intervals are Period (month), Quarter, and Year. However, you
can define a custom interval using the Configuration Workbench. After a
compensation plan has been assigned to a sales role, in order to change the interval,
you must remove the plan assignment, change the plan element's interval, then
reassign the compensation plan.
• Formula types can be Formula or PL/SQL Package. Each formula type requires a
different action:
• Formula: Select a formula from the list of values.
• External: Enter a PL/SQL package name in the Package Name field. This
enables the application to find the external formula.
• If you choose an external formula type, you must enter the name of the PL/SQL
package in the Package Name field.
• The Payment Group Code setting is used to set how you want payments from a
resource's payment plan to be allocated between plan elements. The payment group
codes are customizable using a lookup; the default setting is Standard. If all plan
elements are set to Standard, the payment plan amounts are allocated equally.
• The credit type is normally the preset functional currency, but it can be any type
that you define in the application. Changing the credit type of a plan element after
it has been used in a compensation plan to pay compensation is not recommended.
This can affect payment amounts. Payment can be made only in the functional
currency credit type.
• Optionally, you can identify a liability or expense account (if the application is
integrated with Oracle Payable). Liability and expense accounts can be identified at
the plan element level. Earnings for the plan element are assigned to the specified
liability or expense account.
• Select Yes for Use Eligible Products Worksheets to combine the amounts from all
products assigned to the plan element to meet a target or goal.
• Target is the specific amount set for resources as their attainment amount. The most
common way that a target is used in an expression is for evaluating transactions as
a percentage of quota. Goal is the amount that management sets as the actual goal
expected of the resources. This amount is typically used for reporting purposes and
is not exposed to the resources. Fixed Amount is a constant amount that is used for
calculation purposes.
• Target, Goal, and Fixed Amount are indicated here in the application, but are used
when building calculation expressions.
• Credit Receiver has Manager Role: Rolled up transactions (and direct sales) are
calculated for those resources who have a Manager type of sales role.
• None: Only direct credits are calculated for any resource who has this plan element.
Navigation
Plan Administrator > Create Plan Element > Assign Eligible Products
• You can enter a child rate table. Use the same steps as you used for the Parent Rate
Table section. See example.
• You can click the Plan Element Name link at the top to return to the Plan Element
Detail page.
Example
Child rate tables are referenced within embedded formulas. The following example
illustrates how child rate tables are used.
Amount Rate
0-1 0
1-999,999,999 1
In this example, the first tier with an amount of less than 1 has a rate of 0, and in the
second tier, anything greater than one has a rate of 1.
Create an output expression that references the rate table result. Select Others from the
H-grid in the Expression screen and click Rate Table Result.
Next, you need to configure the embedded formula out of the input expression, rate
table, and output expression you have just created. It will be referenced by the other
formula.
Now you can configure the formula that will be referenced by your plan element. First,
configure an expression to reference the formula that you just created. This expression
looks like this:
Commission Headers.TRANSACTION_AMOUNT/SRP Period Quota.
TARGET_AMOUNT*<embedded formula>.
Next, create the rate table for your formula, as follows:
Percent Rate
0-100% 3%
100-9999% 4%
Finally, create an output expression that multiplies your rate table result by the
Steps:
1. Enter name and click Update.
2. To assign or change rates, click the Update Rates button to go to the Update Rates
page.
3. To create a new dimension while you're creating a rate table, click Create in the
Dimension section and build it on the separate page.
4. Click Apply.
1-25% 1%
25-50% 2%
50-75% 3%
75-100% 4%
• String: The rate tiers are alphanumeric, such as product numbers or the names of
states.
These values comprise the ranges from which compensation is calculated in a rate table.
If a rate is based on multiple criteria, then a multidimensional rate table can be created
to reflect all criteria. Use one dimension per criterion.
Oracle Incentive Compensation supports accumulated revenue with multidimensional
rate tables. Accumulation is limited to one dimension.
Navigation
Plan Administrator > Maintain Component Library > Rate Dimensions > Create
Notes
• For Amount or Percent dimensions, in the Rate Tiers area, you must enter numbers
in the From and To columns. Follow the sequence, and do not leave any gaps in the
rates.
• For String dimensions, enter the string value for the rate tier.
• For Expression dimensions, select expressions from the list of values for the From
and To columns.
• You can also create rate dimensions on the Rate Table Details page by clicking the
Create button.
• After you create a rate dimension with a type of String or Expression, you cannot
change the type with a future update. For rate dimensions of the Amount or Percent
type, you can update the type definition, switching Amount to Percent or Percent to
Amount only.
• If the application is unable to find a match in a string dimension in a rate table, the
application picks the last rate value by default. For example, suppose that in the
example above, a transaction has dimension values of 10,000, Iowa, and Service. No
matches occur, and the rate table result is 9.25%, the last value in the Rate column.
This setup permits you to define a catch-all tier that captures all unmatched values.
If you want the non-matching transactions to receive no compensation, add OTHER
as the last string value to each string dimension with a corresponding rate of 0%, for
example. Another method of dealing with non-matching transactions is to use
classification rules. Transactions with attributes that do not match your
classification rules will have a failed classification status. You can correct these
failed transactions' attributes by changing their values and maintain a record of the
2. Search for the rate dimension whose copy you want to create.
Running the Synchronize Rate Dim Update to Sales Rep Rate Assignment
Request
You must run the Synchronize Rate Dim Update to Sales Rep Rate Assignment
concurrent request only if the OIC: Propagate Rate Dimension Update to Sales Rep profile
option is set to No. See Table of Profile Options, Oracle Incentive Compensation
Implementation Guide for information about the profile option. After a compensation
manager updates the tiers of a rate dimension, page 4-18 on the Update Rate Dimension
To run the Synchronize Rate Dim Update to Sales Rep Rate Assignment
request:
1. Select New Request.
2. In the Program Name field, enter Synchronize Rate Dim Update to Sales Rep Rate
Assignment.
4. Select the rate dimension for which you want to propagate updated rate tiers to the
CN_SRP_RATE_ASSIGNS_ALL table.
6. Specify values in the Batch Size, Number of Workers, and Worker ID parameters. If
you leave these parameters blank, then the request automatically assigns default
values when it runs.
Defining Quotas
Target, Fixed Amount, and Goal are used during Calculation as a basis for quota
achievements or as a stated goal, which can be used as a constant value. How these
values are used in the actual calculation of compensation is up to you.
Target is the specific amount set for resources as their attainment amount. Resources
have views of this figure through their contract. The most common way that a target is
used in an expression is for evaluating transactions as a percentage of quota. The
expression typically looks like this:
TRANSACTION_AMOUNT/TARGET
This expression gives you the percentage of quota a particular transaction yields.
Note: Target and Quota amounts are used interchangeably.
Performance Goal is the amount that management sets as the actual goal expected of
the resources. This amount is typically used for reporting purposes and is not exposed
to the resources. Performance Goal amounts are used to determine performance against
• Feb 07 - 5%
• Apr 07 - 10%
• May 07 - 10%
• Jun 07 - 10%
• Jul 07 - 5%
• Aug 07 - 5%
• Sep 07 - 5%
• Oct 07 - 10%
• Nov 07 - 10%
• Dec 07 - 20%
If you distribute these percentages, which add up to 100%, the amounts display
correctly. Jan 07 displays $500, May 07 displays $1,000, and Dec 07 displays $2,000. For
this example, suppose you decide to change the target amount to $5,000, or one half of
the original amount. When you distribute this amount, the amounts are not cut in half,
but the percentages double.
• Jan 07 - 10%
• Feb 07 - 10%
• Mar 07 - 10%
• Apr 07 - 20%
The pattern continues throughout the year. The percentages are twice what they were
for $10,000. This occurs because the amounts are stored in the application, not the
percentages. Jan 07 is still $500 and Apr 07 remains $1,000, but the stored numbers
represent double the percentage of the new target amount.
Navigation
Plan Administrator > Create Plan Element > Define Default Quotas
Notes
• You can click the Plan Element name link to return to the Plan Element Details
page.
• When you select an interval, regardless of the view, variables are distributed
equally to each period.
• If you do not enter an End Date on the Plan Element Details page, the application
automatically distributes the variables for all remaining periods defined in the
predefined Calendar for the application.
• If the plan element uses a partial year, then the distributed amounts are prorated.
For example, if the periods start with April, and the target amount for each period
is $5,000, then the quarterly view will show as $15,000 each, but the Year view will
be $45,000.
Amount Commission
0-10,000 1%
10,000-50,000 2%
50,000-100,000 3%
100,000-999999999999 4%
This resource also has bonus plan element with the following details.
• Input expression = Commission_paid_ptd column from a view created based on the
Amount Bonus
0-500 75
500-1,000 65
1,000-5,000 55
5,000-10,000 45
10,000-99999999999 25
01-Jan-01 9,000
02-Jan-01 15,000
01-Feb-01 40,000
Compensation calculated for the above transactions using the commission plan above
is:
01-Jan-01 9,000 1 90
Bonus calculation using the bonus plan and bonus rate table
Notes
• Use Commission_paid_ptd in the bonus input expression if your bonus is based on
the compensation of the resource. Use Input_achieved_ptd in the bonus input
expression if your bonus is based on the total sales credit of the resource.
• Here is a suggested view definition for the quarterly bonus that you can build to
create the example shown previously:
select salesrep_id, max(a.period_id) last_period_id, sum
(input_achieved_ptd)
• Multiplier: Increases a resource's quota credit, that is, level of quota achievement
Multipliers work only when they are used by the calculation input expression assigned
to the formula. For example:
• (Transaction_Amount*Multiplier)/Target
Earnings factors can only be used when the Apply Transaction Type is set to
• Deposit
• Order Return
• Write-off: A sale is written off the books for a variety of reasons and posted to
Oracle General Ledger.
Unlike transaction factors, other factors are each calculated separately, and do not need
to total 100%. Each can be over or under 100%. For example, you can set the other factor
of Order Return to be credited at 80%, or clawbacks at 110% to match your business
procedures.
Eligible products must already be assigned.
Navigation
Plan Administrator > Maintain Component Library > Plan Elements> Assign Eligible
Products > Update Factors
• For transaction factors, you can enter numbers to indicate how you want to stage
the payment of commission.
• In the Other Factors area, the default entry for each column is 100.
2. Select the column you want to use in the expression from the Calculation
Values box.
After you have created the interdependent plan elements, build a compensation plan
using the plan elements. Use the expression as the input expression of the formula of a
new plan element. See Creating a Compensation Plan, page 4-4 for steps to creating a
compensation plan.
The new plan element you create calculates compensation based on totals from the plan
element that you built into the expression.
Example
A sales manager wants a resource to receive an additional $1,000 bonus if she sells 100%
of her target for a certain product. Because the bonus requires knowledge from the plan
Defining Formulas
You have complete flexibility to create formulas for calculating compensation. Some
formulas can be embedded in another formula definition or in a plan element
definition. You can save an incomplete formula and return to complete it later.
You can use expressions or rate tables in a formula that are already created or you can
create them as you build the formula. Expressions can be repeated in your formula and
can be reused in other formulas as well. See Defining Calculation Expressions, page 4-
33 for more information on the types of calculation expressions that you can use for
commission and bonus formulas.
Warning: Do not open a new window during a browser session and navigate to the
same page in the two windows simultaneously while you are defining formulas.
Navigation
Plan Administrator > Maintain Component Library > Formulas > Create
Steps:
1. Select an operating unit.
6. Check the Interval To Date box if you want to base the calculation on a period
different from the plan element interval. See Restrictions.
7. Click Apply.
9. Select an input expression. To create a new expression click Create. See Defining
Calculation Expressions, page 4-33
You can use more than one input expression, but the number of input expressions
must equal the number of dimensions in the rate table that you select later.
10. You can assign a forecast if you need it for Projected Compensation.
12. Select a performance measure if you want to use it in the Year To Date Summary
Report for comparison with achievement.
14. Click the Rate Tables subtab, the Add Another Row button, and view the rate table.
To create a new rate table, see Define Rate Tables, page 4-15.
15. After all of the components are in place, click Save and Generate.
If you have successfully created the formula, the status field above the Generate
button changes from Incomplete to Complete. See Restrictions.
Restrictions
For commission formulas, Individual Option for Transactions can be used with any
Cumulative/Interval to Date option.
• By default Interval to Date and Cumulative options must be used together. You
cannot select Interval to Date by itself. Split options are selectable (each is mutually
exclusive).
• Accumulate can be selected by itself. Split options are selectable (each is mutually
exclusive).
Bonus formulas calculate only against Individual transaction options. Split options are
selectable (each is mutually exclusive).
Performance measures must use numeric expressions to work correctly. In a formula, if
no performance measure is assigned, the application uses the first input expression. If
that expression evaluates to string values, the calculation will fail. Therefore, it is
important to assign a numeric performance measure when the first input expression is
not numeric.
You must generate a formula for it to be available when you are selecting formulas for a
plan element. Formulas that do not have a Complete status do not appear in the
Formulas list of values. When you generate a formula the application verifies that the
expressions and rate tables are compatible and that they will work when they are called
during the calculation.
Example of Split Tiers
A rate table shows 0 to 1000 at 1%, 1000 to 2000 at 2%. The transaction amount is 1500. If
you select No Split in the drop-down list, 2% is applied to the whole transaction amount
of 1500. If you select Non-Proportional in the drop-down list, 1% is applied to 1000 and
2% is applied to 500.
The Proportional selection in the Split drop-down list is intended for use with amount
rate tables. For example, if the rate table shows 0 to 1000 at 100, 1000 to 2000 at 200. The
first transaction amount is 200. The compensation for this transaction is 20 because 200
is one fifth of the first rate tier and one fifth of the 100 rate is 20. If the second
transaction amount is 1300, the remaining four fifths of the first rate tier pays 80, and
half of the second tier [(1300 minus 800)/(2000 minus 1000)] pays 100 (half of the rate
200). Total compensation for the second transaction is 180.
In a multidimensional rate table, only one dimension can have split rate tiers.
If you are selecting the Cumulative or Split functions, you can use percent, amount, or
expression type rate dimensions. You cannot use string dimensions.
Calculation Expressions
Calculation expressions are interchangeable, reusable parts that are used in input and
output expressions of formulas, expression-based rate dimensions, performance
measures, forecast expressions, and for projected compensation.
You can use these calculation expressions as performance measures, input expressions,
output expressions, or rate table dimensions. You can also embed one calculation
expression within another. After they have been saved, the expressions can be assigned
and reassigned to any number of formulas you need.
Any column from any table can be part of your expression, as long as the Calculation
Input Expressions
Input expressions tell Oracle Incentive Compensation what to evaluate from the
transactions and how to match the results to the corresponding rate table. A simple
input formula expression looks like this:
TRANSACTION_AMOUNT
For example, a company can establish that its sales force will be compensated based on
transaction amount. The input expression evaluates transactions from the
TRANSACTION_AMOUNT column of the CN_COMMISSION_HEADERS table.
This is an example of a rate table:
$0 - $100 4%
$100 - $500 5%
$500 - $99,999 6%
As transactions are sorted by through the input expression they are matched to the
established rate table tiers. If a transaction is collected in Oracle Incentive
Compensation with the following attributes:
1. Customer X
3. Product Z
Performance Measures
A performance measure is part of a plan element that captures an accumulation of
transaction values by plan element and uses the data in reports that compare
achievements to quota, goal and performance measure. Performance measures are not
used to calculate compensation.
You can use a performance measure to track revenue. You select and define the
columns where revenue information for transactions is held. Then, as transactions are
entered and collected for the assigned plan element, the transaction values are
accumulated. An example performance measure is:
TRANSACTION_AMOUNT
Note: Performance measures must use numeric expressions to work correctly. In a
formula, if no performance measure is assigned, the application uses the first input
expression. If that expression evaluates to string values, the calculation will fail.
Therefore, it is important to assign a numeric performance measure when the first input
expression is not numeric.
• The input of the forecast version of a formula which allows multiple inputs
• You can use values from another plan element and plan element metrics.
• The usage of the expression is also displayed once it is saved. The usage rules
determine where the expression may be applied.
• A bonus formula and plan element is based on values collected in the OIC
subledgers or on results collected from other plan elements. A Bonus calculation
expression cannot include an element from the CN_COMMISSION_HEADERS or
CN_COMMISSION_LINES table or any table that is mapped to this table. A Bonus
calculation expression cannot be used as an embedded formula. See Bonus
Formulas for more information.
• The six selections in the View H-grid represent groups of calculation elements. Only
the calculation elements for that selection are displayed in the Calculation Values
box.
• Sales Compensation Elements: These include seeded and previously defined
columns from the transaction headers and lines tables, as well as compensation
plan related tables.
• SQL Functions: SQL Number, Group, and other functions can be added to an
expression.
• Others: Other elements, such as Rate Table Result and Forecast Amount, are
listed here.
• Selected columns are accessible for use in building formulas and performance
measures.
• The following Oracle Incentive Compensation tables are predefined in the system
and can be used as calculation values in defining performance measures and
formulas:
• CN_COMMISSION_HEADERS: Contains information relating to the
transaction, such as employee name and number. The 100 attributes defined on
this page are descriptive flexfields. For more information on flexfields, see
Oracle Incentive Compensation Implementation Guide, Appendix A, or the
Oracle E-Business Suite Flexfields Guide.
• A rate dimension calculation expression can only be defined from the following
tables:
• CN_SRP_PERIOD_QUOTAS: see above
• Plan element metrics are stored for each resource in the database, and are not
necessarily defined in the user interface. Most of the selections relate to
accumulation of commission in a plan element over a period--period to date (PTD)--
or an interval other than the period--interval to date (ITD). For example, a plan
element can use a period of a month but also an interval of a quarter, and
accumulation of commission for either interval or period can be used in another
expression to calculate a bonus. This can be set on the Calculation Expressions page
using the Plan Element field and the metrics drop-down list next to it.
You can now build an expression that uses this function in the expression builder in
Oracle Incentive Compensation:
threshold_cap(Commission Headers.Transaction Amount,1000,5000).
Warning: When creating user defined expressions, do not perform any updates of
transaction related tables or perform any commits. This will potentially cause data
corruption in the transaction tables. However, you are allowed to select any values from
any table without causing data corruption.
2. Search for the calculation expression, whose copy you want to create.
• Formulas
• Rate tables
• Expressions
Navigation
Plan Administrator > Export Setup Data > Create
Steps:
1. Enter Request Name.
3. Click Next. You will navigate to the Create Export Request: Choose Objects to
Export page.
4. Click Add.
6. Click Submit.
Caution: After you have saved an export request, you can make
changes to the plans listed in the request. You have rendered the plan
incomplete, due to setup changes, or have deleted the plan; you can still
submit the export request. In such a case, Oracle Incentive
Compensation, will not process the export request, and it will not
create any XML document.
Additional Information: You can download the plan details file, only if
the export request is in 'Complete' status.
Navigation:
Plan Administrator > Export Setup Data
Steps:
1. Enter Request Name.
3. Click Go.
When you click Download File in the Search Request page, or click Download in the
request details page, then application dialog box, through which you can save the plan
details file to a local system.
6. Click Submit.
After you have submitted the export request, Oracle Incentive Compensation generates
a Request Id. You can use this Request Id, to track the status of the import request.
3. Click Go.
Prerequisites
• You have changed the names of modified plans and its sub-elements, in the source
environment, to distinguish them from existing plans in the target environment.
• • Plan Element A •
Plan 2 Plan 2
Prerequisites
• Plan and plan components haven been successfully exported to XML
Source Plan Details Files Elements Existing in Target Resulting Setup after
Operating Unit Import Process
• • Plan Element A •
Plan 2 2008: Plan 2
• Plan Element A
Additional Information:
"2008: Plan Element B" is
reused across "2008: Plan
1" and "2008: Plan 2". "Plan
Element A" is reused
across "Plan 3" and "Plan
4".
The Compensation Manager or Compensation Analyst also can create, update, or add
members of a team or group by using the Compensation Overview, 360 Degree View
menu if the correct profiles are enabled for the responsibility (System Administrator >
Security > Profiles).
A resource must be assigned to a Pay Group using a resource role. Generally, resources
are grouped together in Pay Groups based upon the frequency of payments. A
recommended best practice is to use a different role, separate from the compensation
plan role, to assign resources to Pay Groups. This way if the job (role) changes, the
resource's new plan assignment can occur without removing the resource from the Pay
Group. This helps to avoid conflicts for unpaid paysheets and overlapping Pay Group
assignment issues.
Optionally, you can assign a payment plan to a resource. Payment plans are created by
the Plan Administrator to set up Draw and Recovery options and to define minimum
(draw amount) and maximum (cap amount) payments. Both of these functions are part
of the Setup section of the Navigator, along with maintenance of the compensation
periods that measure achievement.
Warning: Do not open a new window during a browser session and navigate to the
same page in the two windows simultaneously while you are assigning compensation
• Plan Setup
• Compensation
• Notes
The Resource Setup tab displays data directly from Resource Manager and supports
maintenance of resource compensation type of data.
The Plan Setup tab supports the management of resource plan customizations, payment
plan assignments and customizations, and pay groups. For more information on
compensation plan management, see Maintaining Compensation Plans, page 4-7. For
more detail about payment plans, see Assign Payment Plans, page 5-10.
For help with pay groups, see Assign Pay Groups, page 5-5.
The Compensation tab gives access to current and historical compensation reports,
provides viewing and maintenance of compensation transactions, and enables
Compensation Managers to view and work on paysheets, without leaving the resource
view or context. For more about reports, see Overview of Reports, page 10-1. For
paysheet information, see Working with Paysheets, page 8-14.
The Notes tab provides the ability to add and review notes associated with resources or
notes associated with changes to objects such as the compensation plan at a higher level.
Notes are automatically generated by the system for changes made to most objects
within Oracle Incentive Compensation, and are very useful for auditing and for
complying with the Sarbanes-Oxley mandates.
Navigation
Compensation Manager > Search Resources
• Distributed amounts
Navigation
Compensation Manager > Resource Compensation Overview > Search Resources > Plan
Setup > Compensation Plans
Notes
• You must select the compensation plan and check the Customized box for any plan
that you want to customize for a resource.
• Click each subtab under Update Plan Element to make changes for a resource. Click
the Details icon to expose the areas you can change, such as rate table rates. Click
Apply after making changes.
Steps:
1. Search for the role you need.
2. On the Compensation Plan subtab, add another row, and then select the
compensation plan that you want to assign from the list of values.
4. Click Apply.
Restrictions
Resources who are assigned a role must also be assigned a pay group (see Assign Pay
Groups., page 5-5
Prerequisites
❒ The pay group must be defined before it can be assigned to a role or resource.
Steps:
1. Query for a pay group, or click Go to view all pay groups.
5. Click Apply.
4. Select a pay group name, along with start and end dates.
5. Click Apply.
Restrictions
You must enter a valid start date and end date for the assignment of a pay group to a
role. An error message displays if the dates are not valid. A role cannot have more than
one pay group assigned at a time.
Prerequisites
❒ The pay group must be defined.
Steps:
1. Query for a pay group, or click Go to view all pay groups.
2. Scroll to the right and click the name link of the pay group you want to assign.
6. Click Apply.
Restrictions
A resource can be assigned multiple pay groups, but only one pay group can be active
at a time.
Pay groups can be assigned to multiple resources at the same time and you can start
and end pay group assignments by individual resource at any time within the duration
of the pay group.
When you assign a pay group to a resource, the application automatically checks to see
if there are any conflicts between the start and end dates of the pay group and the start
and end dates for every resource to which the pay group has been assigned. For
example, if you define a pay group starting Jan 1 and ending on Mar 31 and you have
assigned it to a resource, the application will not let you change the end date for the pay
group assignment beyond Mar 31.
In order to preserve the pay group assignment for a resource when their role is deleted
from a pay group assignment, a Prevent Automatic Override check box has been added
to the Update Pay Groups page (Setup > Maintain Pay Groups). This feature can be
used to prevent individual resources assigned to a pay group from leaving their pay
group, even if the other resources assigned to a role are assigned to a new pay group.
The check box also prevents manual updates to the resource's pay group.
• Example 2: If payment batch 1 is for $1,000 and payment batch 2 is for -$1,200, then
the payment plan will zero out the payment batch 2 amount. In this case, period
earnings are still less than zero--in this case -$200.
Navigation
Plan Administrator > Component Library > Payment Plans
Notes
• Click Create to create a new payment plan or Go to display existing plans.
• The default payment group setting is Standard. Period is the default payment
interval. You can select other entries for these fields if they have been created
separately during implementation.
• For Recoverable, select Yes if you want the minimum amount to be recovered from
later earnings. If you select No, the resource does not have to make up for the
amount paid.
• For the Recovery Option, select Immediate Recovery if you want the payment plan
to apply its rules using earnings that have been collected during the accumulation
period interval. If you select Delay Recovery, the application calculates recovery at
the end of the interval.
• The default recovery interval setting is Period. Based on the recovery interval, the
'true-up' of payments against compensation occurs at the end of the interval
assigned.
• For example, the Recovery Option is set to Delay Recovery, the Payment interval is
Period, and the Recovery interval is Quarter. The quarters are Jan-Mar, Apr-Jun,
Jul-Sep, and Oct-Dec. If a resource has a payment plan that is valid from February
to May, recovery occurs in March. In June, at the end of the quarter, there is no
recovery, because the payment plan is no longer in effect. The resource is paid all
earnings.
• After the payment plan is created, the Plan Administrator can immediately assign it
to a role. See Assign Payment Plans, page 5-10 for details.
Steps:
1. Search for the payment plan that you want to assign to the role.
You can also create a new payment plan before making the assignment.
Prerequisites
❒ The payment plan must already be defined by the Plan Administrator.
Steps:
1. Query for a resource.
5. Select a payment plan. Some or all of the data fields may populate with data.
7. Check the Prevent Automatic Override box if you want to maintain any custom
settings you make.
8. Click Save.
The main transaction types for which events are processed are:
• Order
• Invoice
• Payment
• Clawback - If an invoice due date goes beyond the set grace period, an offset for the
sale is created against the resource's sales credit for the previously collected invoice.
• Credit and Debit Memo - Generated when an invoice is fully or partially reversed
and posted to Oracle General Ledger.
• Manual
• Writeoff
Standard Collection
Oracle Incentive Compensation is delivered with two predefined transaction sources
which allow the collection of data from Oracle Receivables and Oracle Order
Management. Collection from these two seeded transaction sources is known as
Standard Collection.
You can collect transactions from sources other than the seeded Standard Collection
Sources. See the Oracle Incentive Compensation Implementation Guide for procedures for
setting up this process.
In Standard Collection, some of the setups are shipped with the application. These
setups, source tables and queries, cannot be modified for Order Management or Oracle
Receivables.
Both of the standard transaction sources are delivered with a set of mappings to
populate the important columns in CN_COMM_LINES_API. You are allowed to change
source values for these mappings and also to create new mappings of your own. See the
Oracle Incentive Compensation Implementation Guide for the procedures.
Use the Collection - Transaction Sources page to determine which Oracle Receivables or
Order Booking events you want to generate transactions. The two standard transaction
sources are already built into the table as Receivables Posting and Order Booking.
As a convenience, Oracle Incentive Compensation groups five separate transaction
3. Select Yes next to each event for which you want to collect. You can select No next
to events for which you do not want to collect.
4. Click Save.
Collection Features
Oracle Receivables
The predefined Receivables data source is slightly different from any other data source
because it really represents five transaction sources which have been combined into
one, so that they can share a set of mappings. The five sources are referred to as
Receivables Events and are as follows:
• Clawbacks
• Invoices
• Revenue Adjustments
• Writeoffs
For clawbacks, if an invoice due date goes beyond the set grace period, the credit for the
sale is deducted from the resource's sales credit. A credit memo is generated when an
invoice is fully or partially reversed and posted to Oracle General Ledger. Credit
memos are later collected and applied against transactions. You can collect revenue
adjustments that were made in Oracle Receivables using the Revenue Adjustment
Module (RAM). A giveback is a past due invoice that had been taken back but has now
been paid. For writeoffs, a sale is written off the books and posted to Oracle General
Ledger.
These events occur when the relevant transaction is posted to the Oracle General Ledger
application.
The transaction collection queries for these events are all based around the same core
set of Receivables source tables, but the tables are joined together in different ways so
• Collect Clawbacks
• Collect Writeoffs
Navigation
Compensation Manager > Collect Transactions
Select the transaction type and start and end periods when Receivable --Trx Source is
selected.
Oracle Order Management
There is a single collection package which is called by a dedicated concurrent program--
Collect Orders. The concurrent program requires two parameters: Start Period and End
Period. The parameter entry is supported by a list of values.
Order information can be, and often is, changed after the order has been set to the status
of Booked. Such changes, known as adjustments, can be automatically applied to
transactions which have already been collected. If a change is made to any line on an
order, then all of the sales credits (compensation transactions) for that line are
considered to be changed.
There are two possible scenarios:
1. The compensation transactions have been collected but have not been loaded into
Oracle Incentive Compensation.
2. The compensation transactions have been collected and also loaded into Oracle
In scenario 1, the transactions have only got as far as the CN_COMM_LINES_API table.
In this case the original transactions are marked OBSOLETE and they will be re-
collected into CN_COMM_LINES_API with their new values the next time Collect
Orders is run.
In scenario 2, the transactions are already loaded into the application in
CN_COMMISSION_HEADERS and may already have been used to calculate
compensation for a resource. This requires a different approach. The original
transactions in CN_COMMISSION_HEADERS are marked FROZEN. For each of these
a reversing transaction is also created in CN_COMM_LINES_API. This is a duplicate of
the FROZEN line, but with an opposite polarity (usually meaning it becomes negative)
on the transaction amount. This transaction has the effect of reversing out the original.
Finally, as in scenario 1, the compensation transactions for this line will be re-collected
into CN_COMM_LINES_API with their new values the next time Collect Orders is run.
Each time Collect Orders is run, the list of unprocessed updated Order Lines must first
be processed. This can take a long time. To avoid this, when running Collect Orders it is
a good idea to process this list of updated order lines at regular intervals, perhaps daily.
Use the Order Update Notification concurrent program to do this.
Oracle Transportation Management
Oracle Transportation Management creates work invoice for a driver and sends it to
Oracle Incentive Compensation to calculate the compensation pay. Oracle Incentive
Compensation process the data based on the information it receives from Oracle
Transportation Management, for example:
• Weight
• Miles
• Load
• Type of Truck
• The Process Log page shows the details of the processing of a request.
• Transactions collected for a specific period cannot be collected again for the same
period unless the collected_flag is set back to N or the records are physically
deleted.
Collecting Adjustments
• Collecting Adjustments for Order Transactions, page 6-8
The next time Collections is run for this Transaction Source, reversing transactions will
be created to nullify all of the sales credits associated with this transaction line. All of
Navigation
Compensation Manager > Collect Transactions > Collect Revenue Adjustments
Notes
• The parameters provided here indicate the period during which the RAM
adjustments were made, not the period that the transaction's processed date
belongs to.
The following three profile options are set automatically if you run AutoConfig. All of
them set the following default value at Site Level.
• OIC: SQL Loader Server Side Data File Directory - Set to @ "%s_applcsf%
/inbound/%s_contextname%".
After AutoConfig runs, some profile values will appear differently, as follows:
%s_applcsf%/inbound/%s_contextname% /u01/proddb/admin/inbound/cn
APPLCSF /u01/proddb/admin
After you change the setting of a profile option, you must bounce the server to reset it.
Defining Imports
You can define imports.
Navigation
Compensation Manager > Tasks > Import/Export
Prerequisites
❒ The source file must have data delimited in one of the formats recognized by the
Transaction API (comma, double quote, single quote, semicolon, space, or tab).
Steps :
1. Click New Import.
3. Enter a unique name for the import process and an optional description.
7. Check the File Header Exists box if there is a header on the source file.
Mapping begins at the first column, so it is important to specify if your source file
9. Optionally, use the fields at the top of the page to load an existing mapping or save
a new mapping.
10. To create a new mapping, click a source field in the first column to highlight it.
12. Click the right arrow button to move the mapping to the third column.
13. View the Preview window to see what your mapping looks like.
This page displays details of transactions that have been imported, including User
Input Data File Names Server Side Data File Names, and an Import ID number.
This information is useful for tracking the history of previous imports and for
finding the location of the original spreadsheet.
17. If the information is not correct, click Cancel, and then return to the Import Header
Mapping page to make corrections.
18. Click Finish to go to the Imports Search page. You can check there to see if your
import was successful.
Restrictions
If the source file is created using Excel and saved with a CSV file extension, the data will
automatically be delimited with commas by Excel. If you want to update the source file
and remove any rows, select the row(s) and use Edit > Clear > All to remove the data.
This will clear the data and the delimiters. Manually deleting each cell will not clear the
delimiters. Failure to do so may cause the import to fail. This issue may also arise when
using other spreadsheet applications.
In order for dates to appear correctly when you import data into Oracle Incentive
Compensation, you must change all date fields to text fields. Also, you must specify all
years as four-digit numbers, for example, March 13, 2007 should appear as 13-Mar-2007,
not 13-Mar-07.
The number of fields throughout the CSV file must remain the same. For example, if the
A problem can occur when you try to import a revenue class that has a name that
contains more than 30 characters. A revenue class name has a maximum length of 30
characters, whether it is created or imported. To fix the problem, shorten any revenue
class names that are longer than 30 characters and rerun the import.
Process Log
To view a process log for an import or export, click the icon in the Log column. You can
view the Process Log in five ways:
• All: Shows the complete process log.
• Debugs only: Shows debug information only (which can be quite lengthy).
• Milestones only: Shows the status of the import process (such as Staged or
Completed).
Steps:
1. Click the Download to CSV File image icon to download the records to a CSV file.
3. Create a new import using the corrected CSV file to load the data into the
application.
• Enter an import date if you want to restrict your search to one specific day.
• The application allows for three levels of sorting. In the three fields on the left side,
choose your sort parameters from the drop-down lists. The drop-down lists contain
the columns in the Displayed Columns area. Select ascending or descending order
for each sort parameter from the drop-down lists on the right side.
• If you want the report to be the default that appears in the Saved Searches field,
• If you want to modify a saved search, make the changes and click Save. You cannot
modify a predefined search, but you can rename one and save it, and then apply the
changes you need to it and resave the search.
Exporting Data
Just as data can be imported from CSV files, it can be exported from Oracle Incentive
Compensation to a CSV file.
You can export hierarchies and expressions by navigating to Transaction >
Import/Export (see below). You can also perform this export by using the Import/Export
subtab in the Quota tab.
Navigation
Compensation Manager > Import/Export
Steps:
1. Enter type, name, and optional description.
3. Select a set of source fields and use the arrows in the middle of the page to move
source fields into the mapped fields box on the right.
4. You can load an existing mapping instead of creating a new one. This can save you
time.
7. On the Review page, verify that the general information and mapping on the page
are correct.
1. If all the information is correct, click Export. The Confirmation page appears.
2. If the information is not correct, click Cancel, and then return to the Export
Definition page to make corrections.
Maintaining Transactions
The Compensation Manager or Compensation Analyst can review and make
adjustments to collected transactions. Adjustments can be made before, during, and
after the calculation process. Also, if a collected transaction contains errors in
information or credit assignment, the Compensation Manager or Compensation Analyst
can correct them.
Note: After transactions have been run through the Crediting process through
integration with Territory Manager or the Allocation process in Oracle Incentive
Compensation and have been manually adjusted, these adjusted transactions are not
picked up by the allocation engine to be reprocessed. The adjusted transactions can
however, be run through calculation.
Navigation
Compensation Manager > Maintain Transactions
Steps:
1. Search for the transaction you need. An Operating Unit is required.
To add greater granularity for your search, click the Advanced Search button.
2. On the Transactions page, click the appropriate button for the type of action you
want to perform:
• Click the Create button to open the Create Transaction page, where you can
create a new manual transaction. See Create a New Transaction, page 6-21.
• Mass Update: Click this button to get to the page where you can move
multiple credits from the existing credited resource to a different resource that
you specify. See Move Credits, page 6-23.
• You can also split a deal on this page. This feature allows you to split the sales
credit for an entire deal, which may include more than one transaction line.
Note: The radio button for Deal Split appears only when you query a specific
invoice or order transaction number. See Deal Split, page 6-24.
4. To split an individual transaction, click the Split icon next to the transaction you
• If the transaction is only collected and loaded, the transaction is cancelled, and data
from CN_COMMISSION_HEADERS is deleted; data in the INTERFACE table is
retained for auditing.
• If the transaction is collected, loaded, and processed in the roll up manner, then the
roll up job creates indirect credit transactions based on the roll up hierarchy. So to
cancel the transaction, the statuses of rolled up transactions are verified, and if they
are not POSTED to Payments, then the transaction and it's rolled up transactions
are cancelled. If any of the transactions or the dependent transactions are POSTED,
the transaction cannot be cancelled.
Please note that the following cancellation scenarios are valid for manual or collected
transactions:
• Transactions with Status: Roll
Restrictions
You cannot split nonrevenue, obsolete, frozen, or reversal transactions.
2. 2. Check the process date of the transaction to make sure it falls within a valid rule
set date range.
2. The resource is not associated to a compensation group. The resource might have
been assigned a group at an earlier time, but some setup change occurred and the
resource is no longer associated to a compensation group.
3. If the resource on the transaction belongs to more than one organization (OU) and
is in more than one group hierarchy, make sure the Multi-Org role-up profile, OIC:
Multi Rollup Path, is set to Y (not Yes or yes); also make sure the profile is not end-
dated.
4. Make sure that the Sales Compensation Role that is assigned to the resource has
either the Member or Manager box checked.
5. Make sure that the Resource Group role is defined and the transaction process date
is within the range of group role dates.
6. Check to ensure that the Group has a usage type of Sales Compensation.
2. Make sure that the classification rule is included in the product hierarchy, if using a
hierarchy in the plan element.
3. Check that the product hierarchy is not end dated prior to the current period
ranges. The transaction process date must also fall within a valid Hierarchy date
range
4. Make sure that the product (or child of the parent class) assigned to the transaction
is included in at least one plan element that is used in the resource's compensation
plan.
5. Be sure to check the compensation plan status. If the compensation plan was edited,
the plan may be in an incomplete state.
6. If the resource's sales position is end dated in the current period before calculation
occurs and after the load process occurs, then population will not occur. Check the
resource sales role dates.
2. Check the data on the transaction to ensure that values expected by the formula are
not missing.
3. Check the values used in the formula (input or output expressions) to make sure a
divide by zero error has not occurred.
6. Check the interval settings for the current interval and year being processed for the
plan element. Period interval values must be unique when calculating using an
interval-to-date formula.
7. Make sure that there are compensation plan and or quota records created for the
period the calculation is being processed. The records may be missing because the
customize flag for the plan element is checked and the quota was not entered
and/or distributed for the resource's plan element.
8. 8. If using incremental calculation, make sure the system profile, Mark Events, is set
to Yes.
• All the entries in DFFs that are in the Create Transactions page or Update
Transaction page have been validated using the classification and dimension
settings from Configure Columns and Tables entries.
• The reason field supplies an explanation of why the manual transaction was
created, for anyone reviewing the transaction later.
• In the Processing Information section, you can select which phases of calculation
you wish to run. You can skip any of the following four phases by unchecking the
box beside it. The following list describes examples of possible reasons for skipping
a calculation phase and the dependencies that exist if you do skip the phase. For a
general explanation of the phases of calculation, see Phases of Calculation, page 7-
2.
• Perform Classification: If you want to specify a different eligible product for a
transaction than the standard one, you may not want to classify it through the
normal process. However, if you uncheck Perform Classification, you must
supply the eligible product information or the transaction will fail calculation.
• All adjustments made when creating a new transaction must be loaded before they
are available for calculation.
• If you want to create another new transaction using the same basic information as
the current transaction, click the Create Another button. This saves time, because
you do not need to reenter data, and also enhances accuracy.
Steps:
1. Search for the CN_COMMISSION_HEADERS table.
2. Select the table name in the results. The columns are displayed in the table below.
3. Select the Classification view from the View Column drop-down list.
4. Choose an unassigned Attribute field and type in the column name that you want
5. Check the Classification and Search box in the same row as the new user name for
the column. This indicates to the application that you want to use the field for
classification.
6. You may also display this column in the search results page by checking the
Display in Results flag.
Mass Updates
Sometimes you need to adjust a group of transactions. Use the Mass Updates function
for this purpose, for example, when the sales credit for a number of transactions has
been erroneously assigned to a resource.
This feature maintains the history of the original transaction or transactions while
displaying the corrected transactions.
You can also use the Mass Updates function for splitting a deal. See Deal Split, page 6-
24 for instructions.
Navigation
Compensation Manager > Maintain Transactions > Mass Updates > Adjust
Prerequisites
❒ All adjustments made with the Mass Updates process must be loaded before they
are available for calculation.
Steps:
1. Query for transactions.
3. In the Name area, enter the Resource Name you wish to assign these transaction to.
Enter a Customer Name if you want to update the customer name for these
transactions.
4. In the Attributes area, enter any information that you want to update for these
transactions. Customer and the attributes are updated on the adjusted transactions.
If the original resource is still eligible for sales credit, he or she must be specified as
a credit receiver.
6. Click Apply.
Steps:
1. Query a specific transaction by order number or invoice number to activate the Deal
Split button on the Apply Mass Updates to Transactions page.
5. Click Apply.
Restrictions
You cannot have only nonrevenue types in a deal split if the original transactions are of
revenue type. A deal split with only nonrevenue types is possible only if the original
transactions are of nonrevenue type.
All revenue transactions in a deal split must add up to 100%. The total split of the split
transactions should equal the split percentage of the original transaction.
Adjusting Transactions
Sometimes you need to adjust a transaction, for example, if a mistake has been made
when the data was entered. The Adjust Transaction page
Navigation
Compensation Manager > Maintain Transactions > Update
Prerequisites
❒ Transaction must already exist.
Steps:
1. Use the search parameters to find the transaction that you want to adjust.
2. Click the object link for the transaction that you want to adjust.
4. At the bottom of the page, you can select one of three subtabs to view Commission
Lines, Transaction History, or Notes:
• Commission Lines: Use to check the transaction status, calculation status,
commission amounts.
• Transaction History: Displays any changes that have been made to the
transaction.
• Notes: Enter a reason and comments to explain changes for future review.
5. Click Apply.
Adjust Statuses
There are many statuses for transaction adjustments. The table below lists them, with
meanings and notes.
SCA_NOT_ELIGIBLE Not Eligible for Credit (1). The original transaction was
Allocation adjusted after it was processed
by credit allocation. (2).
Order/Invoice line is adjusted in
the source system and collected
into OIC after the order/invoice
line was processed by credit
allocation.
SCA_DISTINCT_ERROR Error - More than One Distinct Transactions for the same
Set of Mapping Columns order/invoice line have
inconsistent attribute values
which will be used for credit
allocation.
Split Transaction
The Compensation Manager or Compensation Analyst can distribute sales credit in
whole or in part between one resource and another or among a group of resources by
using the Split Transactions feature.
You can split sales credit for a transaction differently depending on the transaction split
percentage of the transaction. This percentage is assigned to the transaction when it is
created or as an adjustment. It is already part of the transaction before any splits are
performed.
A transaction split percentage of 0% is the default setting. If the setting is 0%, then any
amount can be used when you split sales credit.
If a transaction split percentage is assigned, any split must add up to that percentage.
Steps:
1. Query for the transaction that you want to split.
3. Select the names of the resource with whom you want to split the credit.
6. Click Apply.
Examples
You want to split sales credit for John's transaction to Steve and Bill. If the
transaction split percentage is 0%, then any split percentages are allowed. So, you
can give 60% to Steve and 75% to Bill or 25% to Steve and 40% to Bill. Or, you can
assign 100% to John and 5% to Steve and 5% to Bill. The percentage amount can add
up to more than 100%.
If the transaction split percentage is set to 100%, you can give 75% to Steve and 25%
to Bill, or 50% to both, but you cannot give 60% to Steve and 50% to Bill (110%) or
40% to Steve and 35% to Bill (75%). It must add up to 100%.
If you decide to split Steve's 75% from the previous example between Cameron and
Dave, you can give 40% to Cameron and 35% to Dave, or 70% to Cameron and 5%
to Dave, but whatever the percentages you choose, they must add up to the 75%
transaction split percentage of Steve's original transaction.
Restrictions
All adjustments made with the above process must be loaded before they are available
for calculation.
• Select Run Load only if the amount of transactions to be calculated is small or there
are only a few salespeople. This type of loading freezes up the application so you
are unable to do anything else until it is complete.
• Select the Schedule Load option to run the loading if the load is large. It runs as a
background process in the Concurrent Manager, so you can use the application for
other tasks. You can enter a name for the request to simply finding it after loading is
complete.
When you schedule a load, you can choose to run it as soon as possible or at a
specific later time and date. If you want to set up a more specific schedule, click
Advanced Schedule. You can create a schedule, and name that schedule.
You can select notification recipients as part of the Schedule Load process. You can
specify under what conditions the recipients should be notified.
• You must specify a revenue class for a transaction before loading the transaction.
• Enter a resource name if you want to load transactions only for a specific resource.
• Check the Perform Classification and Rollup box if you want to perform
incremental calculation for the transactions you are loading. That means that only
transactions that are new or have been changed are loaded.
• Collection from custom sources of data using the standard collection feature.
• Importing data from a spreadsheet (see Defining Imports, page 6-12 and the
following pages).
INV: Invoice
• ERROR - PRIOR ADJUSTMENT: This means that the value of the collection
parameter Allow Prior Period Adjustments? has been set to No and the transaction
processed_date has a column value that is less than the last processed transaction
processed_date. To resolve this, perform the following:
1. Make sure to set the parameter to Yes so that the system can process prior
period adjustments.
• ERROR - TRX_TYPE: This means that the trx_type column value of the transaction
is not a system recognized transaction type. The possible values for this column are
Claw Back, Credit Memo, Give Back, Invoice, Manual Adjustment, Booked Orders,
Payment Received, or Write Off. To resolve this, fix the trx_type value on the
transaction.
• ERROR - REVENUE CLASS: This means that the revenue_class_id column value
provided on the transaction is not defined in the system. To resolve this, make sure
that the revenue_class_id value populated on the transaction refers to the revenue
class defined in the system.
• ERROR - NO EXCH RATE GIVEN: This means that the transaction currency is
• ERROR - INCORRECT CONV GIVEN: This means that no value has been given to
the transaction_currency_code column and the exchange_rate column but the value
of the transaction_amount is not equal to acctd_transaction_amount. To resolve
this, make sure that the transaction's transaction_amount column is not a functional
currency based value, and then provide values for the transaction_currency_code
and exchange_rate columns. This error should not occur if you are using
SQL*LOADER or importing a spreadsheet. This is because the
acctd_transaction_amount is not required in those cases.
• SALESREP ERROR: This means that the process did not find any resources defined
in the system for the given employee_number column value or salesrep_id column
value. To resolve this, perform the following procedure:
1. Make sure the employee_number or salesrep_id column is populated with a
value in the API table. If you are using SQL*LOADER or a spreadsheet, only
employee_number needs to be entered.
• PERIOD ERROR: This means that the given processed_date column value on the
transaction does not fall within the compensation period start date and end date
that is defined in the system. To resolve this, do the following:
1. Provide a value for the column processed_date on the transaction for which the
compensation period start date and end date are defined in the system and also
Open.
2. Verify that the compensation period start date and end date are defined in the
system to include the processed_date column value on the transaction.
• SCA_PENDING: The transaction has been transferred to the Sales Credit Allocation
engine but has not been processed yet.
Additional Note
The Reload Errored Transactions parameter (Configuration Workbench > Collection >
Setup Collection Parameters) allows you to decide whether or not to attempt to load the
unloaded transactions which failed to load in prior attempts. The default value for this
parameter is No. When the parameter is set to Yes, the transaction interface loader
attempts to load the transactions that failed to load in prior loads.
If API transaction data are populated through Collection or created through Maintain
Transaction, the data is always valid. Invalid data, in most cases, are introduced into the
API table by a direct upload into the API table from an external source.
For example, suppose that the invalid salesrep_id, invalid employee_number or both
columns are null. For such invalid transactions, the loader sets the Load_Status to
SALESREP ERROR or PERIOD ERROR, respectively. To fix this problem, correct the
data and then set the Reload Errored Transactions parameter to Yes so that these error
transactions can be picked up again in the next run of the load process. Because this is
an expensive operation, the parameter should be set to Yes only if errors have indeed
been fixed in the transactions that could not be loaded.
Phases of Calculation
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.
• 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.
• 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).
• 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.)
• 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.
3. 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.
4. 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.
5. 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.
6. Make sure that the Sales Compensation role that is assigned to the resource has
either the Member or Manager box checked.
7. Make sure the resource's Sales Compensation role is a Group Member role for the
date of the transaction.
8. Make sure that the group the resource is assigned to has the usage of Sales
Compensation.
• All columns used in the formula to calculate are populated for the transaction.
• 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.
• 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.
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
• 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%:
0-100 1%
100-500 3%
In this case, the commission derived from the aggregated transaction is different from
the commission derived from individual transactions.
Two Parameters
Note: After you change the setting of a profile option, you must bounce the server to
reset it.
0-100 1% 1.5% 2%
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
• Cumulative: Yes
• ITD: No
• Split: No split
1 50 1000
2 100 2500
3 500 4000
0-100 1% 1.5% 2%
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
• Cumulative: Yes
• ITD: Yes
1 50 1000
2 100 2500
3 500 4000
Submitting Calculation
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.
Prerequisites
❒ Transactions must already be collected and loaded.
Steps:
1. Click Calculate Compensation.
6. Check the Incremental Calculation box if you want to run incremental calculation to
process the pending changes made to the system. The default value of the
Incremental check box depends on the value set for the profile option OIC:Enable
Incremental Calculations. See: Profile Options, Oracle Incentive Compensation
Implementation Guide.
7. 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
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.
• Schedule Calculation: Sets up a concurrent request, and is best for big jobs that
can run in the background. See Restrictions for more information.
2. 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
3. If you selected Specific Resources you must enter the specific resources for
whom you want to submit a calculation.
2. Select a resource from the list of values. Create more blank rows as needed.
3. Check the Include Hierarchy box if you want to run calculations for the
resource and all of that resource's subordinates.
4. When you have finished entering names, run or schedule the calculation.
11. If you are scheduling calculation, proceed through the six-step procedure. Click
Next between steps, and after you have reviewed the submission, click Submit.
12. 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.
13. After the calculation batch Information page displays, click OK to return to the
Requests page.
14. Click the Details icon to see more information, including Diagnostics.
Restrictions
The Status field displays the status of the calculation using these values:
• Incomplete: The calculation has not been submitted.
• Failed: An error has occurred. You can run the calculation again, if necessary.
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
Resubmitting 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.
• Classification
• Rollup
• Population
• Calculation
Any changes occurring to the following elements could cause the need for recalculation:
• System Parameters
• Classification Rules
• Product Hierarchy
• Formulas
• Rate Tables
• Plan Elements
• Start date, end date
• Eligible Products
• Transaction factors
• Compensation Plans
• Interval number
• Salespeople hierarchy
• Payee assignment
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.
The profile option OIC: Enable Incremental Calculation determines the default value of
the Incremental Calculation check box. If you set the profile option as No, the check box
is defaulted to unchecked to represent Full Calculation. If the profile is set as Yes, then
the Incremental Calculation check box is defaulted to checked to represent Incremental
Calculation.
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.
• 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.
• In the Attribute Properties area, you can click a selection once in the Available
• 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.
• The submission and approval of the payments (if approvals are used)
4. The paysheets are approved using the Payment Analyst hierarchy. The member
type Analyst locks and submits the payment sheet, the manager type Payment
Analyst approves the payment sheet (s). After the payment sheet is approved it can
be rejected if necessary.
5. After all of the paysheets in the payment batch have been approved, the payment
batch can be paid. All paysheets must be approved before the batch can be paid.
The table below describes the process of creating, approving, and paying a new
payment batch.
3. Compensation Analyst views and adjusts Paysheets : <batch name> Detail icon
paysheet details
Tasks > Maintain Payment Batch > Search >
Paysheets
4. Compensation Analyst locks paysheet Paysheets : <batch name> Detail icon > Lock
button
5. Compensation Analyst submits paysheet to Paysheets : <batch name> Detail icon > Submit
Compensation Manager
Tasks > Maintain Payment Batch >Search >
Paysheets icon OR Tasks > Maintain Payment
Batch > Search > Multi-select > Submit button
6. Compensation Manager approves or rejects Tasks > Maintain Payment Batch > Search >
paysheet Paysheet Icon > Muilti-select > Approve OR
Tasks > Maintain Payment Batch > Search >
Paysheet Icon > Detail Icon > Approve
7. Compensation Manager runs a pay Tasks Maintain Payment Batch > Select
payment batch request Payment Batch > Pay
Steps:
1. Click Export to download the payment batches.
3. If you want to perform this at the resource level, you can view the paysheets first,
click the Paysheets icon, and then click Export.
To get the resource payment detail information, click the Detail icon. You can then
export the details to a .csv file if needed by clicking Export.
Pay Groups
In order for resources to receive payment, they must be assigned to a pay group and a
compensation plan that are effective for the period for which the payment batch is
created. This is how the application determines if a resource is qualified to receive
compensation.
To create a pay group, a Compensation Manager or Compensation Analyst can
navigate to Maintain Pay Groups > Create.
SeeAssign Pay Groups, page 5-5 to assign a pay group to a resource or a role.
All Payment Batches: The user can perform the action on the payment batches if the
status of the payment batch allows it.
* For a payment batch level action such as Refresh Payment Batch or Create Paysheets
for Payment Batch, the user can refresh or create paysheets for all resources included in
the pay group, not only for the resources to which the user has access.
Remove Yes No No No
Paysheet
Update Paysheet No No No No
(Calculated,
Manual
Payment)
Remove No No No No
Paysheet
Lock Paysheet No No No No
Refresh Paysheet No No No No
Approve No No Yes No
Paysheet
• You can only have one open payment batch per pay group at any one time. The
application will not allow you to create a new payment batch until the status of any
previous payment batches for the pay group is Paid.
• You can only create payment batches for the last period paid or a future period.
After you have paid a payment batch for one period you cannot go back to the
previous month to create a payment batch for the pay group.
• It is possible to have more than one payment batch for the same pay group in the
same period as long as you have paid the first one. This is known as an off-cycle
payment.
• The pay date of the payment batch must be within the mapping date range of the
pay element and the plan element for the pay element name to be displayed on the
Transactions page.
You can execute the Synchronize Subledger Balance concurrent program to synchronize
the accumulation balances for a salesperson. The only parameter for this concurrent
program is Salesperson Name. This concurrent program synchronizes accumulation
balances for a salesperson for all open periods.
Steps:
1. Query for a payment batch.
You can click Save Search to create a view, or custom search.
2. For unpaid payment batches, check the box in the Select column if you want to
perform an action. Then, select an action from the Actions drop-down list and click
Go.
3. Click the link in the Name column to go view the Payment Batch Summary.
4. Click the View Paysheets icon to go to the Paysheets: <payment batch name>
summary page. Many actions can be performed on this page. See Working with
Paysheets , page 8-14 for details.
Restrictions
If you are logged in as a Compensation Manager, the Analysts Payment Batch Total
column displays the sum of the payments that roll up to you from resources assigned to
you and from resources assigned to Compensation Analysts assigned to you. If the
Manager is at the top of the Payment Analyst Hierarchy then the total amount columns
will be identical.
The Payment Batch Total field displays the total amount of the payment batch. If you
are logged in as a Compensation Manager, the fields display identical amounts, because
you are at the top of the hierarchy.
The Payment Batches page can be sorted in ascending or descending order on any
column except for Paysheets.
• The bar graph displays the amounts of the paysheets by status. This display gives
the relative amounts of the total worksheets in each status at a glance.
• The Top Paysheets bin lists the top five paysheets by descending payment amount.
Click the Details icon to view the specific paysheet.
• The Top Transactions bin lists the top transactions by descending payment amount.
Click the Details icon to see the specific paysheet.
• The Terminated Resources area displays resources that have been end dated in
Resource Manager within the date range of the pay period. You can export this data
for review. Click the Details link to see a resource's paysheet.
Steps:
1. Check the Notes subtab to enter comments into the Notes area. These notes can be
read later to explain any changes you make to the paysheet.
3. Select a plan element name. The list includes any plan elements that are in the
resource's compensation plan.
4. Check the Recoverable box if you want the payment to be recoverable from
future earnings.
6. Click Apply.
4. Enter the amount in the Payment Amount column for the transaction line and click
Save.
6. On the paysheet, If you waive recovery the resource does not have to pay back any
payment received from a payment plan.
7. After making any changes, lock the paysheet. This must be done before submitting
the paysheet for approval by the Compensation Manager, and to prevent the data
from being changed.
Restrictions
The Pay Element Name fields are populated for transactions for which the plan element
is mapped to a pay element for use in integration to Oracle Payroll.
When you hold a transaction it is taken out of the paysheet and is not paid in the
current payment batch. It can be paid in a future payment batch.
If the Pay by Transaction profile is set to Yes (Y), every transaction is listed on the
paysheet, and the plan element and pay element can be displayed.
If the Pay by Transaction profile is set to No (N), the compensation amounts are
summarized at the plan element level. Therefore, the pay element name is displayed
• Credit holds
After a transaction has been identified to be held and not paid within a payment batch,
it may take considerable time to remedy the issue. Therefore, a held transaction may
need to span multiple payment batches. Held transactions stay in a held status until
they are manually released, so Compensation Managers and Analysts do not have to
worry about the transaction being paid.
The Payment Hold box on the Payment Transaction page must be checked and the
database must be updated. The system-generated note is attached to the paysheet and
the box remains flagged until it is manually changed to release the hold. After a
transaction is held, the amount is removed from the earnings and the paysheet total.
On the Paysheets summary page, the Held Amount column displays the aggregated
1 N 5 0 5
2 N 7 0 7
The Paysheets summary for this payment batch shows the aggregated transactions, in
the amount of $12 in the Current Earnings Due, Paysheet Earnings, and Total Paysheet
Amount columns, as follows:
12 0 0 12 12
The Compensation Manager or Analyst holds the second transaction, for $7, by
1 N 5 0 5
2 Y 7 0 7
The Paysheets summary still displays $12 in the Current Earnings Due column, but also
an amount of $7 in the Held Amount column, and the remaining $5 in the Paysheet
Earnings and Total Paysheet Amount columns.
12 0 7 5 5
The payment batch is locked and paid. If you drill down on the Total Paysheet Amount
for the Jan 07 payment batch, the held transaction no longer appears on the Payment
Transaction page.
1 N 5 0 5
For the next payment batch, February 07, there are no new transactions. However, the
held, unpaid transaction appears on the Paysheets summary in the Held Amount
column.
7 0 7 0 0
When you drill down on the total worksheet amount column, the held transaction
displays on the Payment Transaction page.
2 Y 7 0 7
If the hold on the transaction is released, the amount appears in the Calculated Amount
and Payment Amount columns and is paid by the payment batch. If the transaction is
held, then the amount carries over to the next payment batch and no payment on the
transaction is made.
If you make an adjustment to a transaction and then hold the transaction, the amount of
the adjustment is populated in the payment amount column when the hold is released
and the transaction is paid in a payment batch.
Adjust and Hold Example
In the example below, you can see what happens to the Paysheets summary and the
Payment Transactions pages when a payment analyst adjusts and then holds a
transaction.
First, the Compensation Manager or Analyst creates a payment batch. This payment
batch has current earnings due of $5.
5 0 0 5 0 5
The Payment Transactions page shows the two transactions that relate to this payment
batch.
1 N 3 0 3
2 N 2 0 2
Now, an adjustment is made to transaction 2, adding $2. You can see the $2 added to
the Adjusted Amount column in the Paysheet Summary and the Total Paysheet
Amount is now $7.
5 0 0 5 2 7
On the Payment Transactions page, for transaction 2 the Payment Difference column
shows the added $2 and the Payment Amount column grows to $4.
1 N 3 0 3
2 N 2 2 4
5 -2 4 3 0 3
On the Payment Transactions page, the N (No) in the Held Transactions column
becomes Y (Yes).
1 N 3 0 3
2 Y 2 2 4
Now, when payment batch 1 is paid, the total worksheet amount of $3 is paid. The held
amount remains $4.
5 -2 4 3 0 3
1 N 3 0 3
2 -2 4 0 0 0
The Payment Transactions page shows transaction 2, just as it was when it was held.
2 Y 2 2 4
When the held transaction is released, the $4 moves from the Held Amount column to
the Total Paysheet Amount column. The Paysheet Earnings and Adjusted Amount
columns now show the original earnings and adjustment amounts.
2 0 0 2 2 4
2 N 2 2 4
Note: The example works the same way even if the adjustment is made after the
transaction is held, in reverse order from the example.
Approving Paysheets
After a payment batch has been created, the paysheets in it must be approved by the
Manager in the Payment Administrative Hierarchy. As paysheets are approved, records
are created and stored.
The table below lists four different Paysheet Status types, with a description:
When the first payment batch is paid in a period, the data is transferred to Payroll
successfully if Oracle Integration is set up and used. For an off-cycle payment batch,
after you pay the payment batch from Oracle Incentive Compensation and before you
• Waived recoveries
• Held transactions
While the payment batch is open, compensation recalculation may take place if some
transaction adjustments were not loaded for the current or a prior period. To
compensate for this, Compensation Analysts can selectively refresh paysheets. This lets
the Compensation Analyst include changes for resources that need it while preserving
the comments and manual adjustments that they have already made for the resource.
For example, a paysheet is created for a resource with a payment plan for $1,000. If the
resource's earnings are $600, then the payment plan adds $400 to bring the total to
$1,000. However, after transactions are recalculated for the resource, the earnings are
Defining Roles
In Oracle Incentive Compensation, compensation plans are assigned to roles, and
resources are assigned a role. A Role may encompass one or more job descriptions and
job titles. Within the role type used for Oracle Incentive Compensation, roles are
assigned to resources, resource groups and resource teams. Oracle Resource Manager is
delivered with predefined roles for all E-Business Suite modules, including Oracle
Incentive Compensation.
Roles in Oracle Incentive Compensation must be the Sales Compensation type in order
to be assigned compensation plans and pay groups. The Sales Compensation usage type
must be used when creating user-defined roles to be used in Oracle Incentive
Compensation. The Compensation Manager and Compensation Analyst can define
roles in Resource Manager by using the Resource Management section of their menus.
Before a resource can be assigned a role, the resource must be given a Sales Rep Record.
See the Managing Roles and Role Types chapter in the Oracle Trading Community
Defining Resources
Resources are created in or imported into Resource Manager. For Oracle Incentive
Compensation, the resource must have a Sales Rep record to be assigned to a
compensation plan. This record is located on the Receivables tab in Resource Manager
or on the Resource tab within the 360 degree view of the resource in Oracle Incentive
Compensation. Be sure to enter a Start Date in the Date Active field and Quota Sales
Credit as the Sales Credit Type when creating the Sales Rep record.
For details, refer to appropriate sections of the Oracle Trading Community Architecture
Administration Guide.
Setting Up Payees
You can create a Payee if you want to assign payment to someone other than the
resource receiving the sales credit. For example, use payee assignment if a credit
receiver leaves the company and a new resource takes over the account.
Navigation
Compensation Manager > Resource Manager > Resources
1. Select the resource you wish to have as a payee in Resource Manager.
2. Assign the Payee role (with type Sales Compensation) to the payee/resource in
Resource Manager. Before being assigned the Payee role, the resource must have a
Sales Rep Record as well in Resource Manager.
4. Be sure that the plan element has the Paid Through Third Party option set to Yes.
• Earnings Statement
• Attainment Summary
Reports 10-1
• Performance Detail Report
The first six reports can be accessed from the Compensation tab on the Resource View
page. Three of the reports, including the Compensation Group Hierarchy Report, are
available directly in the Navigator.
Five reports are used by Incentive Compensation Users and their managers to track
their progress towards achieving their sales goals:
• Commission Statement
• Year-to-Date Summary
• Earnings Statement
• Attainment Summary
A resource can export these reports to a CSV file for use with a spreadsheet program
such as Microsoft Excel. Or, the resource can publish the report using XML Publisher.
For all of the self-service reports, RTF Word Templates and data sample files have been
delivered. These allow the Compensation Manager to redesign the look and feel of the
reports that are published in pdf format, as well as to add and delete columns to suit the
company's business needs and data. XML Publisher can be configured to work with
Workflow and Concurrent Manager so the reports can be sent out automatically.
Reports also can be published in Excel, Word, or plain text.
In addition, ten Oracle Discoverer reports are supplied with this release. Oracle
Discoverer is an ad hoc query, reporting, analysis, and web publishing tool. It is tightly
integrated with Oracle E-Business Suite Release 12. Oracle Discoverer is useful in Oracle
Incentive Compensation for creating, modifying, and executing ad hoc queries and
reports. See Discoverer Workbooks, page 10-6.
For some of the reports, when you click the link, a Resource Search page appears. Use
search parameters to get to a Resource Search Results page. A few reports display
another search parameter page after you make a selection from the Resource Search
Results page.
Attainment Summary
The Attainment Summary is a snapshot of salespeople achievement and earnings.
Achievements are shown against interval to date quota and annual quota. Earnings
totals are broken down by period to date and interval to date. This report was earlier
known as the Quota Performance report.
Commission Statement
The Commission Statement report is designed to be easily understood. It includes a
Balance Summary that shows balances, earnings, recoverable and nonrecoverable
amounts, payment due and ending balance. In the Commission Summary section you
can select details for commission, bonus, or payment adjustments. This section also
includes a graph.
Resources and their managers can access the Commission Statement report through the
following responsibilities:
• Incentive Compensation User (Self-Service)
or by using the Sales Dashboard through the Sales User responsibility in Oracle Sales.
You can select the Compensation Reporting Hierarchy usage in Resource Manager as
the Group Usage for all Sales Compensation Groups to determine user access to the
Commission Statement report. This usage makes it easier to set up reporting structures
so that managers have access to commission statements for the people that report to
them. This usage can be set up by the Incentive Compensation Administrator in the
Reports 10-3
General Parameters area of the Configuration Workbench.
Notes
• If you are logged in as an Incentive Compensation User the reporting currency field
automatically defaults to your local currency.
• The Payment Batch list of values is associated with the salesperson selected.
• In the Commission: Plan Element Details area, select a specific plan element or all
plan elements from the View drop-down list. This partially refreshes the page and
gives you the details associated with the selection.
• When you click the Export button to download the report information to a
spreadsheet, the downloaded report includes all possible columns, not just the ones
that are selected for on-screen display.
• If the Period Type is Quarter and the Period is Nov-07, then the report will display
all transactions for the quarter in which November 2007 falls.
• If the Period Type is Year and the Period is Nov-07, then the report will display all
transactions for the year in which November 2007 falls.
You can personalize the Earnings Statement Report by creating views. A view can be
created by using the Save Search button or by using the Views panel > Personalize >
Create View. After you've performed a search in the Earnings Statement Report, if you
want to save the result for future reference, a click the Save Search button. This will lead
you to the Create View page where you can specify the displayable columns, the sort
order and the search criteria. After you have saved this view, you can access it by
clicking on the Views button on the Earnings Statement report. It is advisable to create a
view which has both Period Type and Period search criteria specified. If only one of
these criteria are specified, the application will not take it into consideration.
Reports 10-5
Launching XML based WebADI reports:
1. Navigate to Plan Administrator> Compensation Plans and Components > Maintain
Compensation Plans
2. In the Compensation Plans page, select the Operating Unit. Click Go.
3. Use the Export icon to launch the XML based WebADI report for a compensation
plan.
4. Select to open or save the report as an XML file. This file conforms to the Graph
Exchange XML Format ( GEXF) and can be used with network analysis tools that
provide the visualization.
Discoverer Workbooks
Oracle Discoverer is an ad hoc query, reporting, analysis, and web publishing tool. It is
tightly integrated with Oracle E-Business Suite Release 12. Oracle Discoverer is useful in
Oracle Incentive Compensation for creating, modifying, and executing ad hoc queries
and reports.
Nine predefined Discoverer workbooks are provided in this application. For more
information on these reports, see below.
The predefined Discover reports are explained below.
Formula Definitions
This workbook shows the details of the calculation formula that is associated with a
resource's compensation plan. There are two worksheets. One worksheet shows input
and output expressions for calculation and another worksheet shows input and output
expressions used for forecasting. The worksheets identify all incomplete formulas that
have been assigned to resources and also identifies all formulas that utilize a specific
expression.
Reports 10-7
11
Sales Credit Allocation
• Can credit be based on the specific contribution of the resource to the activity?
• Product: Useful when strong product knowledge is crucial, for example, in complex
industrial machinery.
• Multiple criteria: Combines two or more of the above three territory types.
Example: the California (geography) offices of Acme Computer (customer).
A territory can have a single dedicated resource assigned to it, or it may have many
resources assigned. In other situations, a single resource may be responsible for a single
territory or multiple territories. When multiple sales resources are involved, the
Territory Assignment engine can be used to determine who receives credit during
collection for each transaction, creating multiple lines for the resources identified by the
rules. Oracle Incentive Compensation Sales Credit Allocation rules can then be used to
determine how much credit each resource receives. Optionally, the split percent can be
added to the assignment in Territory Manager, but this involves some customization to
the collection process.
The Sales Credit Allocation engine generates percentages based on the credit rules that
The sales credit allocation process is divided into two main areas:
• Credit Rules Setup
• Data Type
• Value Set
• Transaction Source
Credit rules evaluate inputs using attributes found on the transaction to determine if
credit should be split between credit receivers. Credit rules also specify the allocation
percentage by revenue type (Revenue, Non Revenue) for each role. Each resource that
shares a role receives either the allocation percentage or a proportional share of the
allocation percentage, depending on how the allocation percentages are defined.
You must assign a numeric rank to credit rules. If a transaction matches more than one
rule during processing, the application applies the rule with the lowest rank. If multiple
rules with the same rank apply to the transaction, the application uses the first one it
finds. Ranking does not have to be unique for each credit rule.
A credit rule hierarchy maintains and links rules in a logical manner. A child credit rule
automatically inherits the conditions of the parent rule.
A credit rule consists of the following:
• Name (of rule)
• Description
• Date Effectivity
• Rank
• Parent Rule
• Transaction Source
Credit rule conditions determine whether a credit rule can be applied to a set of
transactions. A credit rule can have one or more conditions. Credit rule conditions are
made up of the following:
• Attribute
• Source Transaction Column Name
• Data Type
• Value Set
• Operator
• Value(s)
Allocation percentages indicate how much revenue credit or non revenue credit each
resource associated with a role receives. You can assign one or more allocation
percentages to each credit rule. Revenue percentages are split evenly among the
resources that have the same role. Non revenue percentages can be split evenly or all
resources can receive the same percentage. The application requires that revenue
allocation add up to 100 percent. You can create, update, or delete allocation
percentages, and make them date-effective.
Allocation percentages have the following definition:
• Sales Role
• Effective Date
Notes
• The data type of the credit rule attribute must match the data type of the transaction
attribute column value or rules engine processing will fail. For example, if the data
type in the rule attribute is Numeric, the credit rule condition is Between 100,000
and 200,000, and the transaction attribute value is ABC, the rules engine will reject
the transaction, because ABC is not numeric data.
• The rules engine processes transactions in bulk, so the log does not list the specific
transactions that caused the failure.
Prerequisites
❒ The transaction source must be seeded or previously defined in the CN_LOOKUPS
table.
Steps:
1. On the Credit Allocation Rules page, click View Full Hierarchy to expose the
hierarchy.
2. click Select next to the hierarchy node under which you want to add a rule.
Example: Oracle Quoting.
6. Enter a rank.
The lower the rank number, the higher priority the rule. So, rank 1 is highest
priority. See Restrictions.
8. Click Next.
Only if Between is selected can you enter both a Value From and a Value To.
11. Enter a value in the Value From field and click Next.
Note: If the rule has an end date, then the end date of the allocation is required.
You can define allocation percentages for more than one date range. See
Restrictions. Note: Date ranges cannot overlap.
You can use the new row if you are setting up multiple date ranges. Enter
information for the second period of date effectiveness.
Note: Use a Sales type role with Oracle Quoting, which calls the
Oracle Incentive Compensation API to create the split. Use a Sales
Compensation type role for Oracle Incentive Compensation
Transactions.
15. If you want all resources that share the sales role to receive revenue credit, enter a
revenue credit percentage.
Revenue credit percentages must equal 100%.
16. If you want all resources that share the sales role to receive non revenue credit,
enter a non revenue credit percent.
You can enter a role to receive only non revenue credit.
Non revenue credit does not need to add up to 100%.
17. If you entered a non revenue credit percent, you can check the Non Revenue Credit
18. If you made changes in the Revenue Credit Percent or Non Revenue Percent
columns, click Update to refresh the total amount.
19. If you are defining allocation percentages for more than one date range for the role,
repeat the steps to set up the second date range, assign it to the sales role, and
indicate sales credit percentages.
21. Carefully review the information. If it is correct and complete, click Finish.
Changes made to a rule on the previous three pages are saved. The Rules Summary
page appears, with a confirmation message, and the new rule appears in its place in
the rule hierarchy. You can select the new rule and view the four pages that you
used to create the rule.
Restrictions
Rank is relative within a hierarchy. If two rules have the same rank but one has a parent
with a higher rank, then the rule with the higher ranking parent takes priority. The
examples below explain how ranking works.
If a single transaction matches more than one Credit Rule, the Credit Rule with the
highest rank (lowest number) is the winning Credit Rule that is applied to the
transaction.
If a single transaction matches more than one Credit Rule, and one or more Credit Rules
have the same highest Rank, then the first Credit Rule with the highest Rank is the
winning Credit Rule that is applied to the transaction. The order of matching Credit
Rules with highest Rank is undefined (depends on result set's random order).
Prerequisites
❒ The credit rule has already been created.
Steps:
1. To delete a rule on the Credit Allocation Rules page, skip to step 4.
If you need to open a hierarchy node to find the rule, click the node containing a
plus sign to drill down to greater detail.
2. To delete a rule from the Simple Search Results page, enter search parameters at the
top of the Credit Allocation Rules page and click Go. To delete the rule, continue
from step 4.
3. Click Search.
4. Click Select next to the rule that you want to delete and click Delete.
5. Click Apply to confirm the deletion or click Cancel to cancel the deletion and return
to the previous page.
Restrictions
Depending on the type of rule to be deleted (leaf-node rule or parent rule), the dialog
page contains a radio button selection. The application provides two types of parent
rule deletion--cascading and noncascading. In a cascading deletion, the parent rule and
all of its child rules are deleted. In a noncascading deletion, only the parent rule is
deleted, and its child rules are promoted to the level of the deleted parent rule.
• After performing a simple search, you can return to the Credit Allocation Rules
summary page by clicking View Full Hierarchy.
• If the table of search results is long, use the Next and Previous buttons to move
through the list.
• If necessary, you can change the parameters and rerun the search. Enter the new
parameter information or change the existing parameter and click Search.
• After you set up and process the request, you can click View Log on the to see the
Process Log.
• Transactions are loaded into fixed format input interface tables. The
CN_SCA_HEADERS_INTERFACE_ALL table holds the transaction data and
CN_SCA_LINES_INTERFACE_ALL holds the corresponding resources and their
roles.
• Seeded transaction sources are Oracle Incentive Compensation and Oracle Quoting.
You can also select any previously defined custom source.
• You can view the status of previously requested credit allocation requests.
• The Sales Credit Allocation engine generates percentages based on the credit rules
that you create. In Oracle Incentive Compensation, these percentages are then
applied only to sales credit amounts. The percentages are not applied to order line
• Sometimes, the generated percentages may not appear to add up to exactly 100
percent. This is because data that is displayed in the application is rounded to the
precision of the currency and does not display the entire precision. However, data
in the database is stored in the full precision and does add up to 100 percent. This is
the behavior of several number fields in the application and is not specific to Sales
Credit Allocation.
• You must set up the background workflow process to move the processed credits
back into the API table.
• Custom: You can add custom code if none of the seeded choices suits your business
requirements. You can use the Custom option to set up for the Workflow process to
not process the transaction.
The option is set in the system profile OIC: Allow split % less than 100%. If you do not set
the value at the application level, it defaults to the site level. If no selection is made, the
Workflow process fails.
For example, the allocation percentages for a transaction are 60% to Role 1, 20% to Role
2, and 20% to Role 3. However, during transaction processing, only two roles are
Introduction
Oracle Incentive Compensation uses modular components to build compensation plans.
All components used in the system can be configured and reused in different
combinations.
For a detailed description of the compensation plan creation process, see Overview of
Building Compensation Plans, page 4-2.
This appendix contains scenarios that show typical ways that companies use Oracle
Incentive Compensation to calculate compensation for resources. It contains all of the
valid formula combinations and illustrates how transactions are calculated using those
options.
The following table describes the fields from all five steps in the checklist, in order.
Paid Through Third Party Radio group Use if you want to assign
payment to a resource other
than the one who earned sales
credit.
Formula Definition
In addition to header-level information, formula options are organized in tabs:
• Options: Five choices affecting transactions
The following table describes fields and other components of the Formula definition
page. See Define Formulas, page 4-28.
Input
Output
Performance Measure
Rate Tables
The following table describes fields and other components of the Rate Table pages. See
Define Rate Tables, page 4-15.
Rate Dimensions
The following table describes fields and other components of the Rate Dimension page.
See Define Rate Dimensions, page 4-16.
Calculation Expressions
Use the Expression Builder to pick and choose components and operators to create an
expression. See Define Calculation Expressions, page 4-31 for details.
Scenario Management
A scenario is a end-to-end setup required to process transactions and calculate
payments. A scenario includes:
• Start and End Date
• Setup information
Search Scenarios
As a Plan Administrator, you can search for an existing scenario, in a operating unit and
perform various operation on these scenarios. Oracle Incentive Compensation supports
Simple Search, Advanced Search, and Views. Using Simple Search you can search for a
scenario using Operating Unit and/or Scenario Name. You can click Advanced Search
to search based on additional search criteria. View allows you to personalize and save
searches.
For more information on exporting compensation plans, see: Creating Export Request,
page 4-38.
A Individually No Split No No
D Individually Non-Proportional No No
For the example test case, the following Percent rate table is used for scenarios A
through H. An Amount rate table (presented later in this document) is used for
scenarios I through L.
Tier Rate
0-1,000 1%
1,000-3,000 2%
3,000-8,000 3%
8,000-20,000 5%
T1 Jan-01-2007 200
T2 Jan-2-2007 300
T3 Jan-15-2007 1,500
T4 Feb-01-2007 1,200
T5 Feb-15-2007 2,000
T6 Mar-01-2007 4,500
Now, we will describe each scenario and list the commission calculation results for the
transactions for each scenario.
T1 Jan-01-2007 200 1% 2
T2 Jan-02-2007 300 1% 3
T3 Jan-15-2007 1,500 2% 30
February
T4 Feb-01-2007 1,200 2% 24
T5 Feb-15-2007 2,000 2% 40
March
T1 Jan-01-2007 200 1% 2
T2 Jan-02-2007 300 1% 3
T3 Jan-15-2007 1,500 2% 30
February
T4 Feb-01-2007 1,200 2% 24
T5 Feb-15-2007 2,000 3% 60
March
T1 Jan-01-2007 200 1% 2
T2 Jan-02-2007 300 1% 3
T3 Jan-15-2007 1,500 2% 35
February
T4 Feb-01-2007 1,200 2% 24
T5 Feb-15-2007 2,000 3% 72
March
T1 Jan-01-2007 200 1% 2
T2 Jan-02-2007 300 1% 3
February
March
T1 Jan-01-2007 200 1% 2
T2 Jan-02-2007 300 1% 3
February
March
T1 Jan-01-2007 200 1% 2
T2 Jan-02-2007 300 1% 3
February
February
March
February
March
I Individually Proportional No No
The table below shows the Amount rate table. It uses the same tiers as the Percent rate
table used in scenarios A through H.
Tier Amount
0-1,000 10
1,000-3,000 40
3,000-8,000 100
8,000-20,000 2,000
February
March
February
February
February
March
February
March
• Bonus Compensation
This scenario uses this rate tables. Columns 2 through 4 show the commission
percentage for each state code:
0-5,000 1% 2% 3%
5000-10,000 2% 3% 4%
10,000-30,000 3% 4% 5%
30,000-999,999,999 5% 6% 7%
When the individual transactions are applied to the rate table, the first transaction falls
into the first tier of the rate table, for state code CA, so it pays commission at 1%. The
second transaction is still in the first tier, but for state code OR it pays 3%. The third
transaction falls into the third tier of the rate table, for state code NV, so it generates
commission at 4%. Total commission for the three transactions is $1,150.
This method of calculating compensation works the same if you use a multidimensional
Amount rate table rather than a Percentage table.
Bonus Compensation
A Bonus plan element has no links or references to individual transactions. Bonus
formulas calculate only against Individual transaction options. Split options are
selectable (each is mutually exclusive).
A bonus plan element uses a formula type of Bonus and a plan element incentive type
of Bonus.
This scenario uses a bonus plan that uses achievement information to calculate a bonus.
This scenario uses these expressions:
• Input Expression: Aggregated transactions
0-50 $0
50-75 1000
75-100 2000
100-999,999 1000
The bonus plan element compares the amount of the aggregated transactions with the
resource's target. The percentage of achievement determines whether a bonus is paid
and also the amount of the bonus.
2. Create a second plan element that pays a specified bonus if a specified percentage
of the target of the first plan element is met. Use a formula with an input expression
that references the achievement of the plan element created in step 1. This input
expression divides the accumulated total by the ITD_Target total, which determines
the achievement.
4. Set up a plan element that calculates commission and determines if the resource has
achieved 100 percent of her sales target. It has been kept simple for the purposes of
this example.
6. Set up the following rate table, which shows what percentage of commission to pay
on ranges of transaction amounts.
0-5,000 1%
5000-10,000 2%
10,000-30,000 3%
30,000-999,999,999 5%
7. Set up a second plan element that uses achievement information from the first plan
element to calculate a bonus.
9. Use this rate table, which uses a Percent input and outputs an Amount.
0-50 $0
50-75 1000
75-100 2000
100-999,999,999 1000
10. The bonus plan element compares the amount of the aggregated transactions with
the resource's target. The percentage of achievement determines whether a bonus is
paid and also the amount of the bonus.
Units Sold
1-100
100-250
250-999,999,999
State
California
Oregon
Washington
Combined, they become a multidimensional rate table, which pays different amounts
based on units sold and also on where the deal took place (see the setup below).
This scenario uses these two expressions:
• Input Expression: Units Sold, State
When transactions are applied to the rate table, the units sold dimension is used first,
and then the territory dimension is applied later. For the three transactions above, the
calculation works this way:
The first transaction is applied to the rate table, in the second tier, for California. This
generates commission of $200.
The second transaction is placed in the third tier of the rate table, for Oregon,
generating $400 commission.
The third transaction ends up in the first tier, for Washington, generating $400
commission.
External Table Based Expressions Used in Formula for Both Input and Output
Oracle Incentive Compensation can accommodate external tables, as long as the tables
are properly registered in the application. In this example, the commission calculation
uses legacy data from the company's Human Resources Department in the input
expression, and then uses another table in the output expression to modify commission
payment amounts.
The input expression uses an Employee Code Number. Employees with less than two
years of experience are assigned code number 1, employees with 2-5 years of experience
are assigned code number 2, and employees with 5 or more years of experience are
assigned code 3. This multiplier increases transaction amounts and can move
transactions up the rate table, paying higher commission to more senior salespeople.
The output expression uses the previous year's achievement as a ratio of sales divided
by goal. This legacy data, stored in a table in Accounts Receivable, rewards resources
who achieved or exceeded their goal last year and penalizes resources who
underachieved last year.
• Output Expression: Rate Table Result * (Previous Year Sales/Previous Year Goal) *
Transaction Amount * Employee Code Number
Here's the rate table, which uses transaction amount and commission percent.
0-5,000 1%
5000-10,000 2%
10,000-30,000 3%
30,000-999999999999 5%
Below is a Human Resources table that shows the resource name and employee code
number.
Rep 1 3
Rep 2 1
Rep 3 2
Here is an Accounts Receivable table, with resource name, sales year, sales amount, and
annual goal.
The External Input Output formula multiplies the transaction amount times the
Employee Code Number and then applies it to the rate table. The rate table result is
then multiplied times the ratio of previous year sales to previous year goal.
This is how compensation is calculated for three different resources.
Rep 1 is a long term employee who met his 2002 goal exactly.
The transaction is multiplied times the Employee Code Number
• $7,000 * 3 = $21,000
The rate table result is multiplied times the sales/goal ratio (1.0)
• $630 * 1.0 = $630
By meeting his sales goal the previous year, Rep 1 receives all of his calculated
commission amount. Note that if the Employee Code Number was not part of the input
expression, or if Rep 1 was a new employee, this transaction would fall into the second
tier of the rate table, paying 2% on $7,000, or $140. This input expression rewards
seniority and meeting previous goals.
Rep 2 has been working for the company for only a year and a half, so she is assigned
Employee Code Number 1. However, she worked very hard last year and exceeded her
goal.
The rate table result is multiplied times the sales/goal ratio (1.5)
• $30 * 1.5 = $45
Although her commission rate is lower because of her shorter time with the company,
Rep 2 increased her earnings on this transaction by 50 percent because of her success in
the previous year.
Rep 3 has worked for the company for four years, and does a good job. However, he
achieved only 90% of his goal last year, and this will affect his final commission
earnings.
The transaction is multiplied times the Employee Code Number
• $4,000 * 2 = $8,000
The rate table result is multiplied times the sales/goal ratio (.9)
• $160 * .9 = $144
Rep 2 benefited from his longevity with the company--it doubled the amount applied to
the rate table. However, he lost out on 10 percent of his earnings because he did not
meet his sales goal for the previous year.
$25,000-50,000 $1,000
50,000-75,000 2,000
75,000-100,000 3,000
100,000-999,999 5,000
For three sample resources, the calculation works this way when the bonus plan
element is applied:
For an external formula type, you must enter External in the Formula Type field instead
of Formula. You do not enter anything in the Choose Formula field, but you must enter
a PL/SQL package name to enable the application to find the external formula.
• Two audit tables (header/detail document the details of data purged including
number of rows deleted, corresponding table names, periods selected and who
columns.
Should an error occur during processing, users can correct the condition that caused the
failure, and resubmit the concurrent request that failed with the same parameters. The
procedure will recognize the previous failed execution and resume processing from
Note: It will not be possible to select a different end period until the one
that failed has been completed. The same processing is involved if the
previous concurrent request is resubmitted or a new one is submitted.
For detailed information on tables associated with the archive and purge process, see:
Archive and Purge Tables, Oracle Incentive Compensation Implementation Guide.
2. Search for and select Archive and Purge OIC Periods concurrent program.
• Select Archive and Purge to archive and purge the tables identified in the audit
report.
6. Navigate to Requests. Click the Details icon for the Archive and Purge OIC Periods
Request ID
7. Click View Log to view the concurrent program logs. The archive_status=Y and
purge_status=Y determines the successful completion of the program.
If you have run the concurrent program as Audit Only, review the tables that have
been identified for archive and purge,
If you have run the concurrent program to Archive and Purge, view the log to:
• Verify that the audit tables contain the expected data and that the counts agree
with the data in the archive tables.
• Verify the archive tables contain the data that was to be purged.
• Verify that the archived data has been deleted from the main OIC tables.
2. Verify that the table cn_arc_audit_all has one record with either archive_status=N
or purge_status=N (there should never be more than one).
3. Correct the issue from the first step that caused the failure.
5. Navigate to Requests and ensure that the process shows as successfully completed
6. Review the log. Note that the processing skips the tables that had been processed
previously and processes the rest.
To import a plan:
1. Download the compensation plan template file to your local system. The files are
stored at the relative path $APPL_TOP/cn/12.0.0/patch/115/xml.
These are the industry-specific compensation plan templates that Oracle Incentive
Compensation provides:
Distributors Cnwldistributors
4. Click Create.
5. Enter the request name and select the target operating unit where the plan is to be
imported.
7. Click Submit.
For more information on importing plans, refer Creating Import Requests, page 4-40.
After you have submitted the import request, navigate to Monitor Request, to see the
Retail Outlets
This is a sample compensation plan for retail outlets selling wireless related products.
The Retail Outlets compensation plan consists of these plan elements:
• Retail Outlets - Activation & Renewals
Distributors
This is a sample compensation plan for distributors selling wireless related products.
The Distributors compensation plan consists of these plan elements:
• Distributors - Activation & Renewals
Investment Specialists
This is a sample compensation plan for wealth management investment specialists. The
Investment Specialist compensation plan consists of these plan elements:
• Investment Specialists - Investment Product Sales
Portfolio Managers
This is a sample compensation plan for wealth management portfolio managers The
Portfolio Managers compensation plan consists of these plan elements:
• Portfolio Managers - Portfolio Performance
Accelerator
An accelerator is a type of incentive that is used in an expression to vary compensation
payout amounts. Earnings factors work on output expressions by multiplying the
compensation rate without affecting the quota. Multipliers work on input expressions,
changing compensation amounts by moving calculation to a different tier in a rate table.
Account Generation
Account Generation is an option in System Parameters that you can use to populate
account codes in General Ledger. You can select the appropriate detail level and from
where the application pulls expense and liability information. Account Generation is set
at the application level.
Adjust Transaction
Use this feature to correct errors and make any manual changes that are needed.
Allocation Percentage
In Sales Credit Allocation, allocation percentages indicate how much revenue credit or
nonrevenue credit each resource associated with a role receives. You can assign one or
more allocation percentages to each credit rule. You can create, update, or delete
allocation percentages, and make them date-effective.
Batch Mode
In Sales Credit Allocation, transactions are processed in either Batch mode or Online
mode. Use Batch mode for processing large volumes of transactions. For batch
Glossary-1
processing, call a concurrent request using the Requests tab. See Online Mode.
Bonus
A percent of base pay, or fixed dollar amount, for accomplishing objectives; may be
capped or uncapped. A bonus is typically paid for meeting a goal, including
quantitative and qualitative goals. A Bonus plan element has no links or references to
individual transactions. Bonus formulas calculate only against Individual transaction
options.
Calculation
Calculation is a process used by the application to calculate commission and bonus
plans for salespeople. Oracle Incentive Compensation supports two types of
compensation calculation--Commission and Bonus. Commission calculation is based on
transactions identified for a Commission type of plan element, which is associated with
a commission type formula. Bonus calculation is based on a Bonus type plan element,
which is associated with a Bonus type formula. A Bonus type formula has no links or
references to transactions.
There are two modes of calculation:
• Complete calculation includes all resources. It is the default setting.
• Incremental calculation runs only for those resources that have new transactions or
changes.
Calculation Phase
During the Calculation Phase of calculation, Oracle Incentive Compensation performs
calculation on all transactions within the specified parameters. It totals the credit for the
transaction, checks against the accumulated quota figure to determine the rate tier,
calculates the final commissionable amount, and updates the commission due amount.
The process calculates commission based on the Calculation Rules (defined in Plan
Elements).
Child Node
A child node rolls up to a parent node in a rules hierarchy. A child node can roll up to
only one parent node.
Classification Rules
Classification rules are user defined categories used to classify sales transactions.
Classification rules are part of a classification ruleset. Classification rules vary greatly
from one company to another, depending on the product or service provided and the
different ways that resources are compensated.
Glossary-2
Classification Rules Report
The Classification Rules report displays the Rule Name, Product, and Expression for
classification rules selected from the list on the Rules Found page. You can download a
CSV file and open it in a spreadsheet program.
Classification Ruleset
A group of classification rules assigned to a specific time period or location that sorts
transactions into preset categories, so that they can be compared to eligible products in
a resource's compensation plan. Only one classification ruleset can be active at a time.
Clawback
See Takeback.
Collection Query
The Collection Query specifies the exact tables and rows from those tables that you
need to perform a collection from a source other than the standard collection sources.
Collections
The Collections function collects the transactions it needs to calculate commission for
resources. You can collect data from different sources, based on the configuration and
mapping defined between the source tables and destination tables. Oracle Receivables
and Oracle Order Management are the seeded transaction sources in Oracle Incentive
Compensation, but you can set up the application to collect from any other source.
Commission
Compensation paid as a percentage of sales measured in either dollars or units.
Compensation Group
A compensation group is a set of resources who share sales credit, directly or indirectly,
when a sale is made. A compensation group hierarchy sets up the relationship of
different compensation groups to each other.
Compensation Period
A compensation period is the time interval during which commissions are collected.
Glossary-3
Compensation Plan
A compensation plan is a collection of one or more modular plan elements used to
calculate a compensation payment. One compensation plan is assigned to a sales role,
which is then assigned to a resource. Some parts of a compensation plan can be
customized for individual resources, such as a payment plan or pay group, and
compensation rates can be individually adjusted as well.
Compensation Transaction
A compensation transaction is a record that identifies a compensation event, such as the
sale of an item. It is the smallest unit of data on which a compensation payment can be
calculated.
Concurrent Program
Concurrent programs run in the background while you are using other Oracle Incentive
Compensation functions. For example, you can run a concurrent program to collect
transactions from a transaction source while you are building compensation plans.
Credit Memo
A credit memo is generated when an invoice is fully or partially reversed and posted to
Oracle General Ledger. Credit memos are later collected and applied against
transactions.
Credit Rule
Credit rules are defined for Sales Credit Allocation using credit rule attributes, which
you set up for each transaction source. Credit rules evaluate inputs using attributes to
determine if credit should be allocated to credit receivers. Credit rules also specify the
allocation percentage by revenue type (Revenue, Non-revenue) for each role.
Credit Type
Credit types must be defined for use in Oracle Incentive Compensation. The credit type
is normally the preset functional currency, but it can be any type that you define in the
application, such as points or air miles.
CSV File
A CSV file is a data file in which the values are delimited by commas. The acronym CSV
is used to represent Comma Separated Value.
Glossary-4
Cumulative
A type of performance cycle. A performance cycle is cumulative when the performance
of the resource is measured over subsequent performance periods.
Customized Box
Check the Customized box if you want to customize a role for a resource. If the
Customized box is checked, subsequent changes to the agreement may not affect the
resource.
Customized Flag
If you leave the Customized Flag box unchecked for a plan element, then any changes
you make to the quota or rates for that plan element are automatically inherited by the
resource. If you check the box, the contents of the customized plan element are not
affected by any changes you make to the plan element at the role level.
Deal Split
Use the Deal Split function to split up sales credit for an entire deal. You must query a
specific transaction by order number or invoice number to expose the Deal Split button
on the Transactions page.
Debit Memo
A debit memo is generated to fully or partially increase an invoice. It is posted to Oracle
General Ledger. Debit memos are later collected and applied against transactions.
Dimension
See Rate Dimension.
Draw
A draw is a mechanism to pay a resource a minimum amount of compensation for a
specified period of time. You can define the period that the draw and recovery will be
in effect by using a payment plan. As part of the agreement with resources, this amount
can be recoverable or nonrecoverable.
Glossary-5
Earnings Statement Report
This report gives you a complete look at all of the transactions for a resource for a
selected period. The columns on the report are parameters that you select in the
parameters modification page.
Expense Account
An expense account is an account type segment in Oracle General Ledger. Expense
accounts can be identified at the plan element level. Earnings for the plan element are
assigned to the specified expense account in Oracle General Ledger. See the Oracle
General Ledger User Guide for more information.
Export
See Import and Export.
Expression
Expressions are interchangeable, reusable parts that are used as input and output
expressions of formulas, in expression-based rate dimensions and in performance
measures. Input expressions tell Oracle Incentive Compensation what to evaluate from
the transactions and how to match the results to the corresponding rate table. Output
expressions instruct the application how much to pay resources.
External Formula
External formulas are used when the formula requires some data that is not in the
application. They are similar to system generated formulas, except that they contain
customized material. This means that when you upgrade the application, any changes
that were made are not automatically applied to the external formula, so they must be
applied manually. For external formulas, you must enter the name of the PL/SQL
package in the Package Name field.
External Table
Oracle Incentive Compensation can accommodate external tables, as long as the tables
are properly registered in the application.
Failed Records
Sometimes records fail during the import process. This often occurs because the content
or the organization of the record is incorrect. The Failed Records page displays any
records that failed during the import process, and the reasons for failure.
Fixed Amount
Fixed Amount is a constant amount in a compensation plan that is used for calculation
purposes. Resources do not have a view or access to the fixed amount.
Glossary-6
Fixed Component
See Component.
Formula
A formula is a set of instructions that determines how compensation is calculated.
Formulas are built from input expressions, output expressions, and rate tables.
Formulas used in Incentive Planning must be designated as planning formulas with a
specific combination of rules. For these formulas, only one input expression is
permitted. A bonus formula has no links or references to transactions. You can use an
external formula when defining a plan element. See External Formula.
Functional Currency
Functional currency is the currency in which Oracle Incentive Compensation performs
all calculations. It is the currency used by General Ledger to record transactions and
maintain accounting data for the set of books. After functional currency has been set up
for an organization, it does not change.
Goal
Goal is the amount that management sets as the actual goal expected of the resources in
a compensation plan. This amount is typically used for reporting purposes and is not
exposed to the resources.
Group By Interval
When you use a Group by interval, all transactions from a predefined period are
submitted together for calculation. This period can be a month, quarter, or year. Group
by Interval calculation requires that you check the Cumulative box. Commission is
calculated by applying the total amount of the grouped transactions to the rate table.
Incremental Calculation
Incremental Calculation marks all predefined transaction events in a notification log
Glossary-7
table known as the Notify Log. By doing this, Oracle Incentive Compensation runs
calculation only for the resources that require it.
Interval
Intervals are time periods during which a compensation or a plan element is effective.
Plan element intervals must be contained within the effective interval of a
compensation plan.
Interval to Date
Use an Interval to Date plan element in a compensation plan if you want to pay
compensation based on accumulated achievement during a specified period. This type
of plan element calculates commission based on achievement towards cumulative quota
targets, such as Period to Date (PTD), Quarter to Date (QTD), or Year to Date (YTD).
Interval Type
An interval type is the time period of an interval. Commonly used interval types are
month, quarter, and year. You can define a custom interval.
Liability Account
A Liability Account is an account type segment in Oracle General Ledger. Liability
accounts can be identified at the plan element level. Earnings for the plan element are
assigned to the specified liability account in Oracle General Ledger. See the Oracle
General Ledger User Guide for more information.
Listing Notification
During data collection, this feature makes a list of all individual transaction lines from
the transaction Source for which compensation is payable.
Manual Transaction
A manual transaction is created by a user to reverse or change sales credit.
Mapping
Mapping is the set of rules defining collection that connect the table columns of a feeder
system to the transaction columns in Oracle Incentive Compensation. Mapping can be
direct or indirect. Direct mapping uses source data from one or more of the tables in the
From clause of the Collection Query. Indirect mapping is more complex, and uses From
and Where clauses in an UPDATE statement.
Move Credits
Move Credits is used in Collections to mass adjust a group of transactions based on
criteria selected in the parameters. Use the Move Credits function when the sales credit
for a number of transactions has been erroneously assigned to a resource.
Glossary-8
Notification Log
The Notification log, also known as the Notify Log, automatically records every change
in the system that affects calculation and lists what part of the calculation must be rerun
as a result of an event. This is especially useful when performing Incremental
Calculation.
Notification Query
A notification query shows the exact query which will be used to create the Notification
list of line-level transactions which are eligible for compensation. It is used when
collecting from a source other than the standard transaction sources.
Online Mode
Transactions are processed in either Batch mode or Online mode. Online mode is best if
you want to create a manual transaction and need to find resources and their
corresponding allocation percentages in real time. For online processing, you must call
a PL/SQL API. See Batch Mode.
Open Collections
Oracle Incentive Compensation can collect transaction information from any source,
including legacy systems, provided that the other system's data can be accessed in the
same database instance.
Org Striping
Org striping means marking something, such as a role, by organization. This is used to
limit access to data to those who need it.
Parent Node
A parent node is a node in a rules hierarchy which has at least one node that rolls up to
it. A parent node typically summarizes information concerning the nodes below it,
referred to as child nodes.
Pay Group
A pay group is an assignment that determines the frequency with which a resource
receives payment. Pay group assignment is necessary for a resource to be paid. A
resource cannot belong to more than one pay group at a time. You can assign a pay
group to a role, in the same way that a compensation plan is assigned to a role.
Resources inherit the pay group when the role is assigned to them. You can perform
individual pay group assignment to a resource.
Payee Assignment
Use Payee Assignment if you want to assign the payment to someone other than the
resource receiving the sales credit. For example, use payee assignment if a credit
receiver leaves the company and a new resource takes over the account.
Glossary-9
Payment
There are three types of payment:
• Regular Payment: The application collects data, prepares it, and formats it to be
used by a non-Oracle Payable system.
• Accounts Payable Integration: Used for vendors, this method prepares payment for
Oracle Accounts Payable by classifying the resources as suppliers.
• Oracle Payroll Integration: The application collects data and creates a file that can
be used by Oracle Payroll.
Payment Group
The payment group setting enables you to assign multiple payment plans to a resource
as long as the payment groups are in different payment groups for a specific date range.
The payment group codes are customizable; the default setting is Standard.
Payment Hold
Payment on a specific transaction can be held so that it is not paid. Compensation
analysts make payment holds under the discretionary review. Reasons for payment
holds include incorrect revenue recognition, credit holds, and company policies, such as
holding high commissions.
Payment Plan
A payment plan is an optional arrangement in affect for some salespeople who need to
receive a minimum payment regardless of their earnings. You can specify a minimum
and/or a maximum payment as well as whether any minimum payments are
recoverable or not against future amounts payable. Payment recovery can be on a
separate schedule from the compensation period.
Payment Batch
Oracle Incentive Compensation uses payment batches to determine payment amounts.
The payment batch process considers:
• Who is paid
Glossary-10
• How much is paid
Paysheet
An individual paysheet displays the details of the total payment amount for a resource.
It comprises manual payments, calculated payments, total payments, and recoveries.
Paysheets are part of a payment batch.
Performance Measure
An accumulation of transaction values that is captured by a Plan Element and grouped
for use in reports that compare achievements to Quota, Goal and Performance Measure.
Performance measures are not used to calculate commission.
Period
The time span over which performance is measured for incentive purposes. The typical
period in Incentive Compensation is a month, but it can be a quarter, a year, or a custom
definition.
Plan Element
Plan elements are the parts from which compensation plans are built. Plan elements
may reflect variations of commission or perhaps a bonus based on the accumulated
achievement of the resource. Plan elements can also be configured for tracking
nonmonetary credits such as managerial points or production credits. Plan elements
consist of modular components that can be freely assigned in different combinations,
including products, formulas, and rate tables. Interdependent plan elements use the
calculated totals of one plan element to calculate for commission for another plan
element.
Population Phase
During the Population phase of calculation, 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.
Preprocessed Code
In Collections, the Preprocessed Code drop-down list contains 16 combinations of
skipping the four main phases of calculation: Classification, Population, Rollup, and
Calculation. You can also skip all phases or skip nothing. There are a variety of reasons
for skipping phases of calculation. The main benefit is saving time. See Chapter 8 for
details.
Glossary-11
Product
A product is a user-defined category of business revenue used to classify a transaction
for compensation and calculation. Products are assigned to plan elements and help
determine whether classified sales credit is applied toward a compensation payment.
Product Rules
Product rules contain one or more conditions that a transaction must meet to classify
into a given product. Product rules are combined into a ruleset.
Product Hierarchy
A product hierarchy is an arrangement of products and subproducts in which the
broadest classes are at the top of the structure.
Profile Option
Profile options enable an organization to configure the application to suit its business
requirements. Some profile options are required and some are optional. Most profile
options have preset default values that you can change as needed.
Quota
A quota is the total amount that a resource or manager is expected to sell. Management
uses quotas to distribute the organization's sales commitment to all resources.
Rate Dimension
Rate dimensions define the tiers that a rate table uses to calculate commission
percentages. There are four kinds:
• Amount: The rate tiers are amounts.
• String: The rate tiers are alphanumeric, such as product numbers or the names of
states.
Rate Table
A rate table is used to establish compensation percentage rates or fixed amounts for
different performance levels. As part of a formula, along with input and output
expressions, a rate table determines the amount of compensation based on amount or
percentage of achievement compared to quota. Rate tables can use percent or amount,
or both, to calculate commission percentages. A multidimensional rate table uses more
than one dimension to calculate commission percentages, for example, State and
Glossary-12
Product.
Recoverable, Nonrecoverable
These terms define whether compensation can be recovered from (paid back by) the
resource who receives it or not.
Request ID
When submitting calculation, 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 request.
Resource
Anyone who is set up to receive compensation in Oracle Incentive Compensation,
including salespeople, managers, and administrators.
Responsibility
People are assigned different responsibilities in Oracle Incentive Compensation to allow
them appropriate access to the application. For example, the Incentive Compensation
Super User has access to everything in the application, while other responsibilities, such
as Incentive Planning Analyst, can access only the areas in the application that are
required to perform their jobs.
Responsibility Group
Oracle Incentive Compensation uses responsibility groups to assign access privileges to
responsibilities. These groups determine which groups and resources the person
assigned to the responsibility can work on. All seeded responsibilities are already
placed in appropriate responsibility groups during installation of the application, but
any new responsibility that you create for use in Incentive Planning must be assigned a
responsibility group.
Role
A role describes a set of resources who share a common compensation structure.
Examples are Salesperson, Consultant, and Regional Sales Manager. In Oracle Incentive
Compensation, each individual resource is assigned a predetermined role, which can be
customized. Changes to a role affect everyone assigned to that role who does not have
the Customized box checked on the compensation plan. A resource can have more than
one role at the same time.
Rollup Phase
During the Rollup phase of calculation, 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
Glossary-13
lines are marked as Rolled Up.
Root Node
Root node is the highest level of a rules hierarchy. You can place as many nodes under
the root node as necessary to meet your business objectives. Oracle Incentive
Compensation provides the flexibility to create multiple root nodes.
Rules Hierarchy
A rules hierarchy sets up relationships between rules. The structure of a rules hierarchy
starts with a root, then adds one or more parent rules, and then as many child rules as
needed. A rule can have one or more child rules or siblings.
Ruleset
A ruleset is a collection of rules. There are three types of Rulesets, which are used for
revenue classification, account generation, and plan element classification.
• Revenue Classification defines the rules that are used to identify a product for each
transaction that the system processes as part of calculating commissions.
• Plan Element Classification is used to classify quotes, opportunities, and so on, for
the Projected Compensation API.
Runtime Parameters
Runtime parameters are used to narrow the range of transactions collected in a
collection package if you are using a custom transaction source. For example, a start
date and end date can be defined. The parameters are defined on the Queries page in
the setup process.
Sales Credit
An amount of revenue or nonrevenue credit that is awarded to a resource.
Glossary-14
Sales Role
See Role.
Set of Books
A set of books identifies a company or fund within Oracle Applications that shares a
common chart of accounts, structure, calendar, and functional currency. Oracle
Incentive Compensation processes incentive compensation payments according to
periods defined in a calendar associated with a set of books that is defined in Oracle
General Ledger (see the Oracle General Ledger User Guide).
Split
Components of an Incentive Planning agreement can use a split when calculating quota
against a rate table. When you split tiers of a rate table, you pay commission at the
lowest tier possible in the rate table. Splits are proportional or nonproportional. A
nonproportional split is used with rate tables that pay based on percentages of the
transaction amount. For rate tables that pay an amount instead of a percentage, a
proportional split is used to takes the amount of the transaction that falls within a tier
and divide it by the entire amount paid for that tier. This generates a percentage that
can be applied against the transaction amount in the tier.
Split Transaction
Use the Split Transaction page to distribute sales credit in whole or in part between one
resource and another or among a group of resources. You can split sales credit for a
transaction differently depending on the transaction split percentage of the transaction.
This percentage is assigned to the transaction when it is created or as an adjustment.
Glossary-15
Takeback
The amount of compensation credited for a sale that Oracle Incentive Compensation
takes back when the invoice due date grace period is exceeded. If the invoice is
subsequently paid, then a giveback can be used to restore credit to a resource.
Takebacks are sometimes called clawbacks.
Target
Target is the specific amount set for resources as their attainment amount in a
Compensation Plan. Resources have views of this figure through their contract. The
most common way that a target is used in an expression is for evaluating transactions as
a percentage of quota.
Team Compensation
If the resource on the transaction is a member of a team, then Oracle Incentive
Compensation automatically calculates compensation for every member of the team.
Teams are set up in Resource Manager. However, although team members all receive
credit for the transaction, the sales credit rolls up a sales hierarchy only on the original
transaction.
Threshold
Minimum level of performance that must be achieved to earn compensation on a rate
table.
Transaction Factor
A transaction factor stages sales credit over the life of a sale, assigning percentages of
the transaction amount to important events in the sales process, including Invoice,
Order, and Payment. Transaction factors must add up to 100%.
Transaction Filters
Transaction filters allow you to define criteria to remove unwanted transactions during
collection. Transaction filters are especially relevant to Receivables and Order
Management, because you cannot change the collection query for those standard
transaction sources.
Glossary-16
User Code Blocks
User code blocks are single or multiple PL/SQL statements (functions and procedures)
that you can insert at defined points in the Collection procedure. User code blocks can
be inserted at:
• Pre-Notification: at the beginning of the Notification query
Glossary-17
Index
calculation
A calculation phase, 7-3, 7-6
classification phase, 7-2
accelerators, 4-24, 4-24
commission or bonus, 7-7, 7-14
accumulation along multiple dimensions
definition, 7-1
example, 7-10
failed calculation, 7-4
adjustments
failed classification, 7-3
custom transaction sources, 6-8
failed population, 7-4
order transactions, 6-8
failed rollup, 7-3
adjust statuses, 6-25
incremental, 7-17
adjust transaction, 6-24
incremental Calculation, 7-2
administer compensation plans, 1-2
nonincremental, 7-1
advanced rule, 11-12
phases, 7-2
aggregate transactions during rollup, 7-10
population phase, 7-3, 7-5
allocate
preparing for, 7-7
quotas and territories, 1-2
preprocessing, 7-2
Archive and Purge, B-1
process log, 7-16
Archive and Purge OIC Periods
revert, 7-2
concurrent program, B-1
rollup phase, 7-2, 7-4
assigning compensation plans, 5-1
status field, 7-16
Assign Payment Plans, 5-10
submitting, 7-13
Attainment Summary, 10-3
two methods, 7-1
two types, 7-1
B
unprocessed, 7-3
bonus compensation, A-26 unprocessed and failure statuses, 7-3
bonus formula, 4-28 Calculation Batch Process Report workbook, 10-6
bonus plan element calculation expressions, 4-31
example, 4-22 Calculation Expressions
bonus plan elements, 4-22 Defining, 4-33
business flow, 1-1 calculation phase, 7-3, 7-6
business strategy, 1-2 calculation process, 7-4
calculation resubmission, 7-17
C calculation sort parameters
Index-1
Concurrent Calculation, 7-17 between database instances, 1-8
Incremental Calculation, 7-17, 7-17 plan component, 1-8
classification phase, 7-2 copying
Classification Rule Sets, 3-4 rate dimensions, 4-16, 4-18
collection features, 6-4 copying Compensation Plan, 4-9
collections create compensation plans, 1-2
adjustments, 6-7 create new transaction, 6-21
introduction, 6-2 Create New Transaction page, 6-22
seeded sources, 6-2 creating
submit a request, 6-6 bonus plan elements, 4-22
using RAM, 6-9 export requests, 4-38
view request status, 6-7 import requests, 4-40
collect revenue adjustments, 6-9 credit and debit memo, 6-3
Commission Statement, 10-3 credit rules, 11-3, 11-5
Commission Statement report, 10-5 creating, 11-6
Commission Statement Report workbook, 10-7 editing, 11-9
compensation analyst, 1-9 synchronize, 11-11
Compensation Group Hierarchy report, 10-2 csv file extension, 6-13
compensation groups cumulative check box, 4-29
define, 9-1 Current Estimated Payout page, 8-25
compensation manager, 1-9 customizing a compensation plan
compensation period, 6-2 resource, 5-3
compensation plan
assign on Incentive tab, 5-4 D
Communications - Wireless segment, C-1
deal split, 6-24, 6-24
date range, 5-5
define
defined, 4-2
resource groups, 9-1
Retail Banking segment, C-1
defining
Wealth Management segment, C-1
formulas, 4-28
Compensation Plan
imports, 6-12
copying, 4-9
products, product hierarchies, 3-1
Compensation Plan, create, 4-4
quotas, 4-19
Compensation Plan Eligible Product Mapping
rate dimensions, 4-16
workbook, 10-6
rate tables, 4-15
compensation plans
resources, 9-2
create and administer, 1-2
roles, 9-1
creating import requests, 4-40
defining plan elements, 4-9
Compensation Plans
deleting credit rules, 11-10
creating a view, 4-6
Discoverer 4i, 10-6
export, import, 4-37
Discoverer workbooks
maintaining, 4-7
Calculation Batch Process, 10-6
compensation transaction, 6-2
Commission Statement Report, 10-7
concurrent request, 6-2
Compensation Plan Revenue Class Mapping,
copy
10-6
in-line plan, 1-8
Formula Definitions, 10-7
plan, 1-8
Resource Assignments Overview, 10-7
plan, plan components
Index-2
Resources Not Validated for Calculation, 10-6
Resources with Pay Group Assignment I
Different than Compensation Plan Dates, 10-7
import
Transaction Details Report, 10-7
compensation plan, 4-40
Transaction Status Report, 10-7
failed records, 6-14
distribute variables, 4-20
introduction, 6-10
process log, 6-14
E import/export
earnings factor, 4-25, 4-25 personalized search, 6-14, 6-15
Eligible Products Import Compensation Plan, 4-37
assigning, 4-13 Import Definition page, 6-11
evaluate performance, 1-4 import examples, 4-42
export import requests
compensation plan, 4-38 compensation plan, 4-40
Export Compensation Plan, 4-37 imports, 6-10
exporting data, 6-16 define, 6-12
Export requests Incentive Compensation administrator, 1-6
compensation plans, 4-38 Incentive Compensation Command Center
exports, 6-10 Jeopardy by Phase Dashboard, 2-18
external elements, 4-35 Paysheet Console Dashboard, 2-14
external tables Performance Evaluation Dashboard, 2-21
scenarios, A-31 Quality by Phase Dashboard, 2-7
Recent Jobs Dashboard, 2-4
F Incentive Compensation Command Center
Overview, 2-2
failed calculation, 7-4
Incentive Compensation user, 1-9
failed classification, 7-3
incentive type, 4-10
failed population, 7-4
incremental calculation, 7-2, 7-17
failed records, 6-14
individual paysheet, 8-15
Failed Records page, 6-11
in-line plan copy, 1-8
failed rollup, 7-3
input expressions, 4-32
Formula Definitions workbook, 10-7
integrating
formula options
third party payroll system, 8-4
scenarios, A-9
interdependent plan element, 4-27
formulas
define, 4-28
L
G library, A-1
Library management, 3-2
generate button, 6-5
load transactions, 6-29
giveback, 6-3
Lock Paysheet, 8-26
group hierarchy
sales credit rollup, 1-4
M
H maintaining Compensation Plans, 4-7
maintaining transactions, 6-17
hierarchy, 7-4
manual pay adjustment, 8-15
Index-3
manual sales credit adjustments, 6-21 payment batch, 8-1
mapping approval process (graphic), 8-25
source fields to target fields, 6-11 creating, 8-10
mass update of transactions, 6-23 table of steps, 8-3
multidimensional rate tables payment batches
accumulation and splits, 7-10 paysheet status types, 8-23
multi-org strategy, 6-9 submitting for payment, 8-24
multiple input formula, A-25 view and change, 8-12
multiplier, 4-25, 4-25 payment batch summary, 8-13
Payment Difference column, 8-17
N payment hold
transaction level, 8-17
navigation, 1-10
payment plan, 8-5
nonincremental calculation, 7-1
payment plans, 8-5, 8-5
notification, four levels of tracking, 7-19
assign to a resource, 5-12
notification, track four levels, 7-19
assign to a role, 5-11
notification log
define, 5-8
triggering events, 7-21
payment setups and relationships, 8-2
notify log, 7-16, 7-17, 7-19, 7-20
Payrun Sign-Off report, 8-26
customize search, 7-20
paysheet
individual, 8-15
O
personalized view, 8-17
Oracle Order Management, 6-5 paysheets, 8-3
Oracle Receivables, 6-4 create, 8-11
Oracle Transportation Management, 6-6 paysheet status types, 8-23
output expressions, 4-33 paysheet summary, 8-14
overview pay worksheet lifecycle, 8-6
Oracle Incentive Compensation, 1-1 performance, 1-4
Performance Detail report, 10-3
P performance measures, 4-31, 4-33
pay by personalized view
transaction, summary, 8-6 payment batches, 8-13
payees personalized view for paysheets, 8-17
setting up, 9-2 phases of calculation, 7-2
pay groups, 5-5, 8-5, 8-5 plan administrator, 1-7
assign, 5-5 plan component
assign to a resource, 5-7 copy, 1-8
assign to a role, 5-6 plan component library, A-1
multiple, 5-8 plan copy and modeling, 1-7
payment plan element
Lock Worksheet, 8-26 interdependent, 4-27, A-27
manual pay adjustments, 8-15 plan elements
overview, 8-1 defining, 4-9
prerequisites, 8-5 population phase, 7-3, 7-5
Payment Administrative Hierarchy, 8-6 preprocessed code, 6-21
payment analyst, 9-2 preprocessing, 7-2
problems
Index-4
resolve revenue adjustment posting, 6-9
with transactions, 6-18 revenue allocation percentage
process log, 6-14 check and update, 11-15
process log in calculation, 7-16 revert, 7-2
Product Hierarchy, 3-3 role
products, 3-1 assign to resource, 5-5
roles, 9-1
Q rollup phase, 7-2, 7-4
rollup summarized transactions, 7-7
quotas
Rule Sets, 3-4
allocate, 1-2
Rules Hierarchy, 3-5
defining, 4-19
rules searches, 11-11
runtime parameters, 6-7
R
rate dimensions, 4-16 S
copying, 4-18
sales credit
define, 4-16
allocation hierarchy, 11-3
rate table, 4-13
sales credit allocation, 11-1
rate tables
process transactions, 11-14
assign to plan element, 4-13
transfer transactions, 11-13
defining, 4-15
sales credit rollup, 1-4
receivables event
sales role, 5-4
revenue adjustment posting, 6-9
scenario management, A-7
receivables events, 6-5
scenarios, 1-8, A-1
Recoverable check box, 8-15
search
reports
rule, 11-11
Attainment Summary, 10-3
simple rule, 11-12
Compensation Group Hierarchy, 10-2
single transaction
Discoverer workbooks, 10-6
cancel, 6-18
overview, 10-1
split
Transaction Details, 10-3
non-proportional, 4-31
Year to Date Summary, 10-4
proportional, 4-31
resolving problems
split in multidimensional rate table
transactions, 6-18
example, 7-12
Resource Assignments Overview workbook, 10-7
split tiers, 4-29
resource groups
split transaction, 6-27
define, 9-1
standard collection, 6-3
resources, 9-2
strategy, 1-2
Resources Not Validated for Calculation
super user, 8-7
workbook, 10-6
Synchronize Rate Dim Update to Sales Rep Rate
Resources with Pay Group Assignment Different
Assignment Request, 4-18
than Compensation Plan Dates workbook, 10-7
responsibilities
based on business flows, 1-4 T
responsibility tables
Incentive Compensation administrator, 1-6 predefined, 4-35
plan adminsitrator, 1-7 takeback, 6-3
Index-5
team compensation, 9-3
templates
compensation plan
Communications - Wireless segment,
Retail Banking segment, Wealth
Management segment, C-1
territories
allocate, 1-2
transaction attributes, 6-3
Transaction Details report, 10-3
Transaction Details Report workbook, 10-7
transaction factors, 4-24, 4-26
transaction interface, 6-30
Transaction Status Report workbook, 10-7
U
unprocessed, 7-3
updating
rate dimensions, 4-16
user
Incentive Compensation, 1-9
V
validation checks and resolution, 6-36
view
Compensation Plans, 4-6
export request, 4-39
viewing
export request, 4-39
import request, 4-41
view transaction requests, 6-29
W
worksheets
approving, 8-23
X
XML document, 1-9
XML Document, 4-8
Y
Year to Date Summary, 10-4
Index-6