For example, I may have one discount applied to multiple casks, another rate to a combination of cask & keg, and another to smallpack volume, and, perhaps, a discount based on overall order value.
It would be most useful to be able to specify multiple discount rules which may apply to an order. including which lines (or container types, or tags) are to be considered for the calculation of the discount due from that rule, and to specify which lines (or container types, or tags) are eligible to have those discounts applied to them.
It’s also going to be useful to require that “firing” of certain rules can suppress the application of others. (There’s a number of ways this might be done, either by explicitly grouping rules such that only one rule in a group should be active [or the group emits only one discount], or by rules emitting discount codes which can be applied only once - i.e. duplicates are removed, so that group membership is expressed by rules emitting the same code. But that’s implementation. So I’ll shut up.)
Thanks, Jon. I see where you’re coming from, but I must admit that I’m a little concerned that we could implement something so incredibly powerful and customisable that it’s too difficult for most people to actually use.
I’m happy to keep this open to pick up votes and support/ideas, but wanted to highlight that we have to consider the trade-off between customisability and usability.
You’ve got requests in for enhancements that would only be well addressed by something like this. Shopify does something similar as I remember.
Bottom line, a single discount rule per order can never capture what (some? how many?) people need to do. As it stands, Breww’s discount rules are (a) difficult to set up - the interface has got 9 fields (it won’t all fit on the crap screen I’ve got on the desktop here), the trumping of one rule by another is (b) obscure, and (c) it’s weak (in that we can’t do stuff that’s obvious).
A more powerful system needn’t be confusing or obscure, and can, of course, be capable of expressing simple, single rules - which might cover many users.
I appreciate that there are other priorities, and thank you for your reply.
It’s not a single rule per order, it’s a single rule per line item on the order.
This takes us back to what was mentioned in Price books rule with different discounts per product type, where (unless you wanted the multiple rules to all apply after each other) there would have to be some way to tell Breww to disregard a suitable rule for one later down the tree, even though rules which you have placed as a higher priority fit the line item first.
I do agree with you that it is already complicated to the point where it can be difficult to use, which is why we are sceptical to add further to it. Of course, if there are lots of customers who cannot do their discounting via Breww because of this, then we will certainly look into it, but this is the first we’ve heard of this specific problem.
It’s not a single rule per order, it’s a single rule per line item on the order.
Thank you for the clarification, I thought that seemed odd, am still struggling to get my head around it. But it’s not per line item is it? Since we can “Match any of the filters below” So it’s per-whatever-combination-of those-things we specify? Is that right? Or am I still confused?
In my limited experience - hardly anyone does their discounting (except for very simple cases) solely with Brewws discount rules. I suspect it’s more common to use a combination of Breww and externally realised business logic. (gags)
Thanks again for the suggestions and comments, and Matt for the extra insight. As this isn’t an actionable feature request, I’m going to close the thread to in order to keep the list “clean”.
If anyone in the future wants to re-start this discussion, please feel free to open a fresh thread
