samuelbirch
commented
5 years ago Hi,
Changing the number of decimal places won't be an issue. Let us have a think about how to implement the base cost + extras feature. It might be a case as you suggested, implemented as a custom modification. - Should all be doable though :)
Hi!
I have a feature request for you guys. I just found your plug-in yesterday and tested it out. So far, it's pretty great and may enable us to take advantage of Craft Commerce in the way we had hoped. We have pricing that varies by quantity. So having this field type certainly simplifies how we're able to get that to work in Commerce.
However, there's one aspect of our pricing structure that still poses a challenge for us: for orders of 1k units or more, we charge a base price for the initial $1k + extra for each additional 1k. Something like this:
Initial 1k: $100 Extra 1k: $10 per thousand Remainder (anything less than 1k): added % of Extra 1k
Here's an example: Quantity: 2046 (1k initial + 1k extra + 46 remainder) Remainder: 46/Extra 1k = $0.46
Total: $100 + $10 + $0.46 = $110.46
Currently, the way I have the Bulk Pricing field type implemented is by creating separate columns for each quantity range. We have lower quantities for 250-499 and 500-999, but for 1k and beyond, I created separate columns for each 1k up to 10k. I basically just calculated the per unit price for each range, which gets us close. However, there are 2 limitations this poses for us:
1) It appears that only 2 decimal places are being used in the Commerce calculations. For example, one of our per unit prices is $0.352. But the unit price Commerce is implementing is $0.35/unit. Not a big deal for small quantities, but it starts to add up with higher quantities.
2) We sometimes have orders in the quantity of tens of thousands and offer even higher, though orders that high are rare. To offer the correct pricing, we would have to add far too many columns (1 for every 1k), simplify our pricing considerably, or find other ways of manipulating higher quantity prices in order to take advantage of Commerce. Solving for this limitation automatically takes care of #1.
Currently, we don't have an e-commerce system in place. We've just have a custom quoting system in place within Craft that uses javascript to calculate pricing on-demand using a lot of math and if statements based on quantity, country, and a multiplier price that we use to create pricing adjustments in some cases. But we're hoping to move to Commerce mostly for the order management and automation capabilities. The pricing is the tricky part for us.
Would it be reasonable to extend your plug-in to accommodate more advanced pricing structure for base + extra pricing? Or would you be interested in building a custom modification of Bulk Pricing for us if that was necessary?