I've got an issue with a discount scenario. I'm not sure if this is a bug or what.

The client wants to offer 10 free products (fabric samples). Any additional fabrics are charged at the normal price of 50p. So the total for 10x is free, the total for 11 is 50p, 12x is £1 etc. The fabric samples are individual products with distinct skus and the quantity can be any combination, e.g 5 red + 5 blue etc.

To achieve this I've created 2 discount rules. The first discounts the Unit Price by 100% when the cumulative quantity is <= 10. The second discounts the order total by £5 when the cumulative quantity is > 10. Both are using the Property rule and accumulated quantity across all lines.

When I'm using 1 line (e.g. all the same sku), this works perfect. However when I add additional lines then I get a line total of 3p. Thats odd and I cannot figure how its getting that value. I've included some screenshots so you can see what i'm talking about.

I've tried changing the reward to order or subtotal however it reverts the line total, so 10 shows a line total of £5 where it really should be zero. Maybe that is better because with a Order Line discount, which line receives the discount when there are multiple lines.

Ahh, good point. Though I'm not sure how this would work then as effectively you are trying to distribute the discount across all order lines 🤔 (ie, you want to knock off £5 but across the accumulated order line amount, but then how do you state the discount amount of each line?)

I'll have a dig into why the order line totals are .03, but I'll need to think of the right option for applying the discount as I'm not sure how we'll do that one.

Yes I think with the Order Line reward the issue of which lines gets it or how is it applied to multiple lines is going be problematic and difficult to manage for a content author. Maybe accumulated quantity should not be used with with Order Line rewards ?

However I do think in my case the SubTotal reward is going to be the correct way and just let the line total show the non-discount total because the subtotal will be correct.

I've found where the issue is, but I gotta work out how to fix it.

The issue ultimately comes down to a rounding issue of sorts. Basically, when we are calculating the order line total, we have a Unit price of 0.5, which at a 20% tax rate works out at 0.4166666 price and 0.0833333 tax. However we round this up to be 0.42 price and 0.08 tax. Then to get the total order line price we multiply those by the quantity, 10, to get to an order line total of £5, but this is made up of £4.20 price and 0.8p tax.

When it comes to the discount though we are saying "take off £5, where that £5 already includes tax" and so we work backwards to work out the price / tax of that £5 which at a tax rate of 20% actually comes out as £4.17 price and 0.83p tax.

The problem is, we cap discounts to prevent going below 0, so when we deduct the discount, we deduct it's price part, but the tax part we can't fully deduct as it would make the tax -0.03 and so cap that at 0, but then the actual price is 4.20-4.17 which leaves you with your 3p.

I'll need to think of the best way around this is feels correct that we should round the unit price and multiple it, but then obliviously because the total is that multiplied by quantity, we get the same result price, but seemingly by a different approach.

Ok, well I think how we are rounding is fine, it just appears that you can round in different ways. We are performing unit-price rounding, where as you can also do line-price rounding which would wait to apply the rounding at the line total level which might help for this type of discounting.

Like I say, either are fine, they just say to be consistent.

With this in mind, I have made a small fix to the discounts calculation that says if the discount amount >= the order line price it's being applied to, I now set the discount price to be exactly as per the order lines calculation. This way regardless of how the order line total was calculated, as long as it adds up to the discount amount, the correct amount will be deducted.

This fix will be in the next 1.2.8 patch release.

So, in terms of your issue though, this would fix the .03p on the orderline incorrectly being applied, however it wouldn't fix the issue of the £5 discount being applied cumulatively. I think the Sub Total discount would in fact be the right way to go there.

Ok cool. FYI most of our clients use Sage and I know it rounds by line - many many hours of head-ache as they have line price breaks per quantity etc....

Anyway, I'm going with the subtotal discount and just let the lines show the unit price and line total with a total discount next to the subtotal. Its clear and simple.

Yea, I think it's a case that systems tend to do one or the other. I was just reading this issue tracker for the Drupal Commerce module https://www.drupal.org/project/commerce/issues/3044185 where they list a number of commerce platforms which do it in the two different ways.

There are clearly pros / cons for both approaches, but I think rounding per unit price (especially where Vendr supports bundles and sub order lines) fits best for Vendr. Unfortunately it does make it a slight pain when you want to get it into another system that does it the other way 🤦♂️

## Discounts with a Property rule issues

Hi Matt

I've got an issue with a discount scenario. I'm not sure if this is a bug or what.

The client wants to offer 10 free products (fabric samples). Any additional fabrics are charged at the normal price of 50p. So the total for 10x is free, the total for 11 is 50p, 12x is £1 etc. The fabric samples are individual products with distinct skus and the quantity can be any combination, e.g 5 red + 5 blue etc.

To achieve this I've created 2 discount rules. The first discounts the Unit Price by 100% when the cumulative quantity is <= 10. The second discounts the order total by £5 when the cumulative quantity is > 10. Both are using the Property rule and accumulated quantity across all lines.

When I'm using 1 line (e.g. all the same sku), this works perfect. However when I add additional lines then I get a line total of 3p. Thats odd and I cannot figure how its getting that value. I've included some screenshots so you can see what i'm talking about.

Hey Sean,

can you share some screenshots of your discount setups + discount rule configuration so I can try and setup a discount the same?

Ask, and you shall receive ;)

Thanks Sean,

Could you share screenshots of the the two "Total Order Line" rules, i'm mostly interesting in the "accumulate" flag.

I do think your last reward should probably be a sub total amount reward, but still, something is off so worth investigating.

Matt

I've tried changing the reward to order or subtotal however it reverts the line total, so 10 shows a line total of £5 where it really should be zero. Maybe that is better because with a Order Line discount, which line receives the discount when there are multiple lines.

Ahh, good point. Though I'm not sure how this would work then as effectively you are trying to distribute the discount across all order lines 🤔 (ie, you want to knock off £5 but across the accumulated order line amount, but then how do you state the discount amount of each line?)

I'll have a dig into why the order line totals are .03, but I'll need to think of the right option for applying the discount as I'm not sure how we'll do that one.

Yes I think with the Order Line reward the issue of which lines gets it or how is it applied to multiple lines is going be problematic and difficult to manage for a content author. Maybe accumulated quantity should not be used with with Order Line rewards ?

However I do think in my case the SubTotal reward is going to be the correct way and just let the line total show the non-discount total because the subtotal will be correct.

Cheers Matt.

Ok, so this is a fun one.

I've found where the issue is, but I gotta work out how to fix it.

The issue ultimately comes down to a rounding issue of sorts. Basically, when we are calculating the order line total, we have a Unit price of 0.5, which at a 20% tax rate works out at 0.4166666 price and 0.0833333 tax. However we round this up to be 0.42 price and 0.08 tax. Then to get the total order line price we multiply those by the quantity, 10, to get to an order line total of £5, but this is made up of £4.20 price and 0.8p tax.

When it comes to the discount though we are saying "take off £5, where that £5 already includes tax" and so we work backwards to work out the price / tax of that £5 which at a tax rate of 20% actually comes out as £4.17 price and 0.83p tax.

The problem is, we cap discounts to prevent going below 0, so when we deduct the discount, we deduct it's price part, but the tax part we can't fully deduct as it would make the tax -0.03 and so cap that at 0, but then the actual price is 4.20-4.17 which leaves you with your 3p.

I'll need to think of the best way around this is feels correct that we should round the unit price and multiple it, but then obliviously because the total is that multiplied by quantity, we get the same result price, but seemingly by a different approach.

Matt

Ok, well I think how we are rounding is fine, it just appears that you can round in different ways. We are performing unit-price rounding, where as you can also do line-price rounding which would wait to apply the rounding at the line total level which might help for this type of discounting.

Like I say, either are fine, they just say to be consistent.

With this in mind, I have made a small fix to the discounts calculation that says if the discount amount >= the order line price it's being applied to, I now set the discount price to be exactly as per the order lines calculation. This way regardless of how the order line total was calculated, as long as it adds up to the discount amount, the correct amount will be deducted.

This fix will be in the next 1.2.8 patch release.

So, in terms of your issue though, this would fix the .03p on the orderline incorrectly being applied, however it wouldn't fix the issue of the £5 discount being applied cumulatively. I think the Sub Total discount would in fact be the right way to go there.

Matt

Ok cool. FYI most of our clients use Sage and I know it rounds by line - many many hours of head-ache as they have line price breaks per quantity etc....

Anyway, I'm going with the subtotal discount and just let the lines show the unit price and line total with a total discount next to the subtotal. Its clear and simple.

Yea, I think it's a case that systems tend to do one or the other. I was just reading this issue tracker for the Drupal Commerce module https://www.drupal.org/project/commerce/issues/3044185 where they list a number of commerce platforms which do it in the two different ways.

There are clearly pros / cons for both approaches, but I think rounding per unit price (especially where Vendr supports bundles and sub order lines) fits best for Vendr. Unfortunately it does make it a slight pain when you want to get it into another system that does it the other way 🤦♂️

Maybe an ITaxProvider (or something) that had hooks for these various things like rounding etc when needed - would be very flexible.

Yea, a possibility. A couple of systems do ask how you want to apply tax rounding.

I'll add it to the issue tracker as an enhancement and see how many people come across similar issues. 👍

UPDATE:

Feature request has been created at https://github.com/vendrhub/vendr/issues/168

Just to let you know, 1.2.8 is out now with the small fix mentioned previously (not the selectable rounding options).

Thats great. Thanks Matt!

is working on a reply...