We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#115543
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Taxes have a `description` field that has been hijacked to
represent tax label on invoices. We want the description field
to be used for its original purpose, thus created a dedicated field
`invoice_label` in which we transferred `description` content.
We also make description translatable.
This is part of the Tax Taxonomy 2 rework.
Task: 3052677
Part-of: odoo/odoo#113236
Rewrite the whole chart template mechanism, removing the templates
stored in the database. The new format will mainly use CSV.
Speed up install time
---------------------
* About half of the time of installing a localization for the first time is
taken by creating the template records. This new in code format gets
completely rid of this.
* Creating the template records could often not be done in batch because
of parent/children relations.
* The instanciation of the accounts on the company has been entirely
reworked too, by
- optimizing the order of creation of records to avoid UPDATE queries
- using precomputed fields to avoid UPDATE queries
- updating the translation in batch
- deactivating logging in the chatter
- avoiding access rights checks by checking the rights at the start
Overall, when installing a chart template for the first time, it is 4
times faster because half of the time spent on saving the template in
the database is not done at all anymore, and the instanciation on the
company is more than twice as fast.
Reduce technical debt
---------------------
There is no need to synchronize the templates with the real records
anymore. No need to use hooks to copy the data from one to the other.
It is easier to change a template in a stable version, which can often
be necessary due to legal reasons (i.e. a change of tax rates, reporting
tags,...)
Two modules have been removed:
* `l10n_generic_coa`: since there is nothing left datawise in this
module, it can be integrated in `account` for free. It is just code
and CSV.
* `l10n_multilang`: the fields that this module modified to be
translatable are now always translatable:
- there was an issue when updating modules that deleted all the
translations because the fields were not translatable at some point
during the loading of the registry, then they because translatable
again but lost all translations because of the column type change.
- most devs are not able to understand all the languages needed for
all the localization available. Therefore, english has been added in
the sources in most localization to understand better issues while
debugging.
- no need to call post init hooks anymore, doing the sync with the
templates.
- more: see "Translations" section
Because most of the data is now in CSV, it is also easier for product
owners to edit, audit, modify files themselves, removing one layer
during trivial development processes when only data should be changed.
More flexibility for declaration
--------------------------------
The data declaration can now be done easily in python or CSV.
A nice feature is that you can declare everything at once, even for some
more complex chart of accounts:
* if you have to set default taxes on accounts, would need to
- declare the accounts because accounts are required on the taxes
- declare the taxes
- declare the taxes to put on the accounts
This would lead to scatter information in multiple files. Now,
everything can be declared in the same place and the loading of the
chart of accounts will do the 3 steps automatically.
* if you have a relation of child/parent, you would first need to
declare the parents then the children, and the loading would not be
efficient because done one by one. Now, everything is done in batch
automatically without having to think about it.
It is also easier to update fields on records where there was no field
for that on the templates, like
* setting a restriction for journals on accounts
* setting specific values on the company
* modifying journals and linking them easily by using the xml_id instead
of having to compute it manually
Translations
------------
Some countries have multiple languages (i.e. Belgium uses officially
French, Dutch and German, and the CoA also has an official English
version) and we must support the languages in all these countries.
All these translations are known, and hard coded without using out
translation platform (Transifex). We also like to have the English
version (even if an official one doesn't exist) so that support can be
done more easily in databases using chart templates in other languages
(especially using a non roman alphabet).
Because the translations were not on Transifex for these records, it was
really hard to maintain: the translation templates (`.pot` files) were
not easy to extract as the automatic export would give values mixing
both the CoA and the menuitmes, the fields' strings,... But we don't
want to translate the CoA as we already know the value.
Managing the translations in the `.po` files was also annoying:
- it is easy to forget that the translations need an update too
- it requires a special editor, special terminal commands that everyone
is not familiar with
- it is easy to make mistakes in the source string
The new format is the following: `field@en_US` where `field` is the
translatable field (usually `name`) and `en_US` is the locale code.
This allows to have the whole declaration on one line, everything in one
file. It also makes the process easier when debugging: instead of
searching for the translation in the `.po` files, it directly appears
next to the configuration of the account/tax/... .
Update of the code
------------------
The code can be updated using this script
https://github.com/william-andre/transform_coa
Forward ports can be managed too by stashing/resetting/checkout the new
modules or the changes in the modules updated in the same PR.
task-2687567
Part-of: odoo/odoo#110016
There is a lot of use case where reports are exclusively in the company
currency, or have columns only in this currency. In these case, showing
the currency symbol is redundant, takes space and makes the reading
slower.
With this change, we will avoid displaying the symbol in a variety of
use case where it is not needed.
Task id #2868674closesodoo/odoo#109666
Related: odoo/enterprise#35671
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
To allow people from v16.0 to have the new module in EURO, we added the module l10n_hr_euro in stable, this PR modify the l10n_hr module to allow people to migrate without problem since l10n_hr_euro become l10n_hr in master.
Also the old module l10n_hr of the stable version will be added so that they can keep an history. But like the other, we renamed the module to facilitate the comprehension.
l10n_hr in stable become l10n_hr_kuna in master.
closesodoo/odoo#108511
Task-id: 3102242
Related: odoo/upgrade#4154
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Improving:
- Chart of account
- Tax report
- Fiscal position
- Translation
Task-id: 2753362
Signed-off-by: Maximilien La Barre <malb@odoo.com>
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#99450
Related: odoo/enterprise#31003
Signed-off-by: William André (wan) <wan@odoo.com>
Following reportalypse, reorder the menu items in order to bring
some consistency to the report menu.
Also clean the menu items by removing all the menu items no longer
used since most reports are now selectable by going on the generic
reports and then switching to localized ones.
Task id #2965755closesodoo/odoo#99210
Related: odoo/enterprise#30854
Related: odoo/upgrade#3831
Signed-off-by: William André (wan) <wan@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>
Storno accounting is the term used to described the process of recording
a reverse action as a negative amount on the same site instead of a
positive amount on the opposite site of the credt/debit.
For instance, when one creates a credit note for an invoice, the values
of debit and credit will be kept in the same column with negative signs
instead of swapping columns like in non-Storno accounting.
It is a business practice commonly used in Eastern European countries.
Countries where Storno accounting is mandatory or considered as best
practice would be :
Czech Republic, Poland, Romania, Russia, Slovakia, Ukraine, Croatia,
Bosnia and Herzegovina, Serbia, Romania, China, Russia, Slovenia
It is available as an option in the settings and is automatically
activated for some countries which use this type of accounting.
otask-2064899
closesodoo/odoo#79581
Related: odoo/upgrade#3212
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: william-andre <wan@odoo.com>
Co-authored-by: qdp-odoo <qdp@odoo.com>
Many changes involved several localizations.
Tax groups data files that were missing the country_id:
AR, AU, EC, ET, HR, HU, IT, JP, LU, MN, NZ, SI, UK, ZA
Account_data.xml files being renamed or split to account_tax_group.xml
AT, CH, CL, PE, SK
Tax templates that were missing tax group information:
CH
Tax groups missing that were added:
EC
Part-of: odoo/odoo#77295
In the hr localization, some of the tax report lines have a line code
without tag name, and are then used in some formulas.
This is incorrect since the tag name is needed to get a balance.
This PR will fix this by removing the codes and their appearance in the
formulas, since these lines have no incidence in the result.
Task id #2376724closesodoo/odoo#62487
X-original-commit: d9e4673b9fe9785ff5fb193bb3c915025eddbb8c
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: Nicolas Viseur <vin-odoo@users.noreply.github.com>
In a general manner,
the chart templates should not be set to noupdate,
that way, if a new company starts in an existing database,
it starts with an up-to-date chart of accounts.
For instance,
if the chart of template is not updated from
12.0 to 13.0, the `default_pos_receivable_account_id`
is not added in the chart template,
and when a new company is created,
the default pos receivable account is not set on the company.
Besides, the field `res.company``account_default_pos_receivable_account_id`
is not displayed on any form view,
whether or not the full accounting is installed,
so we must especially pay attention this default account is well set
from start, as the user as no opportunity to correct this by himself.
In addition,
in upgrade scripts,
the default pos receivable account on the chart template
is used to correctly set the pos receivable account on the company
and on the pos payment methods,
so it must be well set for the upgrade script to do its job correctly.
Technically, it means, without this revision, the fields:
- `account.chart.template``default_pos_receivable_account_id`,
- `res.company``account_default_pos_receivable_account_id`,
- `pos.payment.method``receivable_account_id`
were not filled properly on upgrade,
causing critical issues in the accounting entries on pos session closing.
Related to #52786
Related to odoo/upgrade@ccfd2371efclosesodoo/odoo#52870
X-original-commit: 3258ba015ff75b7c176d83a44261d24ebfcc26de
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Task 2092079
Accounting firms that want to give access to their customers avoiding
mistakes and risks will love this profile that can't do anything
wrong... Maybe as well as companies auditors..?
closesodoo/odoo#39860
Related: odoo/enterprise#6576
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
- Introduce a new account.tax.report object
> Tax report lines now refer to a tax report, and the tax report to a country
- Tax report lines can share tags accross reports within the same country
> To support the cases where some report is a simplified version of another one: some of its lines can be computed in the same way as the 'bigger' report.
> This is done by giving the same tag_name to the tax report lines, and the same country_id to their parent report.
> Full support for tag name modification, and the way it impacts the shared tags (sometimes, we can overwrite them all, sometimes we must delete them, sometimes, we create new tags to replace them on some report lines).
- Support copying tax report (and the lines/tags linked to it), so that it is possible to duplicate them and change the country set on the duplicate for use in another country (coopying is way better as replacing in place, as we don't keep any link to an xmlid, and still allow using the original report in the original country it was created for).
- Make all l10n* modules compatible with those changes
closesodoo/odoo#38964
Related: odoo/enterprise#6217
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Before, we only had a public method that installed
the CoA for the current active company.
With the multi-company changes, it was not
possible anymore to install a module with a
demo company and then have the CoA installed
in that demo company correctly.
We changed that public method to be able to
put an extra optional parameter and shortened
its name to try_loading instead of
try_loading_for_current_company. The method that
it calls when there is no chart installed
is made private and renamed to _load.
closesodoo/odoo#35703
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
[IMP] l10n_*: don't define accounts or tags on tax repartition line templates anymore for 0% taxes
[FIX] account: remove old function used to migrate the former tax model, incompatible with the new one
A new feature[*] in point_of_sale (PoS) which minimizes the
creation of account.move records in closing a pos.session relies
on a receivable account made specifically for PoS.
This commit addresses this feature's requirement by adding a
new receivable account to each localization.
[*] point_of_sale: single AE for a pos.session
TASK-ID: 1862388
- Add repartition lines on taxes
- Link account tags directly to account.move.line; remove the tag_ids field from account.tag
- Add a new report engine dedicated to tax reports, directly generating account tags. It is called as an alternate mode of generic tax report, with a dedicated "Use tax grids" toggle.
>> The biggest change lies in the way the new tax report computes its values.
Everything is now aggregated directly using the tags set on the account move lines. Thanks to that,
modifying the configuration of a tax today will not impact the report for the previous periods anymore.
This is a big improvement, as it means the report will keep on reflecting the values that were submitted
to the state before, whatever the configuration change.
- Add an audit char field to account.move.line telling with tax grids are impacted by the line, with the corresponding amount
- Modify the behavior of cash basis taxes: the cash basis account is now used as the transition account, while the regular account given in tax declaration is used to store the final entry (it was the opposite before)
- Modify every l10n_* module in order to keep them consistent with these changes
closesodoo/odoo#32833
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Purpose
=======
Accounting reports are quite confusing for an accountant as the menuitems doesn't to have a clear structure.
Specifications
==============
Move all the localizations menuitems to the first position under `Reporting`
Put the `US GAAP` report menuitem items under the localizations and rename it accordingly
[MIG] l10n_ae : Migrated to new API.
[MIG] l10n_ar : Migrated to new API.
[MIG] l10n_at : Migrated to new API.
[MIG] l10n_au : Migrated to new API.
[MIG] l10n_be : Migrated to new API.
[MIG] l10n_bo : Migrated to new API.
[MIG] l10n_br : Migrated to new API.
[MIG] l10n_ca : Migrated to new API.
[MIG] l10n_ch : Migrated to new API.
[MIG] l10n_cl : Migrated to new API.
[MIG] l10n_cn : Migrated to new API.
[MIG] l10n_co : Migrated to new API.
[MIG] l10n_cr : Migrated to new API.
[MIG] l10n_de : Migrated to new API.
[MIG] l10n_de_skr03 : Migrated to new API.
[MIG] l10n_de_skr04 : Migrated to new API.
[MIG] l10n_cn_small_business : Migrated to new API.
[MIG] l10n_cn_standard : Migrated to new API.
[MIG] l10n_do : Migrated to new API.
[MIG] l10n_ec : Migrated to new API.
[MIG] l10n_es : Migrated to new API.
[MIG] l10n_et : Migrated to new API.
[MIG] l10n_fr : Migrated to new API.
[MIG] l10n_generic_coa : Migrated to new API.
[MIG] l10n_gr : Migrated to new API.
[MIG] l10n_gt : Migrated to new API.
[MIG] l10n_hn : Migrated to new API.
[MIG] l10n_hr : Migrated to new API.
[MIG] l10n_hu : Migrated to new API.
[MIG] l10n_in : Migrated to new API.
[MIG] l10n_it : Migrated to new API.
[MIG] l10n_jp : Migrated to new API.
[MIG] l10n_lu : Migrated to new API.
[MIG] l10n_ma : Migrated to new API.
[MIG] l10n_mx : Migrated to new API.
[MIG] l10n_nl : Migrated to new API.
[MIG] l10n_no : Migrated to new API.
[MIG] l10n_nz : Migrated to new API.
[MIG] l10n_pa : Migrated to new API.
[MIG] l10n_pe : Migrated to new API.
[MIG] l10n_pl : Migrated to new API.
[MIG] l10n_ro : Migrated to new API.
[MIG] l10n_sa : Migrated to new API.
[MIG] l10n_sg : Migrated to new API.
[MIG] l10n_si : Migrated to new API.
[MIG] l10n_syscohada : Migrated to new API.
[MIG] l10n_th : Migrated to new API.
[MIG] l10n_tr : Migrated to new API.
[MIG] l10n_uk : Migrated to new API.
[MIG] l10n_us : Migrated to new API.
[MIG] l10n_uy : Migrated to new API.
[MIG] l10n_ve : Migrated to new API.
[MIG] l10n_vn : Migrated to new API.
casp-odoo