Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to calculate tax "Exclusively" from the gross sum. #65

Open
frequentredundancy opened this issue Feb 10, 2020 · 7 comments
Open
Assignees
Labels
enhancement New feature or request question Question about the code

Comments

@frequentredundancy
Copy link

Currently the tax in this package is calculated like this;

case 'tax':
                return round($this->priceTarget * ($this->taxRate / 100), $decimals);
            case 'priceTax':
                return round($this->priceTarget + $this->tax, $decimals);

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;

Product Price: 14.99
VAT: 21%

Current Method: 14.99 * (21 / 100) = 3.1479
EU Method: 14.99 - (14.99 / 1.21) = 2.6016

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.

@bumbummen99 bumbummen99 added bug Something isn't working critical Bug, feature, anything related to money calculations. question Question about the code labels Feb 10, 2020
@bumbummen99
Copy link
Owner

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?

@bumbummen99 bumbummen99 added enhancement New feature or request and removed bug Something isn't working critical Bug, feature, anything related to money calculations. labels Feb 10, 2020
@Sartoric
Copy link
Collaborator

Sartoric commented Feb 10, 2020

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

@Sartoric
Copy link
Collaborator

Sartoric commented Feb 12, 2020

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

@bumbummen99
Copy link
Owner

@Sartoric as always awesome work 👍! 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?

@Sartoric
Copy link
Collaborator

Sartoric commented Feb 19, 2020

@bumbummen99
Yep
I don't like this changes too, from a "coding style" pov 😁 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 ?

@bumbummen99
Copy link
Owner

@Sartoric Yeah i would not have made it any differently tbh, i think for now this will be just fine 😄 . Sure, further documentation and reminders never hurt 👍 : 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.

@github-actions
Copy link

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

@github-actions github-actions bot added the stale Inactive, will be closed soon. label Sep 26, 2020
Repository owner deleted a comment Feb 17, 2021
@github-actions github-actions bot removed the stale Inactive, will be closed soon. label Mar 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Question about the code
Projects
None yet
Development

No branches or pull requests

3 participants