Feature request: Tier Pricing Feature and Price Lists

[osseonews]

Please add tier pricing to Vendure as doing this with promotions is not really viable. Tier pricing is sometimes known as bulk pricing.
Tier pricing is: Buy 1 of X for $100, or Buy 3 of X for $80, or Buy 10 of X for $50

An associated feature is to have each price associated with a price list, e.g. this is the price and tier price for CustomerGroupA and then this is the is the price and tier price for CustomerGroupB.

From what I can tell, Vendure is currently set up so that there is only one price per variant and you can only manipulate this price via promotions. However, the above functionality requires a bit of a different set up on the backend.

Thanks.

[michaelbromley]

I think this is almost possible now, but there is one missing piece:

We can, for instance, define a custom field on ProductVariant which is a string list which encodes the different tiers, e.g.

3:8000
10:5000

(we can use a custom form input component to make it nice to interact with in the UI)

Then we can provide an OrderItemPriceCalculationStrategy which reads this custom field data in order to determine the price.

The missing part currently is that the strategy is currently not aware of the quantity.

This could be added though, so the calculateUnitPrice() method also receives the current quantity of the order line. This would allow us to implement tier pricing.

It would also allow price lists based on CustomerGroup too, in much the same way.

[seminarian]

Nice to see this is already planned for v2!

Would be awesome if Price Lists could have lots of configuration parameters (e.g. channel, facets, start date, end date, ..) and that they support two modes:

• Override modus who just changes the price of a Variant
• Sale modus which has a price and Original price so frontends can show a % discount on their pages!

[michaelbromley]

The commit above adds the quantity arg to OrderItemPriceCalculationStrategy, which is the key to unlock this feature.

The exact implementation of where the tiered price data comes from is now up to the implementor - I'm not sure that we should build this into the core without more deeply understanding the possible requirements for such a setup.

My feeling is that it will be best implemented as a plugin external to core. Coming Admin UI improvements will make it possible for a plugin to define a UI for setting tiered prices, and I plan to add a guide to the docs on possible implementations of tiered pricing.