Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

VideoDescriptionPrice Rules
VideoTitleMarketing tools in YC





Price rules allow large reseller businesses better manager their price lists by configuring a set of rules to transform raw prices to end customer prices. 

Typical use case is when reseller receives daily buying in price updates from suppliers which could contain thousands of products and it simply is impractical to review the end customer prices on daily basis manually. Instead resellers can setup rules such as: "HP Notebooks should be sold with 5% margin" or "All notebook accessories should be sold with 15% margin" which could be applied to buying in prices to automatically work out the correct end customer price.

Another typical case is when resellers receive RRP as a daily update from their supplier and end customer price is discounted from the RRP to give realistic customer prices. Example rule would be: "All cameras are sold with 10% discount from RRP"

Price rules management section allows to configure such rules and then transform the raw buying in prices into the end customer prices automatically by running Price generator job.

Price calculation


When price generator job executes it scans all non-auto-generated prices (prices which do not have auto-generated flag). Each price is evaluated by the price rule engine using set of price rules configured for the shop the price comes from (as each price belong to a specific shop). 

Each rule has an eligibility condition which determines if a price is applicable for this rule and if it is the action of this rule is executed. The first applicable rule determines what happens to raw price in terms of action, which is why ranking of the price is very important as multiple rule could have condition which makes the price eligible but only the action of the first rule applicable is executed against the price.

The following actions are supported by price rules:

ActionBehaviourParameters used

Calculates end customer price using formula:


Margin Percent - margin percentage (Can be negative for discount calculation)

Margin Amount - fixed amount (Can be negative for discount calculation)

Add tax - flag, when enabled tax is resolved an added to generated price (e.g. when raw prices are NET but shop works with GROSS prices by default)

Rounding unit - minimal unit for "nice" prices rounding.

Request for priceBehaves similarly to Calculate but also adds the request for price flag onto the price. This flag prevents customer from seeing the price and instead a label is displayed that they need to contact the shop for price quote

Same as for Calculate action


SkipIgnore the price, which is useful to skip generation of customer price (effectively saying we are not selling these products) 



In B2B configurations sub shops inherit all price rules from the master shop but also can define additional rules. Typically this is used to account for special conditions for sub shop, such as "Products from category X are not sold to this customer", or special prices such as "Customers in this sub shop receive a larger discount".

It is also possible to restrict sub shop to use only its own rules by setting SHOP_B2B_STRICT_PRICE_RULES attribute to true at sub shop level.

Tag, Reference and Policy


With calculate and request for price you have the option to set tag, reference and policy on the generated price. Tags are useful to track the origin of the generated price as you can see tags on the generated prices in the price lists view once they are generated, thus rule that caused the generation of this price can be easily identified. Reference is a special field on the price which is copied over to the cart items and later on to the placed order items (so it is like a sticky tag, which you will be able to see in order view). Policy is  special field on prices that allows to limit access to these prices to only customers that have this policy set on their profiles (effectively exclusive right to special prices).

Eligibility condition


Eligibility condition is a logic statement that allows to evaluate an input price and determine if it is applicable for given rule. Each condition evaluates either to true or false. The condition syntax may seem somewhat overwhelming but in essence it is not much more complex than learning Excel formulas. However if this syntax is mastered marketing manager can create some very powerful and complex conditions to fine tune the pricing policies pitch perfect.

The eligibility condition editor provides helper functions for including a typical condition templates, looking up ID of categories and ID of brands which can be used as variable in the condition function.

Watch out for


Eligibility condition is a boolean expression (i.e. expression that evaluates either to true or false) which represents the qualifying criteria for price rule. Default rule expression engine is Groovy (a java library).

Since the expression written in Groovy here are some not so obvious things:

Comparing values: A = B Equals operator is "==" (double equals) or .equals() 


Code Block
// Use double equals sign or .equals()
A == B


Complex statements The condition is a script and can have multiline Groovy code as long as the last line evaluates to true or false 


Code Block
// Check item SKU is one in the list of promo SKU codes
def list = ['PROMOSKU001', 'PROMOSKU002', 'PROMOSKU003'];


Built in variables There are some predefined variablesthat can be used in expression 


Code Block
// customerTags is variable containing list of tags from Customer profile


Using variables and Groovy syntax any condition can be written to represent price rule with conditions resembling a natural English language sentences.





Code Block
// Pricing policy check
PRICE.pricingPolicy == 'COST_MAIN'
// Pricing policy check for all policies starting with COST_
// '?' character must be used since policy may not exist
// Zero prices
PRICE.regularPrice == 0
// Tag check
PRICE.tag == 'special'


SkuPrice object being evaluated


Code Block
// match
SKU == 'ABC'
// partial match e.g. ABC-0001, ABC-0002
// partial match e.g. 00001-ABC, 00020-ABC, XYZ-ABC


SKU code of currently evaluated price



FunctionReturn typeParameter 0Parameter 1ExampleDescription
hasProductAttributebooleanString (SKU code)String (Attribute code)


Code Block
hasProductAttribute(SKU, 'ONSALE')


Check if attribute is set for product with given SKU
productAttributeValueStringString (SKU code)String (Attribute code)


Code Block
productAttributeValue(SKU, 'ONSALE') == 'Y'


Retrieve attribute value set for product with given SKU
isSKUofBrandbooleanString (SKU code)String Array (Brand names)


