When creating a new bank account
e.g. Accounting > Configuration > Accounts >
Setup your Bank Accounts
When the user leaves the journal blank,
a journal, and an account associated to this
journal, are automatically created.
The account type of the account created could be wrong,
as it used the account type of the parent of the first
account of internal type `Liquidity`, which
could not be an account of account type Cash or Bank, but of
account type 'View', and such an account type does not
have the right delivery forward method, in order to report
correctly the amounts when closing a fiscal year.
Instead of using the account type of the parent,
it should actually uses the account type of the sibbling,
which have a correct delivery forward method
opw-647311
in method `button_confirm_cash` of `account.cash.statement`
The check was verifying that the profit/loss account
was set on the journal, and if it was, it raised that it
wasn't, which is obviously wrong.
This was solved in Odoo 8.0 by replacing the code
by something more readable in 9dc9169, and the same
logic to check that the profit/loss accounts are
set is still there.
Closes#2924
For account.tax.code and account.tax.code.template.
Sequences on account.tax.code are used for reporting.
However, it wasn't possible to edit them through the client.
Neither through the form view or the list view with a handle.
Fixes#1844Closes#2656
The Journal field is not hidden anymore when filtering on the 'journal_id'. The
reason is that the filter might correspond to several journals. Therefore it is
not possible to know what is the journal corresponding to a given journal item.
The same is applied to the Period.
Fixes#7793
opw-646292
In the aged balance report, the reconcile entries are excluded
except if the reconciliation date is greater than the date for which the aged balance report is requested.
But this exception should never include opening entries.
opw:643172
A log analysis showed that the normalized query below was executed very often
with a slow explain plan using a seq scan.
```sql
SELECT move_id, date
FROM account_move_line
WHERE journal_id = <journal_id>
AND period_id = <period_id>
AND create_uid = <user_id>
AND state = 'draft'
ORDER BY id DESC LIMIT 0;
```
This query is called in the _default_get of account.move.line to find the last
unbalanced move line.
The existing index can be improved to cover this query as well, showing an
impressive improvement of the explain plan as explained here:
https://github.com/odoo/odoo/pull/7430#issuecomment-119521031Closes#7430
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 duplicating analytic accounts, child accounts are duplicated as well.
The custom copy method removes the analytic lines but this applies only on the
first copy. As the copy_data method recursively copies child accounts, these
child accounts did not use the custom copy method but the basic copy_data.
Move to copy_data
Fixes#6368, lp:1149676
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
This revision is related to dd47b6f5bc.
The above revision was allmost correct, except that, in a supplier
invoices, the `amount_currency` of the invoice is negative,
and the one of the bank statement is possitive.
To check that both are equal, we should subtract one to each other,
and check that the diff is 0, but both part need to be the
absolute value.
opw-634263
closes#6533
When processing the reconciliation of a bank statement
within the company currency with an invoice in a foreign currency,
avoid to recompute the bank statement debit / credit within
the currency rate at the time of the invoice when the
`amount_currency` of the bank statement line and the `amount_currency`
of the invoice move line are the same
(while having the invoice move line and the
bank statement move line in the same currency,
and having the bank statement currency and
the company currency the same),
to prevent gain/loss exchanges during currencies conversion.
Computing the amount of the statement line
within the currency of the invoice is useful
to compute the difference of amount paid within the company currency
when a change of currency rates occured between the invoice date
and the date of the payment.
Nevertheless, recomputing the amount in the currency of the company
is useless when the payment currency
and the company currency are the same,
and the amount of the invoice and the statement in the foreign currency
are identical, since the amount is already computed, within the
debit/credit field of the invoice move line.
Besides, this prevents gain/loss changes.
opw-631748
opw-632133
opw-631895
closes#6559
When the target currency is the company currency, there
is no need to re-compute the debit/credit amounts of the move lines,
since these debit/credit values already contains the amount
of the move line within the company currency.
Avoiding the recomputation prevents gain/loss during currencies exchanges
opw-631748
opw-632133
opw-631895
If a line of the invoice move was in a foreign currency
but its residual amount in this foreign currency was 0,
the `amount_residual` (in company currency) was used,
instead of the `amount_residual_currency`, which
is the residual amount in this foreign currency.
This was due to the fall back with the `and / or` statement.
Using `if / else` instead solves the issue.
This could lead to issues when the residual amount
in the foreign currency was 0, but the residual amount
in the company currency was 0.01, due to the exchange rate
loss.
In SQL, the addition/subtraction between NULL and an integer/numeric
returns NULL.
Therefore, if either debit or credit was set to null instead
of 0.0, debit-credit returned null, instead of the actual subtraction
opw-634044
- ctrl-enter only persist balanced reconciliations
- give a reconciliation proposition only if there's an unambiguous match
- added some missing tanslations
- use default order to display statement lines in reconciliation widget
When searching if a many2one property field is not set, there may be less
results since only the ones with a reference set to NULL are returned.
We should also get those not in the table.
This commit change this case so instead of returning ['id', 'in', {matching non-set ids}],
the ['id', 'not in', {matching set ids}] is returned.
e.g: if (1, 3, 8) are set, (5, 9) are not set. ['id', 'not in', (1, 3, 8)] would
be returned instead of ['id', 'in', (5, 9)] which might not select all non-set
property fields.
closes#6044
opw-631057
The SQL view implementing the "Invoice Analysis" report
JOINs the res.currency.rate table in order to obtain the
correct currency rate to convert each invoice line amount
in the same currency.
The matching of the rate needs to be done on the date
of that rate (`name` column) - the last rate preceding
the invoice date is presumed to be the right one.
However there is no simple way to make a direct JOIN between
account.invoice.line and res.currency.rate with a single
match, without using an ORDER BY clause and LIMIT 1.
This requires a costly SUBSELECT query for each invoice
line, quickly becoming prohibitive.
Through the use of PostgreSQL's Common Table Expressions
(CTE) it is possible to construct a temporary table
with the rates' start and end date of application.
This temporary table can then be used in a direct
JOIN with account.invoice.line, delivering much better
performance (no SUBSELECT needed for each invoice line)
On a database with 50k invoice lines this makes invoice
analysis return results in less than 800 ms instead of
10+ seconds.
The domain on account.account was preprocessed in search method but it had no
effect on read_group. This lead to inconsistency or errors when using 'goup by'
filter.
Move domain processing in '_where_calc' method instead as this is used by both
'search' and 'read_group'.
This reverts commit 24526b18a7.
The journal_id field is not present on account.account but is processed in
search method.
Next commit will improve the processing to also accept journal_id in read_group.
The function _unite_compute and _unit_compute_inv did not give the same display result.
Regardless the way the tax is computed, the display must be the same. The display must
only shows the name of the tax.
opw:633828
The Tax Report printed with details should not include draft accounting entries.
Technicaly, the account move lines include in a draft account move do not have to be
printed
opw:633642
Denis Ledoux
Christophe Simonis
Thomas Rehn
Wolfgang Taferner
Richard deMeester
Odoo Translation Bot
Goffin Simon
Martin Trigaux
Nicolas Martinelli
Guewen Baconnier
Leonardo Pistone
Christophe Combelles
Daniel Dico
Xavier Morel
Julien Legros
vrenaville
Commandant Custo
Nicolas Lempereur
Olivier Dony
xmo-odoo
Joao Alfredo Gama Batista
Stéphane Bidoul
Matthieu Dietrich
Arthur Maniet
Mohammad Alhashash