Rules Library Management

Defining Products and Product Hierarchies

Products are user-defined business categories used to determine whether sales credit is applied toward a compensation payment. The Plan Administrator defines the products, which are then placed into hierarchies. Hierarchies are composed of broader product classes at the top, or root, with subclasses as children of the root. A product hierarchy makes it possible to pay compensation for a broader range of products without specifying all possible subclasses in a compensation plan.

After products and product hierarchies are established, classification rules are used to classify how compensation is awarded. When a compensation transaction passes a classification rule (all conditions are true), Oracle Incentive Compensation then compares the children of that rule, working left to right, until it finds a match. The application then looks at the children of that rule, and so on, and stops if it cannot find a match in the children. The rule classification process returns the product of the last matching rule. After the classification process, the matching product is marked on each transaction as an additional attribute.

If any one of several conditions associated with a product qualifies a compensation transaction to be assigned to a product when the condition is true, you can define multiple sibling rules in the hierarchy, one for each condition. Because Oracle Incentive Compensation evaluates other sibling rules if a transaction does not satisfy the first classification rule on a level in the hierarchy, the application processes these rules as if they were joined by an AND operator. When a transaction fails a rule, the application compares the transaction attributes with other sibling rules from left to right.

If a transaction’s attributes satisfy all classification rules, then the transaction is classified against the product. If the OR condition is used, then the transaction will classify against that product if the transaction attributes meet any of the rules of the product.

If several products share multiple conditions, you can minimize data entry by creating a parent classification rule that includes the shared conditions, and by defining only the unique conditions as child rules.

Rules Library Management

the picture is described in the document text

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 product. Your company might organize its sales strategy around expansion into new markets, where each new market is defined as a separate product.

Your company might use industry-based incentive compensation, paying compensation only for sales made in a resource’s assigned set of industries. For example, a resource's plan might include a plan element that pays only for sales to pharmaceutical customers, or to auto manufacturing corporations.

Navigation

Plan Administrator > Maintain Products

Building a Product Hierarchy

You can use this procedure to create new hierarchies or to make changes to an existing hierarchy.

There are three placements of nodes that you can make for any hierarchy:

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.

You cannot delete the Base Node of the seeded product hierarchy. For more information on the structure of a hierarchy, see Restrictions.

Navigation

Plan Administrator > Maintain Product Hierarchies

  1. Click Create. Create a new hierarchy on the first blank line. The Base Table is the domain where the elements are located that you want to use in your hierarchy. The primary key identifies each hierarchical element in the base table.

  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.

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.

Defining Rule Sets

Rule sets are used to classify information. For example, a classification rule set is used to classify sales transactions to determine the appropriate product for the transaction as part of calculating compensation. Then, using the product, the application matches a transaction with a compensation plan and a compensation amount to be paid when the transaction is calculated.

Rule sets are placed into a hierarchy that accurately reflects business requirements. The rule names are user defined, but many customers have found it useful to give rules a name that is similar to the products that are assigned to the rule. Rules do not require unique names.

In this release of Oracle Incentive Compensation there are four types of rule sets:

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.

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.

Building a Rules Hierarchy

After you create a rule set, you must create the rules and place them into a 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. Every rule must have at least one attribute.

You can define multiple date-effective classification rule sets, but rule set active dates may not overlap.

When you make changes to a ruleset, you must synchronize it. When you check the Select box next to the ruleset and click Synchronize, the application generates a PL/SQL script based on the product and product rules and saves it in an internal table. Before the status changes from Incomplete to Complete, it may display Install Pending. You do not need to synchronize a ruleset if you only rearranged the rules but did not otherwise change them.

The classification engines evaluates the rules from top-to-bottom, left-to-right. As soon as a positive match is made and any child rules evaluated, the transaction is classified and no longer evaluated against any other rules. The rules higher in the hierarchy must be built accordingly so that the transactions locate the appropriate rule.

A rule may or may not have an associated product. If the rule does not have a product, then its children rules must define the product. If a rule has a product, then the product is assigned to the transaction only if none of its child rules match the transaction.

You can enter conditions in the rule and the hierarchy you want to match. If the value of the transaction attribute rolls up the hierarchy to the value you specify, then the compensation transaction satisfies the condition.

You can specify the exclusion of a value you defined by checking the Not box. The compensation transaction satisfies the condition if the attribute is not equal to the specified value, is not between the range of values specified, or does not roll up to the specified ancestor value.

Click the Report link on the Classifications page to view the Classification Reports for a ruleset. The report displays the product and expression related to each rule in the hierarchy. The Plan Administrator can export the report.

Navigation

Plan Administrator > Maintain Classification Rulesets > <rule set link>

  1. Query for a rule.

  2. To add a rule, in the lower section of the Rules Hierarchy page, select Root from the Add Rule column list.

  3. Name the rule and give it a product name.

  4. Add three rows and select an attribute.

  5. Enter conditions for the attribute.

  6. Enter a value range for the attribute.

  7. Enter hierarchy conditions, if necessary, in the Hierarchy Conditions section below.

  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.

When you click Synchronize, If any rules do not have attributes, an error message displays along the top of the page indicating which rule requires attributes to be assigned to it. The messages continue to display for one rule at a time until all contain attributes.

When creating rules, you may use attributes set up for classification rules. If you are using flex attributes which store date information, be sure to enter dates using a date format that matches how your Compensation Manager views date information. If you create classification rules using one date format and your Compensation Manager has a different date format in his profile when running the calculation batch, the calculation process may fail.

Every attribute is assumed to be linked to other attributes with AND. If you want any of the attributes to be related with OR, use the Build Expression page to relate the first two attributes with AND or OR.