Bundle vs Range pricing in variants

[partomas]

Hello,

I appreciate the new pricing features in CRM, but I've noticed a missing attribute in my case. Specifically, I'd like to differentiate between pricing per unit and pricing for a "bundle."

For instance, in our scenario of selling software licenses, the pricing structure involves:

Per Unit: €29 - 1 unit or €18 per unit for a order quantity in the range of 4-10
Bundle Pricing: €49 for a 2-license pack or €59 for a 3-license pack

Customers can choose a quantity from 1 to 10, and the price should be calculated based on whether it falls under the range pricing or bulk pricing for the specified quantity.

This enhancement would greatly benefit scenarios where both unit and bundled pricing options are applicable.

Thank you for considering this request.

[yuri]

It should not be a pricing feature. It could be a bundle/kit feature. A bundle would be a Product with type = "Bundle" or "Kit". Unlikely to be implemented soon. For now, I'd recommend creating separate product records for bundles.

Though I don't understand your request fully. It would be the same as having prices for >1, >2, >3 qty what is already possible.

Please consider to prefer creating topics in the Extensions category. To discuss the functionalities before requesting new features. There might be not needed as already possible.

[Laimonas]

Here is the pricelist of one product. Quantity Tier from 11 to 25 price set per unit, other prices are for the total amount.
The quick fix could be an additional parameter in the ProductPrice entity to mark if is it "unitPrice" or "priceForWholeQuantity".

[yuri]

As it's not a bug, no need fixing. Quick fixes often hurts product development. It looks more as adapting for a specific use case. I believe the proper solution is using different product entries. In other ERPs there's a Kit/Bundle concept. One bundle could contain 2 same products. Bundle is implemented as a Product itself.

What if there're also 3Y, 10Y. Would that mean that we will need to create separate fields for each?

[partomas]

Yes, in case 3Y, 10Y options as variant we'll need a prices for these variants as well.

The issue is that pricing for the same product may be presented either as a 'price per unit' when purchasing a specific quantity or as a 'total price' for the entire quantity. It would be helpful to include an attribute that allows identifying whether it's a price per unit or a total quantity price. This would enable the system to accurately calculate the sales prices for the end customer when providing quotes...

[yuri]

> It would be helpful to include an attribute that allows identifying whether it's a price per unit or a total quantity price.

It's a matter of a simple division operation. When entering the price, just divide it by the quantity. Or you can utilize formula in the spreadsheets before importing prices into CRM.

> The quick fix could be an additional parameter in the ProductPrice entity to mark if is it "unitPrice" or "priceForWholeQuantity".

It's better to fix your pricelists to be consistent rather than adding a new functionality. Such a "fix" will be harmful for future development. It really overcomplicates things that are not visible from the surface. Thing is that the Price Book Price must represent a Unit price for an SKU and nothing else.