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
The key 'novalidate' is added in the context when an operation not impacting
the validation of a move is made. The validation recreates analytic lines
which decrease the performances.
In case of registrating a payment, the skipped validation are the one from
the reconcile method (reconciliation does not change the validity)
Fixes#3787, opw 618529
When creating a new account.move.line, the computation of the default values should accept both `id` and `(id, name)` format.
The key partner_id may be containing a tuple so browsing should only be done on the first element of the tuple.
Fixes#3386
The store recomputation method failed as the search was made comparing id of account.move.line to the account.journal values. Search was returing no result most of the time (opw 615554)
Fixes#2454
When no result is found on the function field 'invoice' (account.move.line), instead of returning {move_id: (False, '')}, return {move_id: False} (expected for m2o fields)
Fixes#2138, opw 613096
When the context contains 'recompute': False, the recomputation was not even
prepared. Now both create() and write() prepare the recomputation by invoking
method modified(). The flag only controls whether method recompute() is invoked.
In addintion, the former flag 'no_store_function' was converted to the flag
'recompute', so that both create() and write() use the same flag.
Fixes#1456
Avoid revalidating the complete account moves
that contain the lines being reconciled.
The reconciliation does not change the validity
of those moves anyway.
This represents a very important speed up of
reconciliation when moves with several hundred
lines are involved.
If we try to generate twice entries on the same fiscal year, we can get completly unrelated errors ("You can only reconcile journal items with the same partner").
With this, we make sure people will first cancel the entries before regeneraing the entries.