To determine the account.move.line to reconcile, first it tries to match with
the ref and the amount of the account.bank.statement.line and if it doesn't match,
it just tries to match with the amount.
opw:643867
When printing these reports from the accounts list
Accounting > Configuration > Accounts > Print menu > General Ledger
the ID of the wizard was considered as the ID of an account,
leading to obvious issues when this ID wasn't available
in the account_account table, or when the user
do not had the access rights to see the accounts with this
ID.
The override was completely useless: The wizard is
launched whether you print these reports from
Accounting > Reporting > Legal reports > Accounting Reports
or from the accounts list, and the super _get_account can
be called correctly for these two use cases.
opw-643589
This fixes 2 issues.
First, it keeps consistent the precision required for posted entries and the
precision for the balance assertion. This could be an issue if the account
precision is larger than 4.
Then, it makes sure to round the amount with the appropriate precision to avoid
numerical errors. For example 1.2344 - 1.2345 = -9.999999999998899e-05, which
is indeed smaller than the required precision 10 ** -4.
A minimum precision of 10 ** -5 is kept for historical reason.
Fixes#7276
opw-643305
A variable "lines" is instancied few lines above,
with the exact same browse call, and there is no
operation that could lead to an update of the result
between these two browse calls.
Closes#1394
During tests, some creation of user records would unnecessarily trigger
password reset or set a password, both of which would trigger password
hashing which takes some time (for good reasons).
Fix by:
* passing no_reset_password in YAML tests and some Python tests still
missing it (a number of Python tests already used it)
* removing passwords from YAML records as they're never necessary, the
test user records are not expected to ever log in
When invoicing in currency A and being paid in currency B, the exchange
rate between those currencies might differ between the invoice date and
the payment date.
When reconciling, invoiced amounts should be converted using the invoice
date exchange rate.
opw-640248
In the Account Tax Decalaration wizard,
Accounting > Reporting > Generic Reporting > Taxes > Taxes Report,
When not choosing the start/end period, but choosing
a fiscal year, the fiscal year was simply ignored,
the report took a fiscal year randomly.
In addition, if no fiscal year was chosen,
the fiscal year randomly chosen could even
not be a fiscal year of the right company,
in a multi-company environment.
closes#7219
opw-643194
The computation of total_invoiced field was very slow when the size of
account.invoice.report grows. This is due to usage of the field
user_currency_price_total that requires to build the full view (generates query
(id in []) for function field).
Using temporary SQL view (inspired by caf333e), directly filter the needed
items and avoid building the full table.
Fixes#6654
This allows to reset correctly the domain of UoM if the product is not set.
Without this patch, the domain used is the domain of the previous product in
the list.
opw-642074
The Taxes report gives the possibility to choose a chart of tax.
This chart of tax wasn't respected when printing the report,
all taxes from all chart of taxes of the company were printed.
opw-642362
When we change a product line of an account invoice, a current unit with
a invalid unit category was not dropped which should be since:
- it is different from a sale.order,,
- there is a domain on the unit of measure only allowing units from the product's unit category.
This fixes drop the current unit of mesure in this case.
opw-640985
When processing the reconciliation of invoices with bank statements
in foreign currencies, this is possible that there is a cent of difference,
due to the fact
the sum of amount exchanged could not be equal to the exchanged
sum of amount received.
For instance,
with a company in EUR as currency,
with a rate of 0.033 for USD,
with an invoice of 2.00 USD
(60.606060... rounded to 60.61 EUR)
and a bank statement of two lines of 1.00 USD
(30.30303030... rounded to 30.30 EUR)
The exchanged invoice amount, 60.61 EUR, is not equal to the sum of
statement lines exchanged amount (30.30 + 30.30 = 60.60 EUR).
In such a case, two journal items should be created in addition:
- 0.01 in the debtors account
- 0.01 in the foreign exchange loss account
opw-640078
The tax_amount on account.move.line generated from the validation of an invoice
did not include the taxes with 'include in base amount' enabled.
Instead of using the line total, use the price_unit of the tax which is
correctly computed through compute_all method.
Fixes#5939
If the whole view relates to a specific group,
apply the group on the view itself instead of
each view part (each fields, each page, each div,...),
so the view is loaded / added to the base view
only if the user is in the right group.
So the view is not loaded uselessly
and the fields are not read for nothing
(performances & security).
Indeed, when a group is applied on a field itself, the field content
is read, but hidden, therefore reading the content of the field
uselessly, and potentially leading to accesses issues
if the user hasn't the rights to read the field.
(e.g. reading a property when not having access to the model
of the proprty, pricelists on partners for instance)
opw-634402
When duplicating confirmed bank statement lines,
the many2many `move_ids` links were preserved, and,
therefore, there were links between the duplicated
lines and the move entries of the original lines.
Closes#6617
Odoo Translation Bot
Goffin Simon
Denis Ledoux
Christophe Simonis
Nicolas Martinelli
Daniel Dico
Xavier Morel
Julien Legros
vrenaville
Martin Trigaux
Commandant Custo
Nicolas Lempereur
Olivier Dony
xmo-odoo
Joao Alfredo Gama Batista
Stéphane Bidoul
Matthieu Dietrich