The `account.account` `name` can be translated
as soon as `l10n_multilang` is installed.
Not passing the context in the calls to
the `search` method prevented to search
on the translations of this name.
Closes#4511
During reconciliation wizard, the wizard tries to find the best match with
exisiting unreconciled lines.
When more than one line could be reconciled with the bank statement line, the
oldest line was not selected.
e.g.
- statemement line: 10€
- invoice 1: 10€
- invoice 2: 10€
- invoice 3: 5€
The statement line was reconciled with the 5€ invoice instead of the first one.
This was due to the domain not matching when the exact same amount was found.
Sign CLA for compassionCH
Closes#8767
The domain for the analytic account in the `reconcile with writeoff` wizard
should be based on the `type` field, which must be `view`,
not on the `parent_id` field, as it's done everywhere else
(e.g. in the supplier invoice form).
`[('parent_id', '!=', False)]`
and
`[('type', '!=', 'view')]`
is almost the same, but the second domain is more appropriate.
Closes#4562
In the case where target_currency == company_currency, the actual_debit or the
actual_credit must be equal to the amount_residual defined on the account.move.line
and expressed in the currency of the company. The actual_debit/actual_credit must
take into account the possible partial reconciliations and this is done by the
residual amount.
opw:648744
In Accounting > Bank and Cash > Cash Registers, when clicking in "More" button
on 'Put Money In' or 'Take Money out', the date used for the bank statement line
created must be the date of the bank stattement(same behaviour then when clicking
on "Add item" in edit mode). It's forbidden to put/take money in/out for a bank
statement which is not open.
opw:647631
When a account.bank.statement.line is created by clicking on "Put Money In"
(Accounting(Menu)>Bank and Cash(Menu)>Cash Registers(Menu)>More(Button)>"Put Money In"),
the account.bank.statement linked to this line must be updated(by passing in the write of
this model) to compute the real closing balance. This fix allow to have the same
behaviour than when a line is manually added (with "Add Item) in an account.bank.statement.
opw:647631
With 3e82c94d we use the timezone in the context to format date
sequences when formatting an ir.sequence.
This commit adds the other missing context when getting a sequence, so
these sequences are also dependant on the timezone.
closes#8351
opw-646487
In bank statement reconciliation, when selecting an other partner(with the pencil),
the possible invoices to reconcile must be suggested.
opw:647210, 647885
It has no sens to map a tax by a tax included in the price because
when a tax is included in the price, the price must be computed
according to this tax.
-account:_fix_tax_included_price
If a fiscal position mapped an included tax on a SO or on a PO line
then the price unit of the product must be recomputed.
-purchase: onchange_product_id test
Test that when an included tax is mapped by a fiscal position, the included tax must be
subtracted to the price of the product.
-sale:product_id_change test
Test that when an included tax is mapped by a fiscal position, the included tax must be
subtracted to the price of the product.
opw:647321
This revision is related to cfbd086b09.
This is the same use case than above, but with a different
currency than the one of the company, for the field
`amount_currency` this time.
Closes#8135
opw-647639
The propositions of reconciliation for a bank statement line must
be taken from account move lines with the same partner_id of this
bank statement line or without partner_id.
opw:647199
When converting an invoice in journal entries,
the invoice lines amounts must be currency rounded
not only when the invoice currency is different
than the company invoice,
but also when they are the same.
Otherwise, a rounding issue can happen
if the `Account` decimal accuracy is greater
than the currency rounding, the journal entries
total and the invoice total could be different.
e.g.
- Set decimal accuracy of Account and product to 4
- Create a supplier invoice, any supplier
- Add a line as follow:
- Product: None
- Quantity: 2057
- Price unit: 11.9150
- Tax: 16% (create a new tax with 0.16 as percentage)
- Validate the invoice
- In the other information tab of the invoice,
click on the journal entry
- Notice that the first line has as credit amount 28430.6150
While the invoice total is 28430.6200
- Now if you try to create a bank statement with one line
of -28430.6200 and as partner the supplier you chose
in the second step of this explanation, and try
to reconciliate it to the invoice created above,
the above won't be marked as paid, while it should.
opw-647639
Fixes#8135
The string belongs to the account module, but was wrongly added to
stock.pot. This commit adds it to account.pot, but also keeps it for the
moment in stock.pot to prevent losing existing translations in
Transifex.
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
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
The CSS on the linei with the "New" button of an bank statement
reconciliation wizard was only applied when there was only a multiple of
two "block" before.
Hence it worked when there was a multiple of 2 cases before, but if not
(for example when account_analytic_plans is installed) on:
- google chrome: the button is on the right (instead of on a line by its
own).
- firefox: idem, but also a difference in float display positioning
caused the parent container to not take floating elements into account
to calculate it's height.
This fix apply the CSS independently if the last block is even or odd.
Before this fix in firefox:
https://cloud.githubusercontent.com/assets/9977887/7315195/70ca5eca-ea6b-11e4-8892-1272f7ee0cb4.png
After this fix in firefox:
https://cloud.githubusercontent.com/assets/9977887/7315194/6e2b05ca-ea6b-11e4-9400-69c9cd587756.pngcloses#6459
opw-633703
Ensure correct sequence of bank statement action views.
As the views are sorted based on the sequence, make sure the tree is selected
before the form view.
Fixes#6413
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
Fiscal year is created when a chart of account is installed on the company.
If no chart of account is installed, setting dates will have no effect in the
accounting configuration wizard.
Fixes#3547
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
contracts_count function field
&
journal_item_count function field
used for the "contracts" and "journal items" buttons
in the partner view are computed by the same
method.
But, this is possible that you have access to
one without having access to the other.
e.g., Project users not being salesman nor accountant
must have access to the contract counts,
but not to the journal items.
Besides, these buttons are added to the partner form
by two separated views, applied to analytic accounting group
& accountant group, respectively.
We therefore avoid to compute the journal items count when
not needed, when not loaded in the partner view.
We therefore prevent the access right issue, and provide
a performance improvment at the same time. Yay.
opw-632454
When generating the accounting entries, to compute the name, the invoice
reference (e.g. origin purchase order name) was first used before the supplier
invoice number. To facilate reconciliation of bank statements, the supplier
invoice number makes more sense.
Fixes#3839, opw 618765
When opening entries are generated, the reconcile_id field is updated in SQL
(probably for performances reasons) but the computed and stored field
reconcile_ref is not recomputed by the ORM.
Force the recomputation of the field by calling ORM method _store_set_values.
Fixes#4267, opw 620369
When printing the general ledger with "With Currency"
checked, two currencies were displayed in the colum
"Currency" when an amount was set, one time the company
currency, one time the move line currency. Only
the move line currency should be displayed.
Besides, the total of currencies amount
for each account should not display the currency symbol
at all, as the total may be composed of multiple currencies.
opw-632086
In the partner ledger wizard, you can check
a boolean to display the amount within the
currency the amount has been invoiced.
This feature was simply no more working
in Odoo 8.0.
opw-630268
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
"Invoiced" stat button on the res.partner form view must not include cancelled and draft invoices.
The button triggered an action which shows a tree view with invoices where:
type in ['out_invoice'] and all states.
Now the button triggers a tree view with invoices where: type in ['out_invoice' , 'out_refund']
and state not in ['draft', 'cancel'].
opw:472318
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.
The domain on the partner field in the bank statement lines
was too restrictive: You should be able to select partners
that aren't either customer or suppliers. For instance, your
employees.
opw-630017
when a customer invoice is created directly,
if a product variant is selected,
it now computes the price from the product variant and
not from the product template.
opw: 629285
When having account installed, but having as only
access right "Contacts creation", it wasn't possible to
display the partner form.
Setting the "groups" on the button itself has as effect
to hide the button, but not to prevent its value computation.
If you did not had the access rights required to compute the
buttons values, it leaded to security issues.
Put the "groups" on the view instead prevent the button to be loaded,
and its value to be computed. It therefore avoids both
a useless computation (computing the value of a hidden button
is not really useful), and prevent any access rights warnings.
Besides, 3 different groups were needed to display the
three buttons:
- account.group_account_invoice
- account.group_account_user
- analytic.group_analytic_accounting
Not having one of these tree groups could lead to security
warnings. We therefore split this view into three sub-views,
with each one a group set (and a button)
opw-628668
Many trivial changes to journal items, such as the
"blocked" flag for litigation (follow-up), do not affect
the balance of the whole entry. These should not cause
the account.move to be (re)validated.
For example it should be possible to change trivial
fields even on journal entries recorded in a closed
fiscal period.
Since all the lines in a partial reconciliation share the same state and the same amount_residual, we need to keep only one 'result' line.
It was the first line found that was kept ; now it's the line whose amount is greater than amount_residual, whiwh most likely is the significant one.
Fixes#5129
Odoo Translation Bot
Martin Trigaux
luc-demeyer
Emanuel Cino
Stéphane Bidoul
Goffin Simon
Christophe Simonis
Nicolas Lempereur
Matthieu Dietrich
Denis Ledoux
Pedro M. Baeza
Florian Hatat
Thomas Rehn
Wolfgang Taferner
Richard deMeester
Nicolas Martinelli
Guewen Baconnier
Leonardo Pistone
Christophe Combelles
Daniel Dico
Xavier Morel
Julien Legros
vrenaville
Commandant Custo
Olivier Dony
xmo-odoo
Joao Alfredo Gama Batista
Arthur Maniet
Mohammad Alhashash
Somesh Khare
rmu-odoo
han-odoo
Rifakathusen Haradwala
nachosalvador
Laurent Mignon
David Monjoie
Laetitia Gangloff
Denis Michiels
