[16.0][ADD] sale_margin_tax #213
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Hello @rousseldenis! In 16.0 it requires more work to hide the tax information in the report -- I'm not sure I've taken the best approach, and it is annoying as it also hides the margin tax total in the backend (maybe there needs to be a context key to know if _prepare_tax_totals is used in the context of the customer report or internally). |
When accounting for margin tax sales, the purchase price and margin (that form the base for the tax lines) need to be split. This is because a different tax grid should be applied on both line. However, Odoo does not provide a way to split the base as it does to split the tax. Furthermore, adding a 'margin' line type does not work because the functions that apply the repartition lines etc are basically impossible to override (they do not provide any hook, and the arbitrary compute order would make any tentative very brittle). To avoid these difficulty, another line is created on a "margin" product (a service), so that both the purchase and the margin can be accounted as base lines. This provide the advantage that no further override of basic accounting functions are needed, and that the tax rate of the margin tax is always either the initial rate (say 21) or 0. The downside is that it makes so statistics harder. Since the margin line and the product lines are linked by a many2one, it is still possible to extract the relevant info, just a bit harder. This refactoring also merges the margin behaviour from invoice and sale into a mixin to avoid desync of the essentially duplicated code (if only both line/tax fields had the same name...). This solved a bug where an invoice would think to be margin-based but without finding a witness margin tax. Last, this now handles the case where the margin is negative, in which case no tax is due.
len-foss
force-pushed
the
16.0-addmargin-len
branch
from
e73dacb
to
76768c6
Compare
|
There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. |
github-actions
bot
added
the
stale
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This module takes a simple approach to the Belgian margin tax.
https://finances.belgium.be/fr/entreprises/tva/assujettissement-tva/regime-imposition-marge
With this, the tax is due on the margin, that is to say the benefit made between the purchase price and the selling price of used goods (not taking into account any cost incurred in between, including refurbishing or repairing costs).
Note that the seller has to be able to track the purchasing price in their inventory.
There are different ways this can be done - by lot, serial number, retrieved from the purchase order, etc.
By default, this module assumes that the purchase price is the same as the cost encoded on the product.
This advanced behaviour can be implemented on overriding modules.
When such a tax is used, the actual tax amount has to be computed at invoicing time.
Moreover, the actual tax amount should be hidden from the report, and an obligatory note has to be present on the invoice.