Open frequentredundancy opened 4 years ago
According to this german source the calculation is correct. In fact, you are right if you assume the price does already include tax but the workflow of this package is to use the ->priceTax
getter in order to display the correct value as it simply adds the tax to the net resulting in the gross. Therefore you can use it legally.
Does your implementation depend on the tax to be inclusive?
It's common practice, in ecommerce application, to have a parameter to define if item prices are including or excluding taxes. This package is using net prices as default (as vat is optional) so we don't separate/exclude the VAT in calculation.
That said, I'll take a look if we can easily add such parameter to enable gross price as base price
I had some time today, and I've checked it and I've made a test version
I've added a config option to set gross price as base price (default is false to be backward-compatible) I had to add a new property priceNet to store the calculated and rounded (to avoid rounding issues) net price. It's available only when using gross price.
Note When using gross prices, it should be kept in mind that discount is calculated on net prices, as commonly done.
In fact I've sent a PR but I didn't meant to ... anyway give a try to the branch feature-gross-price
@Sartoric as always awesome work :+1:! So from the code side it seems pretty straight forward and i saw nothing obvious. I have seen another fork today that also modified the calculation, that got me thinking if we should not abstract the __get
part somehow in the future so ppl. can use the provided implementations or simply hook in their own without the hassle of creating a whole new package and missing out all the future updates.
@frequentredundancy If you want you may please take a look at the feature-gross-price branch and check in if there is anything obvious that would block your implementation?
@bumbummen99 Yep I don't like this changes too, from a "coding style" pov :grin: I just did it in order to quickly test it. I would like to keep things customizable by the user and having a clean and lean code.
Should we add a new "enhancement" issue to keep track of it ?
Out of curiosity, which is the fork ?
@Sartoric Yeah i would not have made it any differently tbh, i think for now this will be just fine :smile: . Sure, further documentation and reminders never hurt :+1: : I think it was this one https://github.com/manojo123/LaravelShoppingcart but i had not much time looking into it and what he is trying to achieve.
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days
Currently the tax in this package is calculated like this;
But in the EU, it is common that prices are listed VAT inclusive and use a different formula. It's calculated like so;
VAT calculation formula for VAT exclusion is the following: to calculate VAT having the gross amount you should divide the gross amount by 1 + VAT percentage (i.e. if it is 15%, then you should divide by 1.15), then subtract the gross amount, multiply by -1 and round to the closest value (including eurocents). The last two operations are not mandatory since you see the VAT value even before you do them.
Source: https://vatcalconline.com/
To see the difference, let me give an example;
Is it possible we can get this as a configuration option whether we want it to be inclusive or exclusive? Since technically speaking anyone currently using this to calculate VAT isn't doing it correctly and there could be issues legally because of this.