Compensation Plan Elements, or simply Compensation Elements, are reusable objects that contain an expression or value. They make it easier to create and maintain compensation plans.
Compensation Elements merely store data. Until a Compensation Element is associated with a Rule, Variable, or Plan, it is not used in calculating compensation.
Access to Compensation Elements is available from the Plans menu. Each type of Compensation Element has its own workspace.
As we go through the next few lessons we will be creating many types of objects: fixed values, territories, variables, plans, and rules. While the system does not have strict naming requirements, we will be using a widely accepted set of naming conventions.
- While spaces are allowed, we will substitute an underscore ( _ ) for spaces.
- Each object is preceded by an acronym to identify the type of object. For example, territories are preceded by T_ , and territory variables are preceded by TV_.
- Objects that can be periodic, such as a fixed value that contains a quarterly quota, will contain the period somewhere in the name, such as FV_Quarterly_Quota or FV_Quota_Quarter.
- Compensation plan rules are preceded with the type of rule. For example, a direct credit rule will be preceded by DCR_, and a deposit rule will be preceded by DR_.
Advantages of Compensation Elements
Compensation Elements store data that can be used in rules. They have three advantages that simplify the management of rules:
- They allow the encapsulation of data in distinct objects rather than storing everything in a large, complex compensation plan.
- They have special abilities that allow certain tasks to be accomplished easily.
- They are Effective Dated, which makes it easier to manage changes in plans.
Types of Compensation Elements
A Territory is a named object defined by groups of categories and classifiers that is used to filter input to credit and primary measurement rules.
Territories filter transactions based on how they are classified. They can be used for a number of scenarios, but a common one is to allocate credit for a Transaction to a payee based on a criterion, such as the location, product or customer type.
Consider the scenario we saw earlier. Stacey Palowski, the Sales Rep for the western region, should get credit for any transaction in the US states of California, Nevada, or Arizona. Let’s add one more criteria: the transactions must also be for sales of bike products or accessories, but not repair services.
Stacey’s territory would be defined using the data in the category hierarchy we saw in the previous topic, and would look like (Bike Products OR Accessories) AND Western Region.Territories:
Are defined using Categories and Classifiers.
Can be simple or complex.
Can be referenced in Credit or Primary Measurement Rules.
Best Practices for Territories
- Use Parenthesis and Logical order of operations to make sure the statement is logically processed.
- For an AND condition, both parts must be true for the territory to succeed.
- For an OR condition, the match succeeds if either clause is true.
- Never leave a Territory object Blank, this will cause errors in the pipeline.
- Have a "dummy" Territory that evaluates as FALSE. You can then use this territory as the default for variables, which will prevent an error if a variable is not assigned.