When applying the accounting configuration wizard,
the `currency_id` was being re-written on the company,
even if there was no change (if the currency remained the same),
because of the related.
This leaded as well to the re-write of the company currency
on all journal items, because the `company_currency_id` on
`account.move.line` is a related to `company_id.currency_id`as well,
and they were being recomputed due to the above re-write.
Meaning, when you had a bunch of journal items, applying the
accounting configuration wizard could have take a while.
opw-672400
In communtiy, the order of the accounts shown in the reports
didn't follow the order written in the legend(How account type affects your reports?)
Adviser > Chart of Account > create
opw:669270
An issue occurs in the following use case:
- Create an invoice, validate.
- Cancel it, reset to draft.
- Change the invoice date
- Validate the invoice
The date of the account move is still the first date entered. This is
because the accounting date has not been reset on the invoice, and
therefore it is not updated.
opw-671672
[FIX] account: fixed behavior in order to create the exchange rate difference entry at the full reconciliation only.
This is needed in order to support the use case where an invoice in foreign currency is paid on a bank account in company currency,
with the user encoding manually the difference due to the currency fluctuation (writeoff in the bank statement reconciliation interface): before
this patch, Odoo was doing automatically the same, what results in a duplicated currency difference booking). ticket ID: 670876.
A test has also been added in account/tests/test_reconcilication.py (test_statement_euro_invoice_usd_transaction_euro_full) to ensure that use case
is now fixed.
[FIX] account_full_reconcile: a reconciliation is full as soon as either total_debit = total_credit OR if total_amount_currency is 0
[FIX] account: when registering a payment with a writeoff, always create the writeoff line exactly as entered by the user. Before, it was modified
by the exchange rate entry, for some reason...
[FIX] account: on invoices, show the payment widget and outstanding payments in the invoice's currency always
[FIX] account: when assigning a payment in company currency on an invoice in foreign currency, save the amount_currency in order to create the correct
exchange rate.
[FIX] account: show the currency difference entry on the invoice payments widget
[FIX] account: fixed the reconciliation methods in order to work with exchange rate entries that have debit = credit = 0
[FIX] account: fixed reconciled field computation. A line is reconciled only if its amount_residual AND amount_residual_currency are 0
[IMP] display the move name of payments on the invoice payments widget
The access/follow/actions buttons on the notification email template
are sent only to employee. For this particular business model when
want all the users to receive them, as the portal users.
when using a journal with 'Group Invoice Lines'
and issuing an invoice with foreign currency with more than 1 line
(of the same product, or no product),
the amount currency in the journal item
associated to the merged invoice lines was wrong.
It took into account the `amount_currency` of the first line only,
ignoring the `amount_currency` of the remaining merged lines.
opw-670972
Closes#10375
When a bank account is set within another currency
than the company currency
(the currency of the journal is set and is different
than the company currency),
the balance displayed was the amount within the company
currency, instead of the amount within the bank account
currency (despite the fact the currency displayed
was the one of the journal).
opw-670815
Convert the domain to display only the sale / purchase
taxes in the taxes list to a default filter doing the same thing,
but which give the possibility to remove the filter
and see taxes with the scope `None`.
opw-670737
When an analytic account is specified in the reconciliation, the
analytic lines are not created. This is because the account move is
posted before the account move lines are actually created.
Fixes#10951
opw-670110
The account number field on a journal is a related field to the
number of the bank account associated to the journal.
As the number of a bank account is a required field,
any attempt to empty it from the journal fails.
Besides, unlinking the bank account from the journal when emptying
the account number on the journal form doesn't seem to be
the appropriate behavior. Imagine you give an account number
to the journal, then empty it, then re-fill it, you probably
do not want the journal entries to be associated to a new bank account,
you probably wanted the same bank account, but renamed, while
it would be the case if we simply unlink it.
If you would like to delete the bank account, you have
to do it from the bank accounts list itself.
opw-670472
Properties depends on with which companies the records
are browsed.
When retrieving the fiscal position as sudo,
the company must therefore be enforced within the context,
to make sure to get the properties from the right
company.
This method can totally be accessed as sudo,
within the crons for instance.
Before this revision, the recurring invoices cron
could retrieve properties from the wrong company,
and therefore retrieve the fiscal position of another
company.
Closes#11039
If there is no currency set on the journal,
the fallback currency must be the currency
of the journal company, not the currency
of the user company.
This would mean that when you change of company,
with another currency set,
the bank statement change of currency, this is non-sense.
opw-670187
When creating account move lines from an account move, the partner
set on the account move lines has to be the same than the one on the
account move.
opw:668322
The methods calling `reverse_moves` expects a list
as returned result.
For instance, in `account_move.py`, `account.partial.reconcile`,
method unlink:
```
reversed_moves = exchange_rate_entries.reverse_moves()
for rev_move in self.env['account.move'].browse(reversed_moves):
```
If there was no reversed moves, the method returned a boolean,
and a list otherwise. It should always return a list, empty
in the above first case.
opw-669790
When a tax with an amount of 0 percent was linked to an invoice line,
this tax didn't appear in the tax details in the bottom of the invoice
report.
opw669162
In Odoo 9.0, the field `company_id` has been moved
from the `res.currency` model to the `res.currency.rate`
model.
The different reports applying the currency rates on the amount
at date have not been updated according to this change. This
includes the sales, purchases and invoices analysis report.
Basically, before 9.0, there was one `res.currency`
per existing currency per company. A simple `JOIN`
on the `res_currency` table was therefore enough
to apply the currency rate.
From 9.0, the currency records are shared between
companies. It's the rates (`res.currency.rate`) that can be
set a on specific company. The simple `JOIN` on
`res_currency` is therefore no longer enough: the company condition
must be added. Only rates from the specific company
(e.g the company of the invoice) must be considered, or rates
without companies.
We take the opportunity to factor out the method, so, if a correction
must be done, it must be done in one place only.
opw-669129
The checkbox `Assets management & Revenue recognition`
actually installs only the assets management. The revenue
recognition is not installed when checking this box.
Actually, the revenue recognition is not even
available within the community edition. This box
couldn't therefore possibly install this module.
opw-669093
Specifically, when one API implementation calls the other one, it has to call
the method *from the same class*. Otherwise, overriding the method may result
in an infinite recursion. Consider:
class A(Model):
_name = 'stuff'
@api.v8
def foo(self):
return 42
@api.v7
def foo(self, cr, uid, context=None):
return self.browse(cr, uid, [], context).foo()
class B(Model):
_inherit = 'stuff'
def foo(self, cr, uid, context=None):
return super(B, self).foo(cr, uid, context=context) + 1
and now call: `env['stuff'].foo()`. This invokes `B.foo` (new-API), which
calls `B.foo` (old-API), which calls `A.foo` (old-API), which calls `B.foo`
(new-API) instead of `A.foo`!
This issue would not be present if old-API `A.foo` was defined as:
@api.v7
def foo(self, cr, uid, context=None):
return A.foo(self.browse(cr, uid, [], context))
Odoo Translation Bot