Thanks for posting this suggestion here. This is the perfect place for suggestions like this. I remember the previous conversation that you are referring to and I’m sorry you felt that this suggestion was originally dismissed. That’s never our intention and we do absolutely want to help solve this, in order to make Breww work better for you.
Part of the difficulty of this suggestion is how to fit it into the existing structure, adding in as much flexibility as possible, but without making it all so complicated (or lengthy) that it’s too difficult to create delivery charge structures in the first place. We would really value your feedback and ideas on how this could be implemented.
Simply adding a new field named something like “Alternative price to charge if the order contains a keg”, feels too specific to your use-case, and if we go down this route, over time there’ll end up being huge numbers of extra fields and the whole feature will become to complex.
I’m thinking this could be implemented with something along the lines of:
- On a delivery charge structure, you can add some “rejection rules” and pick another delivery charge structure to use if any of the rules match. An example of a rule could be “At least [x] products of [container type list]” are in the order (in your case “At least 1 product of keg container type”). There could be other rules too, such as “At least 3 products have the ‘Core’ tag”, or “Total weight of order over 30kg”.
- If any of the rules applied, we would switch to instead use the alternative “fallback” delivery charge structure. This fallback delivery charge structure would have to have already been created in order to be chosen.
- You could add rules and a fallback delivery charge structure to the fallback delivery charge structure too, which would allow you to keep “falling down” through different structures until one matches. Ultimately, if none of the structures match, the delivery would be free.
At the moment delivery charge structures, can be picked on the customer/customer group/type/etc level and the above suggestion would mean that this was still the case, you’d just want to pick the one at the “top of the tree”.
What are your thoughts on this proposal? Do you think this would work for your use case, and wouldn’t be too complex to use? If you have any alternative suggestions, please do put them forward, as we want to build something that works well for you.
I’m also linking this to Deliveries By Weight as the two could be implemented concurrently, as they’re very related.