Skip to content
Snippets Groups Projects
Commit 274fc3ea authored by Loan (LSE)'s avatar Loan (LSE)
Browse files

[FIX] account: fix inconsistencies in `_sync_dynamic_line`

To reproduce (V16):
 0. Install Accounting (can also be reproduced with just Invoicing, but
 there is no "journal item" menu that will ease the process to show the
 issue)
 1. (In debug), change the dollar currency rounding to 0.0001
 (instead of 0.01)
 2. Go to Accounting > Customers > Invoices
 3. Create a first invoice with:
  - a partner P1
  - set an invoice date
  - make sure that there is a payment term set (for example "30 days")
  - at least one invoiced line (the product does not matter) with the
  tax 15 % and the price to 12.36
 DO NOT confirm the invoice
 4. Create another invoice with
  - ANOTHER partner P2
  - set an invoice date
  - make sure that there is a payment term set (for example "30 days")
  - at least one invoiced line (the product and the price does not
  matter)
 5. Go back to the Invoices list view and select the 2 new (unposted)
 invoices then Action > Post entries.
 6. Check Force and "Post Journal Entries"
 7. Go to Accounting > Reporting > Journal Items
 8. Group by "Journal Entry" and unfold the 2 last invoices (that should
 be the one validated in 6.)
=> The "Partner" set on the Debit Line is the one of the other invoice
(and vice versa)

Analyse:
 This issue is a mix of different sub-issues. Solving any of this
 sub-issue would solve the issue but as other sub-issues may exists we
 will fix each of them individually.

 Sub-issue 1:
  The account.move.line (=AML) partner is set correctly before the post
  (6.), this is during the "mass posting" process that the issue happens.
  The partner is changed because of this line:
  https://github.com/odoo/odoo/blob/8006e7ce618f98bd26a82cf9b64eaa9b6e9c9d2a/addons/account/models/account_move.py#L2094-L2096
  The value written to AML of id `line_id` include `move_id` which
  overwrite the account.move that was originally set on the AML.
  As the `partner` is computed only in certain circumstances, if the
  `move_id` written differ from the one of the AML, most of the values
  will be updated with the write values, but the `partner_id` will keep
  its value (this is why the swap of partner happen).

  In other words, this issue happen as `line_id.move_id` order is
  different from `key["move_id"]`. So we write on the "wrong" AML.

 Sub-issue 2:
  In theory, this issue should not have happened in the first place.
  The line:
  https://github.com/odoo/odoo/blob/8006e7ce618f98bd26a82cf9b64eaa9b6e9c9d2a/addons/account/models/account_move.py#L2061
  should have prevent the re-edition of the AML (as actually no relevant
  datas are written). But the equality between the dictionaries fail due to some rounding errors.
  Here:
   - needed_after[<key Invoice 1>]["balance"] --> 14.214000000000002
   - needed_before[<key Invoice 1>]["balance"] -> 14.213999999999999
  N.B: if we don't set an "invoice date" on the invoice, a rewrite is
  done before which would prevent our issue to reproduce.

 Sub-issue 3:
  If we try to reproduce the issue without setting a "payment term", the
   issue would not reproduce.
  By setting a "payment term" the `to_delete` computation change at:
  https://github.com/odoo/odoo/blob/8006e7ce618f98bd26a82cf9b64eaa9b6e9c9d2a/addons/account/models/account_move.py#L2067


  This happens as the `existing_before` keys and `needed_after` keys are
   different:
  - existing_before[<key Invoice 1>]["discount_date"] -> False
  - needed_after[<key Invoice 1>]["discount_date"] ----> None
  As the values are different, Odoo all the AML to the `to_delete` which
   then trigger their overwrite.

  In other words, if no "payment terms" were set on the invoices, the
  issue would not happen either

opw-3270471,3292931,3333799

closes odoo/odoo#124517

Signed-off-by: default avatarWilliam André (wan) <wan@odoo.com>
parent b54f4387
No related branches found
No related tags found
No related merge requests found
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment