Discounts apportionment issues about lunar

[glennjacobs]

I'm happy with the calculation proposal.

In terms of the Cart UI, how would you propose we display it to the customer?

[ryanmitchell]

Is the UI not the developers decision?

Looking at it again (and the work done on AmountOff) it just means creating $line->discountTotal, $line-> subTotalDiscounted, and I think a new $line->taxTotalDiscounted (based off $subTotalDiscounted) so that you get the revised tax figure (but still access the original one should you need it for whatever reason).

[glennjacobs]

Yes, the UI is up to the developer, but we want to support the developer with the right information and sometimes an opinion on how to implement it.

Are you wanting this tax figure so you can show the before price with tax included? If the system allowed for prices to be stored inclusive of vat, would you use that approach instead?

[wychoong]

Can this be configurable in someways? There are situation that doesn’t need VAT/HMRC and just simply wants the free item to be $0

Currently can we replace the BuyXgetY/amountOff and substitute with own flavor?

[ryanmitchell]

For the end user I don’t want to show the apportioned price at all. But the warehouse system integration needs it to be apportioned

@wychoong what I’m suggesting won’t affect the existing implantation.

[glennjacobs]

I am keen to ensure figures are correct for accounting purposes. I know this is specific to UK VAT, but my understanding is accounting principles are fairly standard.

@ryanmitchell how will you continue to show the item as free in the UI if we're changing the price totals?

[ryanmitchell]

I actually wonder if we need to change the approach a little and have a new $line->apportionedDiscountTotals or something like that.

$line-> apportionedDiscountTotals = [
   'subtotal' => x,
   'tax' => y,
];

That way you have options:

1. you can output the original values (eg £0 for the discounted item)
2. you have the discountTotal line if you want to show each line original total with a discount amount underneath
3. you have the subTotalDiscounted if you want to show each lines new subtotal inc discount
4. you have the apportioned totals if you want to show the apportionment totals

[glennjacobs]

I guess it could work, but it's getting a little complex.

[ryanmitchell]

It definitely is! I'm open to other suggestions.

[glennjacobs]

Worth checking how Shopify does it, and whether that conforms to HMRC requirements?

[ryanmitchell]

They dont seem to handle it until reporting, as they can get away with that sort of thing. I'll try some things and see what I can come up with to keep it as clean as possible, maybe we hide it behind a config variable so those that dont want it dont get it.

[ryanmitchell]

Ok, I've pushed some updates to the BuyXGetY branch I was working on: 479f299

When an item is in a discount it works out what its 'share' of the discount is (based on its price percentage of the overall pack price before discount) and applies this to a new CartLine property apportionedDiscount.

This value would then allow developers to calculate what they want - eg subtotal - apportionedDiscount = taxableSubTotal

I've also added this property to FixedAmount discounts as it was calculating discount differently (based on qty not price).

There also doesn't seem to be any consideration given to multiple discounts applying to the same item - the discount amount gets reset each time, instead of compounded. This will definitely cause issues. You'll see in BuyXGetY I've left some comments where this needs to be considered.

Anyway, the intention here is to spark thoughts, not that this is the final solution

[glennjacobs]

There also doesn't seem to be any consideration given to multiple discounts applying to the same item - the discount amount gets reset each time, instead of compounded. This will definitely cause issues. You'll see in BuyXGetY I've left some comments where this needs to be considered.

Should this be a separate issue?

[ryanmitchell]

There also doesn't seem to be any consideration given to multiple discounts applying to the same item - the discount amount gets reset each time, instead of compounded. This will definitely cause issues. You'll see in BuyXGetY I've left some comments where this needs to be considered.

Should this be a separate issue?

Pulled it out separately as #885

[ryanmitchell]

After some Discord chat its looking like apportionment would need to be handled by the developer, so I've opened up #884 as a starting point for providing the information required for this to be calculated.

[ryanmitchell]

Closed by #884