A. UX Improvement:
1. get rid of the `.0%` in the tax names (makes the UI a bit harder to read)
2. For TTC taxes, remove the TTC in the description to prevent it from appearing on the invoice's pdf
B. Tax issue:
Fix some mistakes in the taxes, based on reliable feedback of french partner Didier Six.
1. Fuel purchase taxes: shouldn't imact the P1_base and P1_tax grids because these are for petroleum product to sale.
Instead, put them in grid 20 (normal goods bought)
2. All tax "IMPORT":
- base line shouldn't impact the [{08/09/9B}_{base/tax}] tax grid as these are for sales operation in France and the [I{number}_{base/ tax}] are already there
Currently, the tax is putting up [{08/09/9B} _tax] and [Ix_tax] which induce a double calculation of the due VAT
- tax line should also impact the [24] `24 - Dont TVA déductible sur importations` in addition of the [20]
This tax grid isn't taken into account for the total deductible VAT calculation as it is after the total and label "dont TVA déductible[...]"
4. OSS: add the tax grid E3 on invoice base line and F8 on refund base line
task-3087037
closesodoo/odoo#107351
X-original-commit: 0cea284eec5d3d2bb9aa8d94c0edcb211ba08a50
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
The aim of this commit is to improve the test skipping code of the oss modules
by avoiding to hardcode the chart_template_ref (xml_id) directly in the error
message.
Before this commit:
The TestOSSSpain test class was failing when the l10n_es module wasn't
installed instead of being skipped.
After this commit:
The TestOSSSpain test class is correctly skipped instead of failing.
closesodoo/odoo#102770
X-original-commit: c8018174c483183f95cda2bd805eb003e2ab90f5
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Brice Bartoletti <bib@odoo.com>
The aim of this commit is to:
- allow OSS to use tax that aren't declare by TaxReportLine
- have the oss tax automatically populated with the correct tags for spanish
tax report
- Add taxes specific to the spanish OSS : No sujeto y acogidas a la OSS (Servicios) and No sujeto y acogidas a la OSS (Bienes)
using the official modulo 124 tag
closesodoo/odoo#101121
Community-pr: https://github.com/odoo/odoo/pull/99273
Task: 2930758
X-original-commit: 2a21e4c084ba952eba1b4a7bb6f6ee31875d70ea
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Camille Spiritus (casp) <casp@odoo.com>
Co-authored-by: Camille Casp Spiritus <casp@odoo.com>
This commit adapts account's model to the new report engine introduced for v16, and updates the data files accordingly.
account.report model is now declared in community, together with the other models used by the reporting. This is done so that the tax tags can properly be created by the tax report and used on tax templates. All the actual computation logic stays in enterprise.
See enterprise commit for full details.
Task 2524389
Part-of: odoo/odoo#94125
Task: 2856281
- Remove user_type_id, account.account.type model, internal_type
- Add account_type that is a simple selection field
- Move internal_group and include_initial_balance to account.account
- Because of these changes, type_control_ids on account.journal is also removed
closesodoo/odoo#93212
Related: odoo/documentation#2223
Related: odoo/upgrade#3595
Related: odoo/enterprise#28205
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
This commit aims to allow assigning tags to the taxes
created by the OSS feature by providing the xml_id of their
report.line in the eu_tag_map.py file.
Before this commit:
In l10n_be, the taxes created by OSS (l10n_eu_services) didn't set
the tag +47 on invoice_repartition_lines nor +49 on
refund_repartition_lines.
This make the VAT report for Belgium wrong.
After this commit:
Taxes created by OSS for a company using the belgian CoA will get
their tags set properly and thus will the taxes impact the
belgian tax report correctly.
task: 2770182
ticket: 2768622
Community-PR: https://github.com/odoo/odoo/pull/85607
Design choices:
This fix is currently solving the issue for l10n_be but we have
no doubt that it will be raised for other EU countries too.
In order to provide the tags, we decided to be consistent with
what as been done regarding the tax mapping. Thus we decided to
create and maintain a simple mapping file and to test it.
several other methods were explored:
- create a global variable and update it from all localization
modules. This method would work but is ugly and error prone.
- create a templating method and override it from localization
modules.
The problem is where to set the root of the template method?
The naïve solution would be to create a bridge module between
l10n_eu_services and l10n_be but that would lead to an explosion
in the number of bridge modules which we don't want.
In order to keep things simple and generic, we could put the
template method directly into the account module. But it is kind
of ugly because account shouldn't know anything about the oss
feature and it would encourage such a leaky design to happen
again in the future.
closesodoo/odoo#86314
X-original-commit: 7dcc2ae4665d2d7b577ed10160691775b86a848f
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Brice Bartoletti <bib@odoo.com>
Multivat means you are submitting its national tax report to a foreign country. In this case, you never want to use OSS taxes for that country. Hence, we exclude the countries for which we are submitting such a report when generating the fiscal positions for OSS.
closesodoo/odoo#77080
X-original-commit: ab2d2916e469586bb6c2b63c49de766369aa7277
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Before this fix, a cash basis OSS tax used together with a product using the "non-EU origin" tag didn't appear properly in the OSS import report. This was due to the fact the product tag was not copied on the cash basis move: it only appeared on the invoice, on non exigible lines.
To fix that, we make the choice to keep the product tag as markup on the invoice, and to copy it to the cash basis lines created from move lines containing this tag. We therefore need a non-ambiguous way to identify account.account.tag objects that are used on products, since we don't want to copy tags used by taxes. Hence, we introduct a new value for the 'applicability' field of account.account.tag, limitating their use to products.
closesodoo/odoo#76626
X-original-commit: 0dd712b876844c3e342447e4cf26b324fcaffc37
Related: odoo/enterprise#20916
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
This module is now used to support OSS taxes, which replaced MOSS a few months ago. This renaming follows the changes introduced in stable by https://github.com/odoo/odoo/commit/0e7c289003a0a69075188dbfaea724919dac32a4 .
[IMP] l10n_eu_oss: remove dead code from former l10n_eu_service feature
[IMP] account, product, l10n_eu_oss: community adjustements to support enterprise's OSS report
The following changes where introduced in order to support the features implemented in the new l10n_eu_oss_reports module:
- account.tag objects applicable on taxes are no longer required to have a country_id. This way, we allow using tags in generic reports (i.e. the ones available for multiple countries) as well.
- add account_tag_is on product.template and product.category: this fields are m2m to account.account.tag applicable on taxes. When making an entry from this product, these tags will be set on all the tax move lines created for it. We use it in OSS to differentiate between imported and non-imported goods in the report.
- always display country_id on fiscal positions' form view: OSS taxes require to be used in some fiscal position with a country_id set, so that we can infer the country they are mapping the vat from. We make that change in the view so that users are not obliged to create auto-applied fiscal positions to fix the OSS taxes they created manually, and can directly set the country on the fiscal position.
Task 2591541
closesodoo/odoo#73602
Related: odoo/upgrade#2669
Related: odoo/enterprise#19628
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Julien Van Roy