Both store triggers on reconcile_ref are triggered by the same condition,
but seen on 2 tables different, but they always happen together, so no
need for both.
On regular Odoo, the only problem is the performance: the write operation
is performed twice, but on a system with connector or other parallelization
technology, this provokes lot of concurrency problems.
The account move line created for a tax must have the right account_analytic_id
according CONDITION.
CONDITION(inspired from function compute defined on model "account.invoice.tax")
if the tax is for an "in_invoice" or an "out_invoice" => tax_code = 'tax_code_id'
=> the account_analytic_id of the tax must be set to 'account_analytic_collected_id'
if the tax is for an "out_refund" or an "in_refund" => tax_code = 'ref_tax_code_id'
=> the account_analytic_id of the tax must be set to 'account_analytic_paid_id'
note:forward-port upto saas-6
opw:694821
When processing a partial reconciliation in a foreign currency, a
currency exchange difference might be generated during the
reconciliation process (see OPW for a detailed use case).
This prevents the user to process the reconciliation since he will get
the error: 'You have to provide an account for the write off/exchange
difference entry.'
The fix is to use the company-related foreign echange gain and loss
accounts automatically to book this difference.
opw-687975
when extending these methods with the new api, the context is a frozendict
so we need to copy before mutating.
this patch was made by searching for key addition to context and calls to the
update() method on the 8.0 addons, and checking if a copy was made before in
the method.
Posted moves are not protected from modification if the journal is set
to 'autopost'.
If an account move is posted in a journal with 'Autopost' set, it is
possible to modify the associated move lines without any restriction.
This can for example lead to the creation of unbalanced moves.
The original issue fixed by this extra condition
(https://bugs.launchpad.net/openobject-addons/+bug/615268) does not
occur if the commit is reverted.
This reverts 4e95e4223Closes#12014
opw-683165
Used case:
-Create several customer invoices and validate them
-Register a payment without any partner_id and in a bank statement for an amount
a bit lower than the total of the invoice (the difference is the paypal fees)
-Reconcile the invoices with the payment and create a write-off for the paypal fees
-When you close the bank statement, check the journal items, the paypal fees are
automatically assigned with a partner.
Fix:
-When creating the account move line for the fee, if all the account move lines
linked to the move are for different partners then you cannot determine the partner
of the fee.
opw:674822
- Only invalidate cache for fields and records we modify
- Rewrite query to be more efficient
- Avoid o2m commands to be more efficient; write directly on reverse m2o
This revision is related to 99d8cd6
Avoid to check the journal centralization
mutliple times, for each move lines.
Checking the journal centralization
for each journal for each period just
before the call to `super` is enough.
Before this revision,
if a large number of move lines
was passed in the `ids` parameter
of the `write` method, with all
the same journal / period, this
could lead to huge performances issues,
the `_check_moves` being called
a large number of times for the same
journal and period couple, uselessly.
opw-672797
When computing the balance, debit and/or credit, the opening period must
be filtered out. Otherwise, the invoices which are still opened at the
time of the period closing will be counted twice.
opw-670584
In "Search Journal Items", for the the field 'journal_id', the name
of the current searched journal was written in the context with the key
'journal_id'. Then in the function "view_header_get", the 'journal_id'
was expected to be an id. This is why the key has been replaced in the
view as 'journal_name'.
opw:660591
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
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
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
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
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
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
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
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
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.
In a workflow context (for instance, in the invoice workflow),
context is not passed.
Therefore, relying on the 'recompute' key being the context
in order to not recompute the fields does not work with Workflows.
It leads to huge performance issues,
as fields are recomputed recursively (instead of sequentially)
when several records are implied.
For instance, when reconciling several invoices with one payment
(100 invoices with 1 payment for instance),
records of each invoice are recomputed uselessly in each workflow call
(for each "confirm_paid" method done for each invoice).
With a significant number of invoices (100, for instance),
it even leads to a "Maximum recursion depth reached" errror.
closes#4905
qdp-odoo
Pedro M. Baeza
Goffin Simon
Nicolas Martinelli
Alexandre Fayolle
Stefan Rijnhart
Nicolas Seinlet
Adrien Peiffer (ACSONE)
Denis Ledoux
Danimar Ribeiro
Olivier Dony
Christophe Simonis
Guewen Baconnier
Daniel Dico
Julien Legros
xmo-odoo
Joao Alfredo Gama Batista
Martin Trigaux
Somesh Khare
Nicolas Lempereur
Laetitia Gangloff
Arthur Maniet