We allow creation of QR-Bill codes when they are issued from
another country than Switzerland.
Steps to reproduce :
1. Enable QRcode Bill in Accounting settings
2. Set a valid Swiss QR-IBAN account on your company.
(Contact > CH Company > Accounting tab > Bank Accounts:
Set account number to `CH21 3080 8001 2345 6782 7`.)
3. Set the CH Company's country to something else than Switzerland.
4. Create a Swiss partner (be sure to set all address/ZIP/city/country=CH).
5. Create an invoice to that Swiss partner and post it.
6. Click Print QR-BILL, it will raise an error.
closesodoo/odoo#127798
Task: 3359821
X-original-commit: c456c78e347c707b0f5b684b47631e5566963289
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
The return tax should only be used through its parent tax,
we don't want it to be accessible directly on bills or invoices.
opw-3347425 (2nd issue)
closesodoo/odoo#126803
X-original-commit: a87bb033a3b02bf91f0958e8ee8a5202b297cd68
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
* l10n_ae, l10n_ar, l10n_at, l10n_au, l10n_bg, l10n_br, l10n_ch,
l10n_cl, l10n_dk, l10n_es, l10n_hu, l10n_in, l10n_mn, l10n_nl, l10n_no,
l10n_pt, l10n_sa, l10n_se, l10n_sg, l10n_si, l10n_uk
Some localizations do not have any default account for tax closing.
This leads to the opening of a RedirectWarning when trying to do a tax
closing.
task-3082332
closesodoo/odoo#124003
X-original-commit: 14abe7acb11d522fb2b4a274ac0eb06d41e637ed
Related: odoo/enterprise#42071
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Swiss taxes retrieved by module update (and the update of taxes it triggers)
need to be active, even if the template data was set to inactive.
closesodoo/odoo#121580
X-original-commit: 04f0be5
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Claire Bretton <clbr@odoo.com>
Switzerland changes its rates at the beginning of next year,
this change already has some implications on client's flow so
we add them to the localization so they can coexist with old rates till
the end of the year.
Changes:
- Added new taxes (2.5% -> 2.6%, 3.7% -> 3.8%, 7.7% -> 8.1%)
- Added tax fiscal positions to match those taxes
- Added tax groups
- Adds migration script to l10n_ch to apply those changes
Task: 3162286
X-original-commit: acd14e6f7f91755ea9b058eb7ab957b133266145
Part-of: odoo/odoo#121580
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 names so that it's more clear for users
closesodoo/odoo#114673
Task-id: 3052677
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Until 15.0, to show the behaviour of the QR billing in Switzerland, you had to manually configure a bank account for CH company and create a QR Bill compliant customer before creating an invoice, which was time consuming in the contaxt of a demo.
Updated the demo company's bank account and added an adequate customer to ease the process.
task-3264826
closesodoo/odoo#120349
X-original-commit: 69aab9f4db89f8bf3ba8f29a96fbf9eabd4bac4a
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
In Switzerland, it is mandatory, when a QR bill is printed, to use a line to separate both the QR part from the rest of the page and, within the QR zone, the receipt from the payment part.
This was done using dotted lines on the bill.
However, while generating the PDF caused no problem, the snailmail provider can't print the bottom, far left and far right borders since those are outside of the printing zone.
After further research it does however seem that those are not mandatory, unlike the two separations aforementioned.
Removed those to allow for snailmail printing.
opw-3223714
closesodoo/odoo#119728
X-original-commit: 1326ad2a21e2d9aade1ad2ff4444e595c1caabad
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
The method `_find_or_create_bank_account()` is defined for an
account.bank.statement.line so that it returns either the bank
account found or created. The extension made by l10n_ch does not
return the record found/created by a call to super(), which may
break reconciliations.
The code for the reconciliations in which a record is expected to
be returned can be seen at: https://github.com/odoo/odoo/blob/
c0eb0d41a3e6c1c766278884a745d45952799393/addons/account/models/
account_bank_statement.py#L1232.
The original implementation of `_find_or_create_bank_account()`,
where a record is returned always, is at: https://github.com/
odoo/odoo/blob/c0eb0d41a3e6c1c766278884a745d45952799393/addons/
account/models/account_bank_statement.py#L1282-L1291.
closesodoo/odoo#118451
X-original-commit: 6c7385c74fafbe84042261e29565a77e2ca0c03c
Signed-off-by: Laurent Smet <las@odoo.com>
Removing external links from localization manifests and redirect to our own documentation. Ensure that users can learn about our standard localization modules from a source of information that we have authorship on.
closesodoo/odoo#117005
Task-id: 3248632
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
How to reproduce
================
1. Load the accounting & any of the modified l10n modules
2. Take any of the languages supported by the selected l10n module
You'll see that all the terms remain in english
opw-3114100
closesodoo/odoo#113572
X-original-commit: 13b619477977254d5cb070d716e0c07f87cb7407
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When trying to add a QR code to an invoice, if some conditions weren't met, the user would more often than not get a message simply stating :
"The chosen QR code is not eligible with this invoice".
This was confusing to the user, since the reason for a QR code to not be eligible are multiple : invalid IBAN, unavailable in X country, wrong currency...
Modified the _eligible_for_qr_code function to _get_error_messages_for_qr() so it returns an error message if the qr code is not eligible, and None otherwise.
task-3069753
closesodoo/odoo#116482
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
The fiscal country was changed each time the user modified his
company's country. This caused problems (in particular at onboarding)
because it was not done transparently for the user and possibly
overrided his setup.
After this commit, the fiscal country will behave like this:
- When we install Invoicing/Accounting, it is set by default to company's country
- When we install CoA, it is set to the CoA's country, if there is one (override above setting)
- It is **no longer automatically changed** when the company's country changes.
Fixes related tests that depended on the previous way of compute fiscal country.
closesodoo/odoo#116322
Task: 3221792
X-original-commit: ac1f2a5774a2f8d03003b481829f6e183ab0b713
Related: odoo/enterprise#38623
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Claire Bretton <clbr@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#116167
Related: odoo/enterprise#38542
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Since 16.2, a condition was added to _get_available_qr_methods :
if self.env.company.country_id.code == 'CH':
rslt.append(('ch_qr', _("Swiss QR bill"), 10))
This condition was not allowing a multi-company call, and caused another issue.
Once the method was called to check on the eligible QR choices, the ORM would consider the current company to be the US default one.
Hence the condition would never be fulfilled and a stacktrace would appear :
Oh snap!
Wrong value for account.move.qr_code_method: 'ch_qr'
Reverted back to the unconditional behaviour, and will check this occurence with the framework team.
closesodoo/odoo#115952
X-original-commit: cdba8a062985bfbdcbe8d51aa9705e702b4dee61
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Camille Spiritus (casp) <casp@odoo.com>
Since v16, the QRR reference would always be set at 000000000000000000000000000.
This was because of a conflict in the computation dependencies in account_invoice.py: _get_invoice_computed_reference (account_move) was called on a draft invoice, which hadn't compute its name yet. Since the computation of the QRR invoice checks for this name in order to integrate it into the reference, the space dedicated to the name was instead filled with 0 (see _compute_l10n_ch_isr_number).
By manually computing this field, we ensure the reference computation can be completed.
This fix allows for a correct behaviour in v16, while a more sustainable change will be made in master.
closesodoo/odoo#115071
X-original-commit: 7852b0ee4dddf6cf96b6ce40cf7c24011b9ef33a
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
The type fields of actions already defaults to
the model name in the base model definition.
Therefore, specifying `ir.actions.server`, `ir.actions.act_window`
& so on as type is useless (and adds noise since it's the same as
the action model).
closesodoo/odoo#114539
Related: odoo/enterprise#37855
Signed-off-by: Julien Castiaux (juc) <juc@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
A lot of the separate files were kept up to now because it made the
process easier while applying the script to rebase.
The files can now be merged.
Some code is also cleaned by using CSV instead of a python dict.
Part-of: odoo/odoo#114164
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
The aim of this commit is to fix the export fiscal position for invoices between Switzerland and the Principality of Liechtenstein in the Swiss localization.
context:
This commit corrects the Swiss national fiscal position, in accordance with legislation that considers Switzerland and Liechtenstein to be a common fiscal territory of application for VAT.
Previous to this commit:
- When the use create an invoice with a customer from Liechtenstein, the correct VAT is not applied because transactions to Liechtenstein were considered as export transactions.
After this commit:
- When the use create an invoice with a customer from Liechtenstein, the correct VAT is applied because transactions to Liechtenstein are considered as domestic transactions.
closesodoo/odoo#111578
Task-id: 3151891
X-original-commit: 773ad35af4b4d6d8ec608875ded6b5f22ecad1dd
Signed-off-by: Erradi Mohammed (moer) <moer@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
This is mostly a cleaning/refactoring change.
The current API for init hooks (pre, post, uninstall) is to pass
`cr, registry`.
But the first thing which was done by most
post init and uninstall hooks was to create an env using
the cr passed
e.g.
`env = api.Environment(cr, SUPERUSER_ID, {})`
and the `registry` argument was unused in all these hooks,
completely.
By changing the API of hooks to pass `env` instead
of `cr, registry`, we gain in average two lines in every
hooks:
- the line creating the env `env = api.Environment(cr, SUPERUSER_ID, {})`
- the line importing `api` and `SUPERUSER_ID`
Therefore removing ~250 lines of repeated code lines accross odoo/odoo and
odoo/enterprise.
In addition to these lines removed,
it also ease the API of init hooks for Odoo developers,
who are used to that `env` and not so much how to create an `env`
from a cursor.
Part-of: odoo/odoo#108254
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>
Aim :
Allow customer from Switzerland to emit an invoice with a QR code to a SEPA customer.
Context:
In Switzerland, adding an extra page containing a QR Bill is mandatory in many cases, mainly when the customer is also from Switzerland (although there are other conditions).
However, activating the option 'QR Codes' in the settings (which is not linked to the QR Bill) can cause problem.
For instance, it will be impossible to bill a foreign customer, because we check that the conditions are right to emit a swiss QR (which is a bug).
After this commit :
The new behaviour is :
- Swiss user --> swiss customer: don't change the invoice, allow to create a QR Bill
- SEPA option activated, swiss user --> SEPA customer : join the SEPA QR to the invoice
- SEPA option activated, swiss user --> swiss customer : raise error
task-3062570
Manual fw-port of https://github.com/odoo/odoo/pull/109808closesodoo/odoo#109935
X-original-commit: a9980477048e4adffda4a71a72ff1cc8490637f9
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
One line of the tax report was still in plain French while the code should always be in English
Translate the data and update pot/po files.
closesodoo/odoo#109480
X-original-commit: bc8ff80b84d650c34224315097742cb878404f5b
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Some translations were lost when we changed to 16.0 since there is no l10n project for 16.0 on Transifex.
Reintroduced lost translations for Arabic, German, French, Italian, Dutch and Chinese.
Task: 3126103
X-original-commit: b2794c76fea71011c92212808bfd2bf2edf42645
Part-of: odoo/odoo#109480
The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@odoo.com>
Germany and Switzerland both use the DIN5008 paper layout and encoutered some issues while printing an invoice's pdf.
In Germany, the display of pdf invoices changed with v16.0. The header and footer would always display borders, which would mess up the rest of the display.
Adding the 'table-borderless' class solved this problem.
In l10n_ch, this issue was also encountered, and the general display of the qr bill page was set off. This is problematic since this display is highly rigid.
Those changes seem to be linked to wkhtmltopdf unability to process some of the Bootstrap5 changes.
While waiting for a more long term solution regarding wkhtmltopdf and BS5 compatibility, calling directly the adequate external_layout allows us to get back a correct QR Bill.
task-3037921
closesodoo/odoo#105464
X-original-commit: 627b0f581801705f8e2d2f2bead5176e9af884f8
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Camille Spiritus (casp) <casp@odoo.com>
Due to the deprecation of t-esc to the unique use
of t-out in the rendering template, this replace
every usage of it and ensures everything continues to
work as inteded. Removing deprecation warnings
polluting terminal
deprecation commit: odoo/odoo:9ce5bc8881ae06b613ef61eb07453b224f62bae6
closesodoo/odoo#103731
Related: odoo/enterprise#33037
Signed-off-by: William André (wan) <wan@odoo.com>
Modules:
- hr_maintenance;
- maintenance;
- l10n_ch;
- l10n_generic_coa
- l10n_il.
The plural of "equipment" is "equipment" and not "equipments"
changes in the enterprise version: odoo/enterprise#31498
Remark:
Runbot test log:
Two fields (equipment_count, equipment_ids) of maintenance.equipment.category() have the same label: Equipment. [Modules: maintenance and maintenance]
Two fields (equipment_count, equipment_ids) of hr.employee() have the same label: Equipment. [Modules: hr_maintenance and hr_maintenance]
Using "Equipment Count" to differentiate them
opw-2981186
closesodoo/odoo#100558
Signed-off-by: Adrien Widart <awt@odoo.com>
The early payment cash discount functionality was merged in 16.0.
This PR allows for the behavior to be as localization specific as possible.
This concerns :
The tax computation (some countries leave it untouched after the discount, some countries discount it, and Belgium has a mixed behaviour)
The account in which the cash difference resulting of the cash discount should be put.
task- 2983913
related to #99572closesodoo/odoo#102032
X-original-commit: 591757902dcdf1e3609d9c5ae23e2b134ee8e4da
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Camille Spiritus (casp) <casp@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
Creditor Reference is one of the 3 allowed references type in swiss QR-Bills (with None and QR-Reference)
It is used with normal IBAN (QR-Reference must be used only with special QR-IBAN)
Fixes#71578Closes#81269closesodoo/odoo#95518
X-original-commit: 8e1d86dcb10aebc1be1a318126492573a4b74331
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Only for terms containing Credit Note and expenses
closesodoo/odoo#97840
X-original-commit: 1754b094a66476a0bdb29fe60dc5583c03336c3f
Related: odoo/enterprise#30262
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
TLDR:
* invoices are implemented using computed methods instead of onchange
* the synchronization only happens when switching tabs in the Form view
to improve perfs.
_______________________________________________________________________
The whole engine of the synchronization of Invoices to the Journal
Entries has been refactored
* by using computed fields instead of onchange functions
* by synchronizing only from invoice to journal entry in `create` and
`write`
* by saving when switching tabs on the Invoice form, to synchronize
before showing the values
This comes with numerous advantages:
* no need to call the onchange methods manually
* no need to use the Form emulator to build invoices (i.e. EDI, OCR,
intercompany, ...)
* the performance for invoices with many lines improves drastically, going
from 2 minutes to 4 seconds to create an invoice with 500 lines
* the model is more declarative, we can now see how the values are computed
instead of having the values being copied from various places.
* remove the hack in `onchange` that disabled the recursivity of it,
which was unexpected and needed to be managed manually in all the
onchange methods
This means that:
* Some fields need to be exclusively computed on journal entries values
or invoice values, more specifically the Tax Summary widget.
It is now
- computed from entry lines, when opening the view
- computed from invoice lines when changing those, because the tax lines
will need to be recomputed anyways, erasing previously set values
- set with an inverse function when saving; after the sync has been done
* Some possible operations previously possible have been dropped.
(i.e. look at the removed test test_in_invoice_line_onchange_accounting_fields_1)
This is because such a behavior was undefined (how is changing the balance going
to affect the unit price? How is the amount currency going to affect it?)
_______________________________________________________________________
Implementation Details
----------------------
The "dynamic lines", meaning the payment terms and the tax lines are now
only created in the `create` and `write` functions.
In order to reduce code duplication, it has been implemented using
context managers used in both `account.move` and `account.move.line`
These context managers help comparing the values before/after, acting
like a local `onchange`, but getting benefit from the dirty flags from
the `compute` dependences.
This is relying on computed fields on the move (`needed_terms`) and on
the lines (`compute_all_tax`) which contain the values needed for the
related move.
Depending on the needed values and the existing values (`term_key` and
`tax_key`, respectively) the context manager will determine what needs
to be created/updated/deleted.
Some related changes are to produce a `dict` instead of a `str` for the
`tax_totals` (previously `tax_totals_json`) fields, by simplicity to
reduce the complexity of IO, and simplicity of debugging, because the
logic of the field needed to change (cannot be computed at the same time
anymore since it needed the lines to be synced)
By simplicity, and also because it makes more sense, some boolean fields
have been merged into `display_type`:
* `is_rounding_line`
* `exclude_from_invoice_tab`
* `is_anglo_saxon_line`
The `price_unit`, `quantity` and other "invoice fields" are now not set
anymore on lines that are not product lines since it didn't make any
sense to have it.
Performances
------------
You have to keep in mind that a simple `create` didn't compute a lot of
fields, for instance not taxes were set, no payment terms,...
Now it does.
```python
import random
from timeit import timeit
from odoo import Command
domain = [('company_id', 'in', (False, self.env.company.id))]
products = self.env['product.product'].search(domain).ids
partners = self.env['res.partner'].search(domain).ids
taxes = self.env['account.tax'].search(domain).ids
def create(nmove, nline):
self.env['account.move'].create([
{
'move_type': 'out_invoice',
'partner_id': random.choice(partners),
'invoice_line_ids': [
Command.create({
'name': f'line{i}',
'product_id': random.choice(products),
'tax_ids': [Command.set([random.choice(taxes)])],
})
for i in range(nline)
]
}
for j in range(nmove)
])
# After | Before
print(timeit("create(1, 1)", globals=globals(), number=1)) # 0.11 | 0.09
print(timeit("create(100, 1)", globals=globals(), number=1)) # 2.76 | 2.50
print(timeit("create(500, 1)", globals=globals(), number=1)) # 14.56 | 12.34
print(timeit("create(1, 100)", globals=globals(), number=1)) # 1.03 | 5.52
print(timeit("create(1, 500)", globals=globals(), number=1)) # 3.99 | 125.02
print(timeit("create(50, 50)", globals=globals(), number=1)) # 19.44 | 79.55
```
Another metric that can be used is running the test suite with
`--test-tags=/account` (only `account` installed)
* before: 404s, 267127 queries (366 tests)
* after: 318s, 232125 queries (362 tests)
Why this commit title?
----------------------
Someone told me that this was the perfect way of naming your commits.
c04065abd8
task-2711317
closesodoo/odoo#96134
Related: odoo/upgrade#3715
Related: odoo/enterprise#29758
Signed-off-by: Laurent Smet <las@odoo.com>
The render API was confusing as mixing the access to the report and
the rendering env.
The ambiguity was present for code such as
`report.sudo()._render(record_ids)` where it was not clear if the
`sudo()` is needed to access to `report` or to `record_ids`. For low
priviledge users (such as portal or public), it was common to use
`report.with_user(SUPERUSER_ID)._render(record_ids)`.
This PR changes the render methods signature to be `api.model`. The
`report_ref` can be:
- ir.actions.report external id
- ir.actions.report id
- ir.actions.report recod
- `report_name` value
This will allow to call the report methods with any user and no longer
need to use `with_user(1)` to render reports as public user.
Task-id 2670865
closesodoo/odoo#91341
Related: odoo/upgrade#3650
Related: odoo/enterprise#27323
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Just fixing a typo in _render_qweb_pdf_prepare_streams().
closesodoo/odoo#97182
X-original-commit: 9cf1061b9a463e67e46468b5bf83a0e2059ded77
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
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>
The only option to print a QR Invoice was to go on the invoice page and to click on the Print QR Button.
This PR allows for a user to print multiple QR codes, selected from the Invoices view.
The download occurs normally if all invoices are valid and QR-printable.
A wizard opens when the whole invoice selection isn't valid. It allows to download the invoices as a single pdf or to see a list of the ones that could not be printed in the QR format.
The wizard's text depends on the number of QR-valid, ISR-valid and classic (non QR, non ISR) invoices that the user tried to print.
All invoices for which a print is asked will be printed with a QR bill if it is possible. If not, this will check if printing in the ISR format is possible. Lastly, if none is possible, the classic invoice will be printed.
The behaviour allowed for the removal of the QR PRINT and ISR PRINT buttons on the single invoice view, for a behaviour closer to the original guidelines.
Bills can't be QR printed.
Corrected QR-Bill CSS.
task-2726507
closesodoo/odoo#82341
Signed-off-by: Laurent Smet <las@odoo.com>
Claire Bretton (clbr)