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
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
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
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
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 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
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
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 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
The `tax_amount` of move lines is by default set to `0.0`.
Nevertheless, this default value is set by Odoo,
not by postgresql.
This is therefore likely that the `tax_amount` is set as
null instead of 0.0, in database.
Therefore, when getting this value directly with a SQL
request, this is possible that `null` will be returned.
Therefore, in this specific case, `res.get(record.id, 0.0`
could return `False`, if the sum of `tax_amount` is `null`,
and try to multiply a boolean with an integer is not possible:
`_rec_get(rec) * rec.sign`
opw-633903
When doing a manual reconciliation, the current filter could restrict the
visibility of move lines and show empty results for some partners (e.g. filter
the lists on only one partner will show empty list of moves for other partners).
This is also the case for multicompany restrictions.
Integrate the current filter to the search to only get results for displayed
lines.
Fixes#3817, opw 618134
Fixes#5221, opw 632095
The name field contains the refund reason.
The reason is filled when you create the refund
from the refund wizard available when
pressing "Ask Refund" on a supplier invoice.
As this field wasn't visibile on the supplier
invoice form, this wasn't possible to change
the reason on draft supplier refunds after
having created them through the wizard, while
you could change your mind or having done a
silly mistake in the wizard, that you could
edit since the invoice is stil draft.
This was also not possible to set a reason
when creating the refunds without going through
by the wizard.
This was also not possible to change the reason
when you duplicated your supplier refunds.
opw-632756
closes#6301
Backport of 8.0 code, rev f61339b
Create a new journal item with an tax included, the automatically created tax
line had the amount computed as tax excluded.
Fixes#3731, opw 618305
The report generated by this wizard considered all the partners without taking into account
the filters and target entries set.
To show the right partner the function _set_context
must consider the "self.query" which sets the period, the dates, the states, the accounts and
the journals of the sql query used to give the demanded partner.
opw:631649
If a customer changed of company while having
account.move.line records in the former company he was in
It wasn't possible for someone else than the admin
to print the partner ledger report including this partner.
opw-631800
On an invoice, tax lines are generated in tax_line field. When modifying
manually the tax amount, the recomputed tax_amount field was incorrect in
multicurrency environment, leading to an entry with different tax amount and
debit value.
opw 611474
On a line write in a account.move.line tree view, the on_write return all the
sibling move lines of the written move line. The lines are then displayed even
if they do not match the current search domain.
This fix adds the context on the given on_write callback request, and in
on_create_write use a on_write_domain in this context to filter the returned ids.
fixes#3161, closes#5727
opw-630093
It is possible, if the user created a new country by himself, to have a country without a code, we then need to check that.
Fixes opw 629891, where the customer wrote "Belgie" trying to find "België", didn't find it and created a new "Belgie" country without code.
When having an invoice with multiple lines having the same
product_id and account_id, the residual amount was wrong.
This is due to the fact the residual amount of each line
was computed on the residual amount of the invoice divided
by the number of lines of the invoice, and the fact the main
select of the sql view was grouped by product_id, account_id.
So, for an invoice defined as
Product Account Total
A 1 10
A 1 10
B 1 10
The invoice analysis, grouped by product, account, computed
Product Account Total Residual
A 1 20 10
B 1 10 10
The residual amount '10' of the first line being
30 (the residual amount of the invoice)
divided by 3 (the number of lines in the invoice)
The residual amount of the invoice should actually be divided by
the number of lines in the invoice * the count
of occurences in the group by clause
So, in this case, (30 / 3) * 2 = 20
Replacing the big jointure by
SELECT count(*) FROM account_invoice_line l where invoice_id = ai.id
to get the number of lines in the invoice
is just an optimization for performances
opw-621672
Partners totals were not correct if the partner paid partially an invoice in advance
For an invoice of 20.000 in the future, with a payment made in advance of 5000
The column not due must contains 20.000, as the amount is not yet due
One of the column 1-30, 30-60, ... (accordingly on when the payment was made). must contains -5000
The total should be 15.000
This is related to rev. db98434e85
rev. abe5c803a0 forgot some partial reconciliations when the date domain was other than BETWEEN (for instance, <= stop date or >= start date, alone, not between)
Besides, the rev. abe5c803a0 did not care about account move being posted or not.
rev. db98434e85 took several times the same partially reconciled moves lines
Odoo Translation Bot
Olivier Dony
Matthieu Dietrich
Denis Ledoux
Thomas Rehn
Wolfgang Taferner
Goffin Simon
Martin Trigaux
Guewen Baconnier
Christophe Combelles
Nicolas Martinelli
Nicolas Lempereur
xmo-odoo
Joao Alfredo Gama Batista
Mohammad Alhashash
Somesh Khare
han-odoo
Rifakathusen Haradwala
David Monjoie
Laetitia Gangloff