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

changed vat rate calculation logic #1194

Merged
merged 4 commits into from
Jan 26, 2024
Merged

changed vat rate calculation logic #1194

merged 4 commits into from
Jan 26, 2024

Conversation

OlegPhenomenon
Copy link
Contributor

@OlegPhenomenon OlegPhenomenon commented Jan 2, 2024

What does this PR address?

The issue here is related to the method override of the vat_rate column in the invoice table. It is expected that each invoice will have its unique vat_rate depending on the country associated with the user's billing profile, whether the user is an organization or an individual. However, due to the presence of the vat_rate method in the invoice model's code, it overrides the existing column, preventing data from being stored in the column and making the values dynamic. Additionally, since the Estonian income tax has been changed, these tax rate changes would also affect old invoices created before 2024.

To resolve this, it is necessary to eliminate this method and ensure that each invoice stores its own value so that changes in the tax rate do not affect old invoices.

What do I need to know?
In this PR, I have also included a rake task that allows you to go through all the accounts that do not have a vat rate and assign them a value. Ideally, this should be a separate PR and I will make it, because first the commands that assign the necessary values for the accounts are executed, and only then the current PR is deployed in production. This will help avoid errors, but for testing purposes, to simplify this PR, it also includes such a command: rake invoices:assign_invoices_vat_rate

What does this command do?

  • It takes all accounts that do not have a Vat Rate, takes the code of Estonia and those that do not have a vat code. Then it checks when these accounts were created, if before 2024, it sets the vat rate value to 0.2, if after, 0.22.
  • It takes all accounts that do not have a vat rate but do have a vat code and assigns them a vat rate of 0.
  • It takes all accounts that are not from Estonia and where vat_rate is nil, and assigns them a vat rate depending on the value of the country code column
  • When the user changes their billing profile, ensure that the payment amount also changes when the user switches to Everypay.
  • Check directo and e-invoice omniva

How to test?

  • Firstly, it is necessary to check the operation of the rake task and ensure that all the values assigned are correct for the invoices. The calculations should be taken in the context of Estonian accounts, considering when the account was created and whether the tax rate is correct. It is also important to take into account organizations and individuals from different countries.
  • Subsequently, it is important to make sure that the correct values are assigned for Estonian accounts. Also, check that correct values are assigned for foreign accounts and organizations.
  • Ensure that when changing the billing profile, the value of the active account is also correctly changed, while old accounts should not be altered.

@OlegPhenomenon OlegPhenomenon added the Not for merging for testing and development only label Jan 4, 2024
@OlegPhenomenon OlegPhenomenon removed the Not for merging for testing and development only label Jan 12, 2024
@vohmar
Copy link
Contributor

vohmar commented Jan 19, 2024

if billing profile country code is EE and invoice date is less than 2024 then vat_rate must always be 0,2. Currently all Estonian companies get vat_rate of 0,0 that is incorrect.

In one instance 0,0 rate was set on invoice with EE billing profile but no VAT code. This result is inconsistent with other results, but not sure what is different here (invoice id 284, billing profile id 3) @ staging other invoices with with the same billing profile have the same issue

@vohmar vohmar assigned OlegPhenomenon and unassigned vohmar Jan 19, 2024
@OlegPhenomenon OlegPhenomenon force-pushed the refactor-vat-rate-logic branch from daf8bfb to e9818e4 Compare January 22, 2024 11:27
@OlegPhenomenon OlegPhenomenon force-pushed the refactor-vat-rate-logic branch from e9818e4 to 1024b92 Compare January 25, 2024 11:44
@vohmar vohmar requested a review from maricavor January 26, 2024 09:45
@vohmar vohmar merged commit f863adb into master Jan 26, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants