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