This blog post is part of a series designed to demystify the process of understanding and writing your own business rules.
Now that we’ve spent some time going over the process of building and combining rules, we can set aside a few posts to highlight some functions that don’t get as much attention. Although admittedly they aren’t used quite as frequently, we can guarantee that when you do need them, you’ll be glad to have them. This post will focus on three advanced functions:
The GETLABELSOFTYPE function retrieves a comma-separated list of all of the inventory labels assigned to a product. You can then use this list in a conditional statement to have the rule take different steps depending on a product’s labels. Here’s a template for a conditional rule that references GETLABELSOFTYPE:
IF(CONTAINS(GETLABELSOFTYPE(“”), “Label Name”), [Value 1], [Value 2])
This function can be very powerful, but be wary of where and when you’re using it. If you’re getting ready for a sale, it might be tempting to simply apply an “On Sale” label on your products, and use the GETLABELSOFTYPE function to identify those products and dynamically create a reduced price to send to each marketplace. However, from a business perspective, this reduces the control you have over setting the sale prices for your own products.
From a software perspective, this function takes more time to process than referencing custom attributes — which means that our pricing updates wouldn’t get to the marketplace as quickly. When preparing for a sale, a better plan would be to use custom attributes to store your intended sale prices, and either reference these attributes in a business rule or simply map one directly to the template.
In more infrequent situations — such as managing a set of products that you’ve decided not to restock, for example — using a label instead of a custom attribute to group the affected products may make more sense. In that example, you could apply a “Blowout Sale” label to the products so they will follow completely different pricing guidelines until they’re all purchased. Here’s an example rule:
IF(CONTAINS(GETLABELSOFTYPE(“”), “Blowout Sale”), $itemsellercost * 1.25, IFBLANK($amzrepricerautoprice, $itembinprice))
This rule says that if a product has the “Blowout Sale” label, then its price should be 25% above the seller cost, no matter what. If it does not, then the rule uses the AmzRepricerAutoPrice if one has been set, and the Buy-It-Now Price ($itembinprice) otherwise.
SETCONTEXTVALUE and GETCONTEXTVALUE
These two functions can be used together to temporarily store a value and recall it later in the same rule. A rule using these functions only needs to process a difficult calculation once, but you can keep using the result as many times as necessary. This helps to both speed up processing time for the rule and also cut down the character count, making the rule easier to interpret.
Let’s start with a full example that dynamically calculates each product’s listing price, and then chooses a shipping price tier. We can refer back to the screenshot below to break down the steps of this rule (click to enlarge).
First, note that the entire function is wrapped within an IF statement. The SETCONTEXTVALUE function is a complete rule on its own, and it simply returns “true” when it’s finished storing a context value. However, these context values get discarded when the rule finishes running, so we need this IF statement to create space for our actual intended logic once the SETCONTEXTVALUE function is complete.
Because the SETCONTEXTVALUE result is always “true” we can nest this logic in the IF statement’s first result. This example’s logic is contained entirely within the SELECTCASE function. The second result of the IF statement will never be reached, so the example simply uses the text “N/A”.
For the purposes of this example, we’ll look at a complicated function to determine each product’s listing price. If we weren’t using these context value rules, the rule would need to re-calculate the listing price multiple times to compare it to each shipping tier limit. Instead, we use the SETCONTEXTVALUE function as the conditional statement to temporarily store the price in a context value named “PRICE.”
Since the conditional statement is always true, we’ll always reach the IF statement’s first result. This is where the actual business rule logic resides. In this rule, we use the SELECTCASE function to compare our stored “PRICE” value to the lower limits of each shipping tier. As long as the price is above $25, the product will use free shipping. Otherwise, if it is above $10 (but less than $25) it will charge $4.99 for shipping. Otherwise, it will charge $9.99 for shipping.
We then need to finish the IF statement by providing a second value, even though that value will never be used. To emphasize this point, the example uses the text “N/A” but this is up to you.
*Important Note* Other values can be retrieved through the GETCONTEXTVALUE function that don’t need to be defined in the same rule. These values are determined by Rithum and are based on the feed that is currently processing the rule. We won’t go into these values in detail; instead, we recommend you read up on the various other uses of the function in the Rithum Community. If you’re using the GETCONTEXTVALUE function for one of these values, you do not need to use the SETCONTEXTVALUE function or place your rule in an IF statement.