Price Lists & Rules with Multiple Tags

steve-neal · January 17, 2023, 2:43pm

Hi all, I’m hoping someone with a bit more knowledge on the Pricebook rules might be able to clear something up for me - is it possible to explicitly define rules with multiple tags that insist on multiple tag criteria being met?

E.g.
I’ve created a rule for pricing which I would like based on a number of tags, which Breww presents to me as -

Product types: Multipack AND Product Tags "Tag A" or "Tag B"

This is fine, however on the same price list, some of my rules end up looking like this:

Product types: Multipack AND Product Tags "Tag A" or "Tag B"
Product types: Multipack AND Product Tags "Tag A"

Essentially I’m asking breww if its A & B, then do this, if its just A, do that.
If I switch the rule order around to:

Product types: Multipack AND Product Tags "Tag A"
Product types: Multipack AND Product Tags "Tag A" or "Tag B"

Any products tagged with B, will always be priced at just A as breww reads the rule here & stops, this is incorrect - so by switching the order around to A or B first - this appears to work like an explicit A & B and is pricing how we expect…
However, the word ‘or’ suggests this isn’t true & my dataset for this scenario is limited so testing is difficult, and my concern is that the ‘or’ may still be functioning as an 'or; and not ‘and’.

Hope this makes sense, and someone might know the answer. Thanks in advance!

matt-cousins · January 18, 2023, 2:54pm

Hi Steve,

Thanks for the great question!

Short answer - no - it’s not currently possible to insist on multiple of the same product selection fields, e.g. multiple product types, or multiple product tags. As I’m sure you see, this could only work for product tags anyway, as none of the other fields allow for multiple rules to be met at once (with the exception of container type in mixed packs). For example, a product can’t be a Keg and a Cask, so the operator between these two parameters would have to be ‘or’.

Long answer:

I think you may have slightly misunderstood how the price book rules work. In all fairness, the way a computer interprets the rules isn’t always the same as how a human might. The computer is always consistent, so once you’ve got it, you’ve got it! I’ll run through your examples, and hopefully, this will clear it up a bit.

Product types: Multipack AND Product Tags "Tag A" or "Tag B"

This would match products that are multipacks and have either “Tag A” or “Tag B”. If a multi-pack has either tag, it will satisfy this rule’s criteria and use it. It doesn’t matter whether it has both or a single one of either tag - it meets the criteria as the operator is ‘or’. If the operator (which isn’t currently possible) was
“Tag A” AND “Tag B”, only products with both tags would meet the criteria.

Product types: Multipack AND Product Tags "Tag A" or "Tag B"
Product types: Multipack AND Product Tags "Tag A"

Your second example is a good one to further explain the above. Say you have a multipack product with Tag A (and not tag B). Breww will go through your rules from the top and pick the first rule that fully satisfies the criteria. Starting from rule one, it will read left to right. Product type: multipack - . Then it sees the 'AND" keyword and knows that the next whole query (Product tags) needs to be true as well. The next query is Product Tags: "Tag A" or "Tag B". The product must have Tag A or Tag B. The product has Tag A, so that satisfies the tags part. Both the product type parameter and the product tag parameter have been satisfied; therefore, this rule is selected. The second rule in this example can never be selected, as a multipack with Tag A will always be picked up by the first rule, regardless of its other tags.

Product types: Multipack AND Product Tags "Tag A"
Product types: Multipack AND Product Tags "Tag A" or "Tag B"

Similar to the second example, a multipack with Tag A (regardless of any other tags it might have) will always be selected by the first rule. And vice versa - a multipack with Tag B (regardless of Tag A status), will be picked up by the second rule. The “Tag A” referenced in the second rule isn’t doing anything, as no mixed packs with Tag A could ever make it to rule two.

The solution to all this would be to allow you to use the ‘and’ operator between product tags. For if you could do (note the *and*):

Product types: Multipack AND Product Tags "Tag A" *and* "Tag B"
Product types: Multipack AND Product Tags "Tag A"

then a product with just Tag A and not Tag B (and vice versa), couldn’t satisfy the first rule and would move on to the next one.

Please let me know if you need any further help in understanding this - I’m sure it’s helpful to others as well, so please do ask if so.

Finally, I have created a feature request for you, for the ability to use the ‘and’ operator between product tags.

steve-neal · January 19, 2023, 8:41am

Thanks for the detailed response & the feature request Matt.

Your explanation is exactly what I expected to happen - so after reading through and double checking everything at this end - it turned out an incorrectly tagged beer (with Tag B) was causing it to appear as though switching the order of the rules was creating this confusion between ‘or’ operating as ‘and’.

So, takeaway lesson here is be more mindful of our tags , and thanks for taking the time to explain, its much appreciated.

The ‘AND’ operator would be extremely useful for some other scenarios we’ve been thinking about writing rules for - in the meantime, we’ll use the workaround of creating additional unique tags for these instances.