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
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 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
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
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
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
The payment method code is not supposed to be changed
from an `account.payment`.
Besides, this field is only used for technical reasons,
as stated:
```
Technical field used to adapt the interface to the payment type selected.
```
There is therefore no reason to not set it as readonly.
Not setting it as reandonly could lead to a `write`
operation on the `account.payment.method` with the value
of the code, even if this is already that one set, and
such an operation could be prevented by the access rights.
opw-668624
In a multi-company environment, a user from company A which is a parent
of the company B has access to taxes from both companies. The
consequence is that the method _set_taxes will automatically add the
taxes from both companies.
If the SUPERUSER creates an invoice, we should make sure to keep only
the taxes related to the company of the invoice. This is for example the
case in the PoS, where the invoice is created with the SUPERUSER.
Fixes#10648
When an account move line is reconciled with debits and credits, both are
subtracted from the original amount. This is not logical, since if the
line is a credit (debit) we should subtract (add) the debits and add
(subtract) the credits.
opw-667137
The write-off currency should be the currency of the first
account.move.line, since it is what is assumed in the interface.
Moreover, the sign of amount_currency should match the constrain
_check_currency_amount.
opw-667137
The Purchase module provides a functionality to add pre-filled invoice
lines to an invoice. The issue is that extensions of the accounting
modules might add fields on an invoice line, and one would like to see
these fields populated as well.
This is the case for account_asset, which adds an asset_category_id on
an invoice line. However, the Purchase module is not aware of the fields
added by account_asset, and therefore it cannot populate them.
This fix adds a method, _auto_fill_extra, which is intended to manage
these extra fields.
opw-667162
In function _compute_expense_totals, the debit and credit of an account
move is computed in the right currency rate according to the date.
Then in function _prepare_analytic_line, the amount of an analytic line
must also be computed in the right currency according to the date.
opw:666538
The company currency should be the company currency of the invoice, not
the company currency of the account journal linked to the payment.
The following use case causes an issue:
- invoice in GBP
- journal of the invoice in AED
- journal of the payment in CHF
In this case, residual_company_signed will be considered to be in CHF
while it was recorded in AED.
opw-666595
Previously we only changed the accounts of type liquidity and that had the prefix/suffix defined on the company settings.
We added to that the other accounts with the following heuristic:
if #digits > len(account.code):
add 0 after account.code,
if #digits < len(account.code):
remove 0 from end of account.code (if possible).
Behaviour for the accounts of type liquidity that start with prefix/suffix defined on the company settings does not change,
except for a bug correction that did not remove 0 when we set a smaller number of digits.
Simplify the API and make it possible to detect fiscal positions based
only on geo information, without having to call `get_fiscal_position()`
which requires a specific partner record.
This commit simply moves the logic related to the global 'world' fiscal
position fallback (no country, no country group) into the low-level
method `_get_fpos_by_region()`, so that callers do not have to do it
themselves.
In multi currencies, the different invoices linked to a journal can
be in different currencies, this is why the amount_total of each invoice
must be summed in the same currency.
opw:666311
The field "amount" in 'account.analytic.line' must be in the currency
of the 'account.move.line' record because the "currency_id" field is over
written in "addons/account/models/account_analytic_line.py" and
this field is related to the currency of the move linked to the
analytic line.
opw:666538
Once accounting is installed, the currency of the amount must be the
currency of the company, while the amount currency contains amount in
the original currency.
opw-665821
The use case is the following: the currency of a customer invoice (e.g.
EUR) is different from the currency of the company (e.g. USD). An
invoice is created in EUR, and a payment is done in EUR on the
receivable account which is in EUR.
Between the invoice date (e.g. 2015-01-01) and the payment date (e.g.
2015-02-01), the rate has changed. The reconciliation between the
invoice and the payment is done afterwards, for example 2015-03-01.
When the write-off related to the exchange difference is created:
- the date should be the max date between payment and invoice if the
corresponding fiscal year is not closed (otherwise, today's date).
- the amount currency on the receivable/payable account should be zero,
since the amount currency on the foreign exchange account is zero.
opw-659289
Denis Ledoux