Code Block
// Check for single brand
isSKUofBrand(SKU, 'HP')
// Check for multiple brands
isSKUofBrand(SKU, 'HP', 'Lenovo')


Check if current SKU belongs to one of the brands
isSKUinCategorybooleanString (SKU code)String Array (Category code)


Code Block
// Check for single category
isSKUinCategory(SKU, 'Notebooks')
// Check for multiple categories
isSKUinCategory(SKU, 'Notebooks', 'Accessories', 'Desktop')


Check if current SKU belongs to one of the categories
productProductString (SKU code) 


Code Block
product(SKU).name == 'E73'


Retrieve product by SKU code
productSkuProductSKUString (SKU code) 


Code Block
productSku(SKU).name == 'E73'


Retrieve product SKU by SKU code
brandBrandString (SKU code) 


Code Block
brand(SKU).name == 'HP'


Retrieve product's brand by SKU code

Price rules tester


Price rules management section includes price rules tester function which allows to run the configured rules on a set of SKU code and allow you to see the exact result of the calculations. You can also set the time variable to see how the rules behave in different time periods which is ideal for testing how the rules are evaluated say in seasonal sales and how calculations are performed with time sensitive rules and time sensitive raw (input) prices.

Price Rules Management


Working example

Business scenario


Given typical use cases described above suppose we have price import feeds available from our suppliers and we are able to receive buying in prices (BP) and recommended retail prices (RRP). Suppose that our BP are provided as NET (without tax) and RRP as GROSS (tax included) and our basic price view for web shop is GROSS prices.

Our marketing strategy for price would be to utilise both types of raw prices and devise a strategy based on the following rules:

  • Notebooks (products in category 'notebooks') should be sold as 15% margin from BP
  • Lenovo brand products should be sold as 5% discount from RRP
  • We do not sell products from mobile category (say we receive products in PIM feed but we do not want to sell them in our shop)

Price import


Raw prices can be imported utilising the CSV import facility available as standard in YC. Auto import listener job can be configured to pick up raw prices CSV import files at designated time.

However we do not want to expose these prices on the front end as both RRP and especially BP are not meant to be accessible by customers. Therefore we will use a special policy (this is an optional data field that exists on every price and if set will only be visible to customers that have this policy set on their profile).

Recommended usage for BP policy is 

Body'COST_' + fulfilment centre code
. For example if you FF code is MAIN, then the BR pricing policy field should be filled in with 
. If you are following this convention then the BP prices will be automatically be resolved for the items that your customer purchases and will be visible in JAM's order view (provided you have access to this).

Similarly to BR, RRP policy could be set to 

Body'RRP_' + fulfilment centre code

Therefore the raw prices import file would look something like this (this is standard format for skuprices.xml import descriptor):

SKU codeShop codecurrencyquantitylist pricesale pricevalid fromvalid totagpricing policyref
The import file can be single file, or can be broken into several files (e.g. BP and RRP separate) or can be any parts of the BP/RRP set or a mix. In terms of import this is not relevant as long as all columns are specified correctly.
Above is the standard import for price file. It is possible to configure own format for the import descriptor including only columns you need (even on per shop basis). See import/export documentation for more details

Price rules


We setup the following price rules that reflect our business requirements:

CodeRankEligibility conditionActionMargin PercentAdd taxBusiness rule


Code Block
(PRICE.pricingPolicy == 'COST_MAIN') && 
(isSKUinCategory(SKU, 'Mobile')


Skip  We do not sell products from mobile category


Code Block
(PRICE.pricingPolicy == 'COST_MAIN') && 
(isSKUinCategory(SKU, 'Notebooks', 'PortablePC')


Calculate15 (tick)Notebooks (products in category 'notebooks') should be sold as 15% margin from BP


Code Block
(PRICE.pricingPolicy == 'RRP_MAIN') && 
(isSKUofBrand(SKU, 'Lenovo')


Calculate-5 (error)Lenovo brand products should be sold as 5% discount from RRP

As you can see we rearranged the rules slightly and given NOSALE rule top rank, because this is the most fundamental rule and any price which matches this condition should be ignored as we do not sell these product and if no price is generated this product will not appear in the front end (all products must have a valid price unless they are set as SHOWROOM availability).

Next   NB15MARGIN acts only on prices whose pricing policy is COST_MAIN and SKU is in notebook categories. If the price being evaluated satisfies this condition the calculation action is applied to generate a price with 15% margin and tax added to the result. Effectively we convert our BP which was NET into customer end price as GROSS (including tax). Say tax for this type of products is 20% then the calculation for NB-0001 would be 

Body(500 * (1 + 15/100)) * (1 + 20/100) = 690


The tax applied would be default tax for given product. This particular example works in VAT type systems were tax for products is deterministic. For US/Canada taxation we recommend using NET prices

Last rule LE5DISCOUNT act only on prices whose pricing policy is RRP_MAIN and is of Lenovo brand. The calculation for LE-0001 would be 

Body(410 * (1 + (-5)/100)) = 389.50

Important to mention is that Lenovo notebooks would be calculated using NB15MARGIN rule as it has higher rank and will be applied first. So rules should be arranged by rank in such a way to produce correct prices. The question is with this scenario, what is the right rule to apply NB15MARGIN (because it is a notebook product) or LE5DISCOUNT (because it is of brand Lenovo). These types of questions can only be answered by marketing manager and thus it is up to them to arrange these rules in the correct ranking.