2d42501a5b94de45e68a0b7ee8573aefc29500f0
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 wan
|
5125748616 |
[REF] account: remove chart template
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
|
||
|
Brice bib Bartoletti
|
ed1a35b3f8 |
[FIX] l10n_eu_oss: fix l10n_es test skipping
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. closes odoo/odoo#102770 X-original-commit: c8018174c483183f95cda2bd805eb003e2ab90f5 Signed-off-by: Quentin De Paoli <qdp@odoo.com> Signed-off-by: Brice Bartoletti <bib@odoo.com> |
||
|
Brice bib BartolettiandCamille Casp Spiritus
|
5e7da9c8ca |
[FIX] l10n_es,l10n_eu_service: OSS with Spain
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 closes odoo/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> |
||
|
oco-odoo
|
b7232b14b7 |
[IMP] account, l10n_*: Introduce unified reporting engine
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
|
||
|
Brice bib Bartoletti
|
b06ee24be8 |
[FIX] l10n_eu_oss:apply tag from localization
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. closes odoo/odoo#86314 X-original-commit: 7dcc2ae4665d2d7b577ed10160691775b86a848f Signed-off-by: William André (wan) <wan@odoo.com> Signed-off-by: Brice Bartoletti <bib@odoo.com> |