How to access Classification Data in Compensation ...

Lara · ‎2021 Feb 15

SAP SuccessFactors Incentive Management uses Classification Data to organize "master data" such as products, customers, geographic regions, and any other data that you need to correctly calculate incentive compensation. If you've been through any of the standard training, we focus on the use of this data in Territories used to allocate credit for a Transaction based on, for example, sale of a type of product in a region.

However, Classification data can be used for so much more! After all, if you're already pulling your product data from your ERP, you can also pull any other information about that product, such as the price, cost, net margin, or anything else that can help calculate compensation. In this article, I'll show a few basic use cases and show how you can reference this Classification data in a Credit Rule to bring your rule-writing to a whole new level. After the two examples, I'll give some pros and cons around the use of this method, and present a few alternatives.

The Transaction.Classifier() function

Let's start with the basic mechanism. The function you'll be using is "Transaction.Classifier( )". What this does is tell the system to find the matching Classifier for any given Transaction. When you use this function, you'll be prompted to select which hierarchy you want to use. That will return a single record, so from there, you just request a specific field.

You can use this function directly in a Credit Rule, but I'd recommend you create a Formula, as I do in the examples below, so you can re-use the same expression in multiple rules.

Example scenarios:

Scenario #1. For each of 20,000 products, once a credit is allocated to the payee, the value of the credit will be 5% the gross margin. Gross margin is calculated by subtracting the cost of the product from the price.

Here's an example of a product we've already uploaded to our Product Hierarchy. As it happens, the Product record already has fields for Price and Cost (we could add other fields if we need to, but that's a topic for another day).

Category Hierarchy: SERVICES HIERARCHY

Product ID: L4000

Product Name: License 4000 Pack

Price: $10,000

Cost: $3,000

What we need to do is subtract the cost from the price to calculate the gross margin.

Here's how you would do this using a Formula. I'll use the Window Editor because it's a little easier, but if you're comfortable with the syntax, you can build the expression right in the Expression field.

Create the Formula in the Formulas workspace. I'll call mine F_Gross_Margin.

Set the Return Type to Currency (yes, you can use the same Formula for multiple currencies)

Open the Window Editor

Click the Data Field button on the right side to bring up a list of available data fields. Scroll down to Transaction until you see a reference called Transaction.Classifier().

When you select this, you'll get a pop-up window prompting for the Category Hierarchy. Select the SERVICES HIERARCHY.

Note: You can always use an asterix (*) as a wild card if you're not sure which hierarchies are available.

Once you select the hierarchy, the formula will look like this:

So far, so good! The next step is to tell the Formula which field in the Classifier you want to use. In this case we're starting with the Price.

After the parenthesis, enter a period (.). This will return a list of all the available fields in the classifier. In this case we only have Price and Cost, so the list will look like this:

Select Price. Now your expression will look like this:

We're going to subtract the cost from the price, so just enter a minus sign (-) in the grey box.

Finally, we'll do exactly the same steps to enter the Cost field. When you're done, the whole thing will look like this:

Transaction.Classifier(SERVICES HIERARCHY).Price - Transaction.Classifier(SERVICES HIERARCHY).Cost

To save the window, click the grey checkmark in the upper right corner, and click Create to save the Formula.

Now, let's take a look at how you could use this in a Credit Rule!

The only thing you really need to change is the Amount field, which can be found in the Credit Amount section. If you're using the Wizard, this amount looks like this.

What we did is just take the Formula and multiply it by the commission amount. Now, in the real world, you probably wouldn't hard code the 5%; a better practice would be to use a Fixed Value, but I wanted to show this in a way that's easy to interpret.

Here's a helpful hint: You can wrap this expression in another function to take care of a few contingencies. For example:

Wrap this expression in a Convert Null to Value() function so it reverts to $0 if the Price and Cost are the same.

Convert Null to Value ( F_Gross_Margin , $0.00 )

Wrap it in an If...Then statement to return $0 if the value returned is negative.

If Then Else ( F_Gross_Margin < $0.00 , $0.00 , F_Gross_Margin )

Not too hard, right? Let's take a look at a different scenario, this one using the Postal Codes hierarchy.

Scenario #2. For each of 50,000 zip codes, our client needs to apply a different multiplier to the value of the Credit. The amount of the multiplier is stored in a Generic Attribute called GN1:Postal Code Multiplier.

Again in the Credit Rule, we want to apply the multiplier percentage to the Transaction.Value field. For example, let's say the value of the Transaction is $150, and the value of GN1:Multiplier is 110%. The value of the credit would be 150 * 110%, or $165.

There are several ways to do this, but again, if you can load those multipliers with their respective zip codes during a regular data load, using the Transaction.Classifer() function is an elegant and scalable solution.

In this scenario, I activated a Generic Number on the Postal Code workspace and labelled it the same as above: GN1:Postal Code Multiplier.

In the Postal Code Hierarchy, I set the Classification Rule to Transaction.Billing.Postal Code = Postal Code.Postal Code ID.

Now that we have the Postal Code hierarchy set up and each Postal Code has a multiplier assigned, I can set up a Formula that multiplies the Transaction value by the Postal Code Multiplier:

Transaction.Value * Transaction.Classifier(Postal Code Tree).GN1:Postal Code Multiplieriplier

Again, if you're concerned about getting a null value if one of your Postal Codes isn't populated, you can wrap this Formula in a "Convert Null to Value ( )" function so it reverts to 100%.

Transaction.Value * Convert Null to Value ( Transaction.Classifier(Postal Code Tree).GN1:Postal Code Multiplier , 100% )

What's really happening here?

Transaction.Classifier() acts like a big lookup, but instead of using a Lookup Table, it uses the entire Classification Hierarchy as the table. The match field is whatever you specified in the Classification Rule.

Could you use a Lookup Table instead? Yes! But there are advantages and disadvantages to both methods.

Advantages to using Transaction.Classifier():

It's highly scalable. You can use this method to retrieve data from tens of thousands of rows.

It works well with dynamic data. You can load a frequently changing master list from an upstream source system. This is great for scenarios in which the changes would be too much to keep up in a Lookup Table.

It allows you to perform these calculations within SAP Commissions instead of, for example, calculating the margin in the Transaction in the source system.

Here are some scenarios in which you might consider using a Lookup Table instead of a Classification Hierarchy:

If you need to match on a value stored outside the Transaction; for example, if the data to match is in the Participant or Position record. Matching can only occur on transactions if you are using Classification.

If you need to match on multiple classifications. Transaction.Classifier() can only perform a one-dimensional lookup.

If data is sometimes removed completely. It's not recommended to delete Classifiers (we recommend you end date them instead), but if your list of source data involves removing records frequently, a Lookup Table may be easier to manage.