This chapter covers the following topics:
The Collections function of Oracle Incentive Compensation imports the transactions it needs to calculate compensation for resources. It allows the collection of data from different data sources, such as Oracle Receivables and Oracle Order Management, or external sources.
Oracle Receivables and Oracle Order Management are known as Seeded Transaction Sources, and they are shipped with the application. To read about how to set up mapping to these sources for your classification needs, see Standard Collection.
You can also create your own Transaction Source mapping for collections from the database tables of any legacy or external application. This is called open collections.
Compensation periods are used to define the time period during which transactions are collected. You must open a compensation period in order to use it to calculate compensation. After compensation is calculated, you can close or permanently close the compensation period, after which you cannot calculate compensation for that period. To set up compensation periods, see the Oracle Incentive Compensation Implementation Guide. In addition, the Compensation Manager can use the Maintain Compensation Periods menu to search for the Operating Unit and Year and then change the period status to Open and save it.
Data is collected on a periodic basis by submitting a concurrent request. The concurrent request uses the mapping and rules that are defined to determine what data to collect and how to collect it. See Submitting a Collection Request for steps.
Each transaction comprises several attributes, for example, the resource's number, the amount of the sale, the sale date, the product type, and so on. A transaction may optionally contain other attributes, such as transaction currency, product identification, and customer identification. Some of the attributes can be user-defined during implementation. There are an additional 100 columns that can be used to map data to the Oracle Incentive Compensation transactions.
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.
The main attributes of a transaction are:
Type of compensation event
Identity of the person who is directly credited for the event
Value of the attainment for the transaction
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
A transaction may optionally contain other attributes, such as transaction currency, product identification, and customer identification.
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 sources into the Receivables Posting transaction source. In the Receivables Event area you can select which Receivables events you want to be collected. By excluding transactions that you do not need, you can save time in the collection process. The default value for each event is No.
To set these events to collect data:
Select the Incentive Compensation Administrator responsibility.
Navigate to Configuration Workbench > Collection > Generate Collection Packages.
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.
Click Save.
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
Payments and Givebacks
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 five different transactions sources would normally be required. The five have been combined into a single transaction source so that you only set up the mappings that you want once and they are applied to the collection of compensation transactions for all five events.
For each event for the Receivables Transaction source, you need to select the row corresponding to the event and click Generate. This will create a package for that particular Receivables event.
When the Generate button is clicked, the full package will be generated for the collection of invoices, credit memos, and debit memos. For the other four events (Writeoffs, and so on), simple stub packages will be generated, which speeds up the Generation process.
Each Receivables event has a dedicated concurrent program. Each of these requires two parameters: a Start Period and End Period. The parameter entry is supported by a list of values. The concurrent programs are:
Collect Invoices
Collect Clawbacks
Collect Payments and Givebacks
Collect Writeoffs
Collect Revenue Adjustments
Navigation
Compensation Manager > Collect Transactions
Select the transaction type and start and end periods when Receivable --Trx Source is selected.
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:
The compensation transactions have been collected but have not been loaded into Oracle Incentive Compensation.
The compensation transactions have been collected and also loaded into Oracle Incentive Compensation.
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
For more information, see: Oracle Transportation Management, Oracle Incentive Compensation Implementation Guide.
Before the Compensation Manager or Compensation Analyst can submit a transaction collection request, the collection setup must be completed and the collection package must have been generated successfully.
Start the collection request by entering basic information about it. You then proceed through a set of steps to make the request more specific. You can schedule the request to occur as soon as possible or at a future time, or to run at scheduled and regular intervals. You can also indicate whom should be notified and under what conditions they should be notified (normal, warning, error). You can specify printing information next, and then review it all before submitting it. After the request is submitted, you receive a reply
Runtime parameters are used to narrow the range of transactions collected in a collection package if you are using a custom transaction source. For the standard transaction sources you cannot make any changes to the Source Tables or Queries tabs, so the only runtime parameters available are for Start Period and End Period.
For a custom transaction source, a runtime parameter value can be defined, as needed. See the Oracle Incentive Compensation Implementation Guide for the procedures. The specific runtime parameters are not set during the collection setup, but are instead entered during the collection submission process. This allows you to change the values without regenerating the collection package.
Navigation
Compensation Manager > Collect Transactions
Notes
The Collect Orders collection type collects data from Oracle Order Management. The other events collect data from Oracle Receivables. The Collect Custom Transaction Sources collection type collects data from external sources.
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.
After you complete the request submission process, click OK and the Requests page displays. If there is an X in the Status column next to the request, an error has occurred. Find the request number and click the Details icon to view the details of your request. On the details page you can hold or cancel the request. Click the View Log button to see the specifics of the request, including any errors.
Navigation
Compensation Manager > Collect Transactions > OK
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. See Special Features for a complete explanation.
You can make adjustments to transactions in your custom Transaction Sources in the same way as standard Collections from Oracle Order Management does. All you need to do is to call a Collections API, identifying the transaction that has been changed.
If you specified a Header Table on your Source Tables tab then you need to pass the unique identifiers of both the Header record and the Line record of the changed transaction. Otherwise only the identifier of the Line record is required.
Suppose that Collections has already been run for October 2001 transactions in the example legacy system. Also, those transactions are already imported into Oracle Incentive Compensation. Now a change is made to one of the orders for that month. The ID of the Order Header is 1001 and the ID of the Order Line is 1234. To notify Oracle Incentive Compensation of this change you make the following call:
CN_NOTIFICATION_PUB.Create_Notification
This API can be called either:
At the time that the adjustment was done in the source system
In the prenotification phase, or
In the notification phase itself.
This is the code:
CN_NOTIFICATION_PUB.Create_Notification
( p_api_version => 1.0,
x_return_status => l_return_status, -- OUT parameter
x_msg_count => l_msg_count, -- OUT parameter
x_msg_data => l_msg_data, -- OUT parameter
p_line_id => 1234, -- Line Table Id
p_source_doc_type => 'LEG', -- Transaction Source Type
p_adjusted_flag => 'Y', -- Adjustment(not new record)
p_header_id => 1001, -- Header Table Identifier
p_org_id => your_org_id, -- Operating Unit (optional)
x_loading_status => l_loading_status -- OUT parameter
);
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 the sales credits will then be collected again with the new values in. This reversal and re-collection of the October transaction will occur even if you specify that you want to collect only November transactions this time.
Note: to understand the p_org_id parameter, you need to first understand the Oracle Applications 'Multi-org' strategy, which allows data for multiple operating units to exist, partitioned from each other, within a single database. Discussion of Multi-org is beyond the scope of this document. If you don't understand this concept then please see the Oracle Applications Multiple Organizations Implementation Guide.
If your procedure which calls CN_NOTIFICATION_PUB.Create_Notification is running in a database session where the Org-Id has been set, and your procedure is only dealing with transactions for this Org-Id, then you can omit the p_org_id parameter. In any other situation (for example where you have a single procedure or database trigger which detects updates to transactions from multiple Org-Ids) you must specify the correct value of p_org_id for the transaction when you call Create_Notification.
When collecting an invoice, if a resource is assigned non revenue credit only, quantity is not populated for this particular resource. However, the transaction amount is populated as the total of revenue amount and non revenue amount. This can cause some confusion. If you want to display the quantity for resources with non revenue credit only, set the collection parameter Collect Quantity for Non Revenue Credit Receivers? to Yes.
Oracle Incentive Compensation allows you to make transaction adjustments one time, in Oracle Receivables using RAM (Revenue Adjustment Module), and collect the adjustments into Oracle Incentive Compensation. This eliminates the need to make corresponding manual adjustments in Oracle Incentive Compensation to reflect the RAM adjustments.
Use the receivables event, Revenue Adjustment Posting, to collect the revenue adjustment. You need to enable this event during the collection setup process, generate the collection package, and submit the concurrent request Collect Revenue Adjustments to collect the adjustments.
Submit the Collect Invoice concurrent request to collect your invoice transactions from Oracle Receivables. After collecting the invoice transactions, you can subsequently run Collect Revenue Adjustments on a regular basis to collect any adjustments that has been made on the transactions since the last collection. Oracle Incentive Compensation compares the time of the adjustments with the time of last run of collection and determines which adjustments should be included.
During the process of Revenue Adjustments Collection, you can control whether the manual adjustments that have been made on the Oracle Incentive Compensation side should be negated or not. To do so, use this collection parameter: Negate Original Transaction During Revenue Adjustments Collection?. There are two possible values for the parameter as follows:
Yes: Revenue Adjustments Collection negates the corresponding transactions that have been collected before and then re-collects them from Oracle Receivables with the new RAM adjustments. Any manual adjustment that has been done in Oracle Incentive Compensation against the original collected transactions is negated. This option ensures the data integrity from Oracle Receivables; however, you lose the manual adjustments made in Oracle Incentive Compensation side if any.
No: Revenue Adjustments Collection does not negate any corresponding transactions that have been collected before. Only the new RAM adjustment transactions is collected. This option preserves your manual adjustments, which have been done on the collected transactions, but it may result in the loss of the data integrity. In certain cases, the data in Oracle Incentive Compensation may need to be manually synchronized with the data in Oracle Receivables.
Before collecting adjustments from ARM:
The collection setup must be completed and the collection package for Revenue Adjustment Posting event must have been generated successfully.
The invoice transactions must be collected into Oracle Incentive Compensation.
The adjustments must be made in the Revenue Adjustment Module in Oracle Receivables (Receivables Responsibility > Control > Accounting > Revenue Accounting).
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.
You can import a batch of transactions from an external source rather than importing them one at a time. You can create an Import transaction on the Imports Definition page.
The import process begins with data files in CSV file format that are imported from an external source. These files are mapped to the target table columns in Oracle Incentive Compensation, where they are stored using a stored mapping or a new mapping that you create. At this time the status of the data is NEW.
After you review the setting, you can cancel the import process, which will set the status of the data to Cancelled.
If you do not cancel the process but proceed, you submit the data, which transfers it from the data file to the CN_IMP_LINES table. The data then has a status of Stage. If this process fails, the status is Failed at Staging.
After the data is staged, the application runs the concurrent program, which transfers data from CN_IMP_LINES to the destination table. While the data is waiting for the concurrent program to start, its status is Scheduled.
If the import process succeeds, the status of the data changes to Completed. You can then view the Process Log or Import Report to confirm that everything is the way you want it.
If the import process fails, however, the status changes to Failed at Importing. At this point you can either view the Process Log or Import Report, or view and download the failed records using the Failed Records page. After you have corrected the records that caused the import failure, you can resubmit them for import.
Begin the import process on the Imports Definition page, which is Step 1 of the import process. The process continues on to Step 2: Import Header Mapping. It is used to map source fields to target fields in the application. The process then continues on to Step 3: Review, and Confirmation pages. It is used to review your mapping of source fields in a file to target fields in Oracle Incentive Compensation. The process then continues on to Step 4, the Confirmation page. It confirms that your mapping of source fields in a file to target fields in Oracle Incentive Compensation has been submitted for processing.
Warning: When you import transactions, the application does not check for duplicate records. There is no way of determining whether a transaction is a duplicate transaction that should not be reloaded or simply a transaction that is identical to a previous one. Two identical transactions can be loaded as valid separate transactions.
There are two profile options used for the Import Framework.
OIC: SQL Loader Control File Directory: This profile must be set at the site level to OIC: SQL Loader Control File Directory = $CN_TOP/bin. $CN_TOP/bin has to be first translated to a full physical path. Be sure that the $CN_TOP/bin exists on the Concurrent Manager tier and that write privileges are enabled. If the bin directory does not exist it should be created and given read/write/execute permission.
OIC: SQL Loader Server Side Data File Directory:
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%".
OIC: SQL Loader Control File Directory - Set to "$CN_TOP/bin"
OIC: Log File Directory - Set to "%s_applptmp%"
After AutoConfig runs, some profile values will appear differently, as follows:
| Before Autoconfig Runs | After Autoconfig Runs |
|---|---|
| %s_applcsf%/inbound/%s_contextname% | /u01/proddb/admin/inbound/cn |
| APPLCSF | /u01/proddb/admin |
| contextname | product name = cn |
After you change the setting of a profile option, you must bounce the server to reset it.
Navigation
Compensation Manager > Tasks > Import/Export
Prerequisites
Steps
Click New Import.
Select an import type.
Enter a unique name for the import process and an optional description.
Click the Client or Server button to define your data source.
Select the column delimiter. Comma is the default.
Select how you want your fields to be enclosed.
Double Quotation is the default.
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 has a header.
Click Next to proceed to Step 2: Import Header Mapping.
Optionally, use the fields at the top of the page to load an existing mapping or save a new mapping.
To create a new mapping, click a source field in the first column to highlight it.
Click the target field in the second column.
Click the right arrow button to move the mapping to the third column.
View the Preview window to see what your mapping looks like.
Click Next to save and move to Step 3: Review.
Review the general information and mapping on the page.
If all the information is correct, click Import.
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.
If the information is not correct, click Cancel, and then return to the Import Header Mapping page to make corrections.
Click Finish to go to the Imports Search page. You can check there to see if your import was successful.
If you want to perform another import, click New Import.
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 header contains ten fields, all imported data must also have ten fields. Any blank spaces after the ten fields are seen by the application as additional fields. If data is imported with any additional fields in it, the import will fail.
The table below shows an acceptable format for transaction data. It is a very brief example of data that would work for a transaction API format.
| Name | Revenue Type | Processed Date | Transaction Amount | Item ID | State |
|---|---|---|---|---|---|
| Randy Roth | Revenue | 31-Mar-2006 | 250 | AS72111 | CA |
| Suzanne Chalmers | Revenue | 31-Mar-2006 | 250 | AS72111 | WA |
| Azid Hakim | Revenue | 31-Mar-2006 | 250 | AS72111 | OR |
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.
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.
Brief: Shows Errors and Milestones (see below).
Debugs only: Shows debug information only (which can be quite lengthy).
Errors only: Shows errors only.
Milestones only: Shows the status of the import process (such as Staged or Completed).
Sometimes records fail during the import process. This 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. The reasons for failure are shown at the end of each record.
The Failed Records page displays automatically upon failure of the import process. You can view the page by clicking the number link in the Failed Records column on the Imports/Exports page.
After you correct failed records you can reimport them.
Correcting failed records individually is much more efficient than reimporting an entire file. That is because reimporting creates an entire new set of records in the database in addition to the old set.
Navigation
HTML: Transaction > Import/Export
Steps
Click the Download to CSV File image icon to download the records to a CSV file.
Correct the data in the CSV file.
Create a new import using the corrected CSV file to load the data into the application.
Use this search page to configure the display that appears initially when you click the Import/Export subtab of the Transaction tab.
Import or export must have taken place to be displayed.
Navigation
Compensation Manager > Imports/Exports
Notes
All is the default Operation setting.
Enter an import date if you want to restrict your search to one specific day.
In this release of Oracle Incentive Compensation, the columns in the Displayed Columns area cannot be moved to the Available Columns side.
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.
The default number of rows to be displayed is 10.
If you want the report to be the default that appears in the Saved Searches field, check the Default box.
If you want to modify a saved search, make the changes and click Save. You cannot modify a seeded search, but you can rename one and save it, and then apply the changes you need to it and resave the search.
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
Enter type, name, and optional description.
Click Next to proceed to Export Header Mapping.
This page is where you map source fields to mapped fields. You can use an existing mapping or create and save a new one.
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.
You can load an existing mapping instead of creating a new one. This can save you time.
Save the mapping.
Click Next to proceed to the Review page.
This page is used to review your mapping of source fields in Oracle Incentive Compensation to target fields a file. The process then continues on to the Confirmation page.
On the Review page, verify that the general information and mapping on the page are correct.
If all the information is correct, click Export. The Confirmation page appears.
If the information is not correct, click Cancel, and then return to the Export Definition page to make corrections.
On the Confirmation page, click Finish to go to the Export Search page. You can check there to see if your import was successful.
If you want to perform another export, click New Export.
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
Search for the transaction you need. An Operating Unit is required.
To add greater granularity for your search, click the Advanced Search button.
On the Transactions page, click the appropriate button for the type of action you want to perform:
Click the Create button to opens the Create Transaction page, where you can create a new manual transaction. See Create a New Transaction.
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.
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.
To make adjustments to a transaction, click the resource name link on the transaction. See Adjust Transaction
To split an individual transaction, click the Split icon next to the transaction you want to adjust. See Split Transaction
Perform the steps you need on the appropriate page.
You cannot split nonrevenue, obsolete, frozen, or reversal transactions.
This section contains useful guidance for resolving transaction failures for classification, rollup, population, and calculation.
Oracle Incentive Compensation provides links to appropriate application pages to help you resolve disputes, correct setups, or make adjustments. If a transaction has not been classified, then a Compensation Manager or Compensation Analyst can view any related details for that transaction. If a transaction has been processed, either partially or all of the way through calculation and payment, then the Compensation Manager or Compensation Analyst can drill down from the Commission Lines via the Status Detail icon for each individual commission line and view the details related to that line item. If a transaction has not been classified, then a Compensation Manager or Compensation Analyst can view any related details for that transaction via the Status Detail button on the page.
Navigation
Compensation Manager > Maintain Transactions > Detail icon or Compensation Manager > Compensation > Transaction subtab
Check the Attributes that are used by the Classification Rules and Rules Hierarchy. Make sure that the values entered or collected for the transaction used by the classification rules match the vales for the rule expressions. These are case sensitive.
2. Check the process date of the transaction to make sure it falls within a valid rule set date range.
The resource has a Sales Compensation role but is not attached to a group that has a Sales Compensation’ type of usage. The resource must have both a sales compensation role and belong to a sales compensation group hierarchy.
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.
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.
Make sure that the Sales Compensation Role that is assigned to the resource has either the Member or Manager box checked.
Make sure that the Resource Group role is defined and the transaction process date is within the range of group role dates.
Check to ensure that the Group has a usage type of Sales Compensation.
Check the date range for the plan element and compensation plan. If the ranges do not encompass the transaction process date, the transaction will not be considered for this plan element.
Make sure that the classification rule is included in the product hierarchy, if using a hierarchy in the plan element.
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
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.
Be sure to check the compensation plan status. If the compensation plan was edited, the plan may be in an incomplete state.
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.
Records may be missing in the cn_dim_explosions_all table because a trigger was inadvertently disabled. Check to make sure that product transactions exist in this table. If one or more records are missing, enable the trigger, delete the product and save, then re-add the product and save.
Make sure that the rate table is set up to accept all possible values passed to it from the transaction. This applies to both input and output expressions. If the first tier is setup with value Xxx to Value Xxx, change the first range to 0.00 to Xxx. Also check any string values passed to the table. Strings must find an exact match.
Check the data on the transaction to ensure that values expected by the formula are not missing.
Check the values used in the formula (input or output expressions) to make sure a divide by zero error has not occurred.
If a plan element is used in a calculation expression, make sure that it is assigned to the resource’s compensation plan.
If a formula used in calculation was updated, the package may need to be regenerated. Make sure that the status of the formula and compensation plan are complete.
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.
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. If using incremental calculation, make sure the system profile, Mark Events, is set to Yes.
If any resource needs manual sales credit line adjustments, you can create a manual transaction for the process date.
Navigation
Compensation Manager > Maintain Transactions > Create
Notes
After entering the required information, you can enter other fields as needed and available. These fields are customizable.
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.
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.
Perform Rollup: If you want to keep credit from rolling up to managers for a specific transaction, you can uncheck Perform Rollup to keep the credit with the direct resource only. However, if the Managerial Rollup box on the System Parameters page is unchecked, rollups for all transactions are prevented, so in that case selecting this preprocessing code for a single transaction is unnecessary. If a resource is a member of more than one compensation group, then you must specify a compensation group when selecting any preprocessor code that skips Rollup, or the transaction will fail rollup. There are no other dependencies on this selection.
Perform Population: If a resource is a member of multiple groups and has multiple plan elements, you may want to eliminate possible duplication of compensation payments. In this case, you can skip the population phase for a transaction. However, you must specify the plan element and the role assignment for the resource for calculation to succeed.
Perform Calculation: Calculation is normally not skipped, but the application provides the flexibility to choose it in case a business situation requires it in the future. If this option is unchecked, you must provide the calculated amount in the commission text box.
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.
You can customize the attributes on the Create New Transaction page. This helps in setting up effective classification of transactions.
Navigation
Incentive Compensation Administrator > Configuration Workbench > Calculation < Configure Tables and Columns
Steps
Search for the CN_COMMISSION_HEADERS table.
Select the table name in the results. The columns are displayed in the table below.
Select the Classification view from the View Column drop-down list.
Choose an unassigned Attribute field and type in the column name that you want to be displayed on the Transaction Page in the User Name column.
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.
You may also display this column in the search results page by checking the Display in Results flag.
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 for instructions.
Navigation
Compensation Manager > Maintain Transactions > Mass Updates > Adjust
Prerequisites
Steps
Query for transactions.
Make sure that theAdjust radio button is selected.
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.
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.
Enter your comments, if any.
Click Apply.
You can divide up the sales credit on an entire deal.
Deal split is used only for order and invoice type transactions. You cannot perform a deal split for a manual type transaction with the order number or invoice number.
Navigation
Compensation Manager > Maintain Transactions > Mass Updates > Deal Split
Steps
Query a specific transaction by order number or invoice number to activate the Deal Split button on the Apply Mass Updates to Transactions page.
Select the Deal Split button.
Enter the names of the new credit receivers.
In the split field, enter a credit percentage for each resource.
The numbers for revenue credit must add up to 100 percent.
Click Apply.
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.
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
Steps
Use the search parameters to find the transaction that you want to adjust.
Click the object link for the transaction that you want to adjust.
Enter any changes in the appropriate fields and click Apply.
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.
Click Apply.
There are many statuses for transaction adjustments. The table below lists them, with meanings and notes.
| Status | Meaning | Notes |
|---|---|---|
| MANUAL | Manual | When a new transaction is created, it has this status. |
| SPLIT | Split | When a single transaction is split on the UI, the original transaction is set to FROZEN and one or more transactions are created for each new credit receiver with this adjust status. |
| MASSADJ | Move Credits | When mass moving credits, the original transactions are set to FROZEN and new transactions are created for the new credit receiver with this adjust status. |
| DEALSPLIT | Deal Split | When splitting transactions at the order or invoice level, the original transactions are set to FROZEN and new transactions are created for the new credit receiver with this adjust status. |
| FROZEN | Frozen | When a loaded transaction is adjusted, the original transaction is set to frozen and is not processed any further. |
| REVERSAL | Reversal | The transaction reverses an existing transaction, and will not be used in calculating compensation, only for auditing. |
| SCA_PENDING | Frozen for Credit Allocation | The transaction is currently being processed by credit allocation, and can't be adjusted or loaded into the transaction header table. |
| SCA_ALLOCATED | Processed - Credit Allocation | The transaction has been processed successfully by credit allocation. |
| SCA_NO_RULE | Processed - No Credit Rule Found | The transaction was processed by credit allocation, but no matching rule was found for the order/invoice line. |
| SCA_NOT_ALLOCATED | Processed - Credit Not Allocated | The transaction was processed by credit allocation, a matching rule was found, but credit was not allocated to the resource because no allocation was defined for the role . |
| SCA_NOT_ELIGIBLE | Not Eligible for Credit Allocation | (1). The original transaction was 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 Set of Mapping Columns | Transactions for the same order/invoice line have inconsistent attribute values which will be used for credit allocation. |
| SCA_REVENUE_ERROR | Error - No Revenue Line | At least one of the transactions for the order/invoice line must have the REVENUE revenue type. |
| SCA_SRP_ERROR | Error - Invalid Salesrep. | The name failed validation against: JTF_RS_SALESREPS(ORG_ID, SALESREP_ID) |
| SCA_ROLE_ERROR | Error - Invalid Role | The role failed validation against: CN_SRP_ROLES(ORG_ID, SALESREP_ID, ROLE_ID) |
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. For transactions that have a transaction split percentage of 100%, the sales credit for split revenue transactions must equal 100%. If the transaction split percentage is another amount then the sales credit for the split revenue transactions must add up to that percentage. Nonrevenue sales credit does not have the 100% constraint of revenue credit.
See Examples below.
Navigation
Compensation Manager > Maintain Transactions
Steps
Query for the transaction that you want to split.
Click theSplit icon.
Select the names of the resource with whom you want to split the credit.
Enter the percentage of revenue or nonrevenue sales credit each person is to receive.
Note: If the original resource is still eligible for sales credit he or she must be specified as a credit receiver.
Enter any User Comments.
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.
All adjustments made with the above process must be loaded before they are available for calculation.
After transactions are collected and adjusted, they must be loaded into Oracle Incentive Compensation tables prior to running the calculation and payment processes.
Navigation
Compensation Manager > Load Transactions
Notes
You must specify an operating unit.
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.
Click Refresh on the Requests page to display updated information as the concurrent processing proceeds.
Note: You must specify a revenue class for a transaction before loading.
After you have loaded the transactions, you can view your Concurrent Manager request. As you prepare to request calculation, the View Requests link is on the Calculation Requests page. Another link takes you to the process log, where you can review details of the load request.
Navigation
Compensation Manager > Requests > Monitor
Oracle Incentive Compensation supports use of a transaction interface to bring compensation transactions into the system. To process incentives, Oracle Incentive Compensation uses the CN_COMM_LINES_API table as a transaction interface for the following:
Standard collection of sales credit transactions using out-of-box integration with Oracle Receivables (for Invoices/Credit Memos/Payments and so on) and Oracle Order Management (for Booked Orders).
Collection from custom sources of data using the standard collection feature.
Uploading transactions directly into the CN_COMM_LINES_API table using SQL*LOADER, SQL, PL/SQL routines, and so on, for processing Incentives.
Importing data from a spreadsheet (see Defining Imports and the following pages).
If you intend to upload transactions directly into the CN_COMM_LINE_API table or import data from a spreadsheet, the table below provides a detailed description of key attributes of the CN_COMM_LINES_API table. See the Oracle Incentive Compensation TRM for more detailed information on each column.
| Column | Data Type | Description |
|---|---|---|
| COMM_LINES_API_ID | NUMBER(15) | This is the unique identifier of the table and must be populated with a value. If using the SQL* LOADER then use the sequence CN_COMM_LINES_API_S.next val. |
| PROCESSED_DATE | DATE | The date the transaction needs to be processed for compensation calculation. This is a mandatory column. |
| TRANSACTION_ AMOUNT | NUMBER | The transaction amount that needs to be used as a basis for arriving at the compensation value. This is a mandatory column. |
| TRX_TYPE | VARCHAR2(30) | The type of the transaction. It can have any one of the following values: CBK: Claw Back (or Take Back) CM: Credit Memo GBK: Give Back INV: Invoice MAN: Manual Adjustment ORD: Booked Orders PMT: Payment Received WO: Write Off This is a mandatory column. |
| EMPLOYEE_NUMBER | VARCHAR2(30) | The resource that is receiving credit for the transaction. If using the SQL*LOADER option or the spreadsheet, the value needs to be Salesrep Number as defined in Resource Manager. Please refer to Resource Manager documentation for more information on how to define a resource. |
| OBJECT_VERSION_NUMBER | NUMBER | Sequential number which is set at 1 on insert and incremented on update. Used by APIs to ensure that the current record is passed. This is a mandatory column. When you upload a transaction directly into the API, the value must be set to 1. |
| SALESREP_ID | NUMBER(15) | This value is populated by standard collection programs of the application. Custom and nonstandard processes should not populate a SALESREP_ID value. The EMPLOYEE_NUMBER column should be used instead. |
| LOAD_STATUS | VARCHAR2(30) | This denotes the status of the transaction after the Transaction Interface Loader process is run to load transactions from the API table to the CN_COMMISSION_HEADERS table. Here are two important status values: UNLOADED: Status of new transactions when they are first loaded into the API table. It also denotes transactions that have not been picked up for loading into the CN_COMMISSION_HEADERS table. LOADED: The transaction is successfully loaded into the CN_COMMISSION_HEADERS table. See Validation Checks and Resolution Method for more details and the rest of the LOAD_STATUS values. |
| TRANSACTION_CURRENCY_CODE | VARCHAR2(15) | The currency code of transaction amount that comes with the transaction, for example, USD. The value must correspond to the currency code as defined in GL-Currencies. See the GL-Currencies form to confirm. See Note: in Exchange Rates following. |
| EXCHANGE_RATE | NUMBER | The exchange rate that needs to be applied to determine the actual amount of the transaction. Ideally, this matches what is defined in the GL-Daily Rates table. Note: Transaction_Currency_Code and Exchange_Rate are not mandatory. If these two values are left as Null the application assumes that the currency_code matches the functional currency and that no exchange rate will be applied. However, if you populate TRANSACTION_ CURRENCY_CODE with currency that is not the functional currency, you must populate EXCHANGE_RATE. This is done automatically using the GL rates with using the Transaction screen. If done using SQL, you can populate whatever exchange rate you want. |
| ADJUST_STATUS | VARCHAR2(10) | The adjustment status of the transaction. It is automatically updated on the Adjustments screen when the system makes adjustments. This is a system-generated field and should not be populated with any value. |
| ORG_ID | NUMBER | Needs to be populated with the specific org for which the transactions are being loaded for Incentives calculation. If the implementation is multi-org, then it is a mandatory column. If the implementation is not multi-org, then the column can have null value. |
| ROLLUP_DATE | DATE | The date the transactions must use to roll up the sales credit using the compensation group hierarchy. If this column is null, the date value in the PROCESSED_DATE column will be set for this column. If you need this date to be different from the PROCESSED_DATE you can set it to a different value. |
| REVENUE_TYPE | VARCHAR2(15) | This column denotes whether the transaction is of a Revenue or Nonrevenue sales credit type. For transactions collected directly from out-of-box integration with Oracle Order Management or Oracle Receivables, this column is populated automatically with the respective sales credit type defined in these source systems. Note: When the application collects nonrevenue transactions from Oracle Receivables, if there is a quantity value, it is zeroed out during collection. |
| ATTRIBUTE1 - ATTRIBUTE100 | VARCHAR2(240) | These are the descriptive flexfield columns on the transaction. They can be populated with values to be used in defining classification rules or for defining expressions to be used in formulas, rate tables, and so on. |
The transaction interface loader process starts by collecting transactions from the API based on the parameters provided by the user and looking at transactions in the API that have the following load_status:
UNLOADED: Status of the transaction when it is first loaded into the API table. It also denotes that it has not been picked up for loading into the CN_COMMISSION_HEADERS table.
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:
Make sure to set the parameter to Yes so that the system can process prior period adjustments.
If the paramet is set to No, change the processed_date on the transaction to be greater than the date for which calculation was last run.
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 different from the functional currency defined for the system and the value of the exchange_rate column is not populated. To resolve this, populate the exchange_rate column with a value on the transaction.
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.
ERROR - CANNOT CONV/DEFAULT: This is a catch-all bucket in case the process cannot do currency conversion of transaction_amount column of the transaction. Possibly the currency code has not been defined.
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:
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.
Make sure the employee_number or salesrep_id on the transaction is defined in the system and active for the processed_date of the transaction.
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:
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.
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.
For example, if periods are defined as follows:
Jan-06 (1-Jan-06 to 31-Jan-06)
Feb-06 (1-Feb-06 to 28-Feb-06)
A transaction that is processed for 2-March-06 will create a period error message.
The transaction interface loader process does not pick up transactions in the API that have the following load_status:
OBSOLETE: The transaction has been adjusted prior to the transaction interface loader being run and cannot be uploaded into the system.
FILTERED: As part of Standard collections, the post collection process is defined to filter this transaction, therefore that it cannot be loaded into the system.
LOADED: The transaction is already successfully loaded from the table CN_COMM_LINES_API into the transaction table CN_COMMISSION_HEADERS. See Validation Checks and Resolution Method for more details.
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.