Odoo Changelog — 2024-05-06

Monday, May 6, 2024

4 changes

Bug Fixes(4)

Resolved issues and error corrections

[FW][FIX] stock_account,purchase_stock: compensate return of fifo product

Core17.0stock_accountpurchase_stockHigh impact

This fix resolves an accounting error that occurs when returning products purchased at different prices using FIFO inventory valuation. Previously, returned items could create unreconciled accounting entries with significant value discrepancies. The fix ensures proper compensation of stock accounts when product return values differ from original receipt values, maintaining accurate financial records.

Original PR description

The value of the returned product may be different from the one initially received. In such case, the stock accounting may be broken. To reproduce the issue: (Need account_accountant) 1. Create an…

The value of the returned product may be different from the one
initially received. In such case, the stock accounting may be broken.

To reproduce the issue:
(Need account_accountant)
1. Create an auto-FIFO product category
2. Create a storable product
3. Confirm a PO with 1 @ 10
4. Receive it
5. Confirm a PO with 4 @ 25
6. Receive 1 with backorder
7. Return it
8. On the backorder, receive 4
9. Bill

Error: Looking at the AML of the stock-in account, some lines are
not reconciled and there is a $15 difference between the totald debit
and the total credit.

Step 7, when returning the product, we actually return the one at
$10. Step 8, we then receive 4 products at $25 (hence the difference
of $15). So, back to step 7, when returning the product, we should
also compensate the stock-in account (with the expense one) in case
of a difference.

Let's look at another case: after step 7, the user "returns the
return". In such case, the value of the new receipt is based on the
returned one (see [1]), i.e.: the value of the newly received
product will be $10. In such case, we also need to (1) compensate
the stock-in account and (2) prevent the pdiff process to generate a
pdiff of $15 (otherwise, we would add a value to the received
product, which would go against the logic of [1]).

This commit does not address the behaviour difference between the
two above use cases (-> depending on how the user receives again the
returned product, its value is not the same). This would probably
need a deeper analysis a change, on master.

Note: a third use case does not work either: (step 1-4), PO 1 @ 25,
receive, bill, return, refund.

[1]
https://github.com/odoo/odoo/blob/07464844c69ac3b667adfede0e4e330831819802/addons/purchase_stock/models/stock_move.py#L32-L40
Initially added by https://github.com/odoo/odoo/commit/200aac56771fd1ef759f73b277a6808d96ee5f31

OWP-3698324

Forward-Port-Of: odoo/odoo#162368

#inventory#accounting#FIFO#product returns#financial accuracy

[FIX] account: don't discard attachments when parsing EDI data

PR #164237

Core17.0accountHigh impact

A recent change to how invoice attachments are processed was causing previously uploaded files to be removed when new files were added to a draft invoice. This created access errors for other users trying to view the original files. This fix ensures that new attachments are added without removing existing ones, preserving all uploaded documents and their accessibility.

Original PR description

PR #140196 modified the extension mechanism when processing files accompanying an invoice, in order to focus on a single relevant file per invoice.

Unfortunately this change can break the upload of subsequent files on a new invoice, causing access errors.

Typical scenario:
 - use the Upload Bill feature to create a new vendor bill from a PDF file -> a new draft bill is created, with no lines initially, and with the invoice PDF attached to the new bill.
 - before adding any lines, and before any automatic extraction process is able to parse the PDF and add lines, use "Log a note" on the draft bill to attach an image
 - result: the second file (the image) is processed by `_message_post_after_hook` and ends up being added as an attachment on the draft bill. However the first file (the invoice PDF) is now detached from the invoice, and the attachment counter is back to 1. If another non-admin accountant user tries to open the invoice PDF it will fail with an access error, because the file is detached and can only be accessed by the original uploader (or an admin).

Fix: instead of replacing all attachments on the invoice, `_message_post_after_hook` should add the new one without discarding the existing ones.

[FW][FIX] google_calendar: recurrent events vanished

PR #164408

Core17.0google_calendarHigh impact

This fix resolves an issue where recurring events in Google Calendar would disappear when updating them in "This and future events" mode. The problem occurred because attendees were being removed during updates, causing events to vanish from the calendar. The fix preserves the event organizer as an attendee when syncing updates from Google, ensuring recurring events remain visible and properly maintained.

Original PR description

Before this fix, when updating recurrence events in "This and future events" mode, some events vanished. This happened because we were removing all the attendees from the occurrences, and then no event was being shown in the calendar. Additionally, when creating recurrences from Google with the "UNTIL" option, one extra event was being added at the end because the rrule on their side finished on the next day after the end at 23:59:59.

After this fix, we no longer delete all attendees when receiving updates from Google. Instead, we update the current attendees for not recreating all of them every time. Thus, when updating recurrent events, they no longer vanished anymore. Creating recurrent events in Google with the "UNTIL" option also no longer adds an extra day at the end because we are subtracting the extra day.

Task-id: 3731542

Forward-Port-Of: odoo/odoo#156077

#calendar#sync#recurring-events

[FW][FIX] account: select generated pdf streams from invoices without attachments

PR #164558

Core17.0baseaccountHigh impact

This fix resolves a critical issue where generating reports for multiple invoices would fail when some invoices had previously saved reports and others didn't, with the "Reload from attachment" option enabled. The problem was caused by incorrect indexing when combining newly generated reports with cached ones. This fix ensures reports are properly generated and combined for all selected invoices regardless of their attachment status.

Original PR description

Issue
-----

Report creation for multiple invoices fails (e.g. with <AttributeError: "NoneType" object has no attribute "getvalue">)
when some, but not all, of the invoices across the selection have a previously generated report
as an attachment, and the 'Reload from attachment' option is enabled for the report action.

Steps
-----

 - Enable 'Reload from attachment' from Settings -> Techical -> Actions -> Reports -> invoices.
 - Create 3 invoices without any previous reports as attachments.
 - Select the middle invoice and generate a report (Print -> Invoices). An attachment will be created
   for the invoice.
 - Select the 3 invoices then generate a report (Print -> Invoices).

Cause
-----

When "Reload from attachment" is enabled, the algorithm for creating aggregate reports for a number
of invoices selects only those that don't have an attachment to generate a pdf for. These are copied
into a separate list "res_ids_wo_stream". When the pdfs streams are generated, they're put back into
the return value "collected_streams. However, this was done from the original ids list "res_ids" rather
than the selected one, which resulted in an indexing issue.

opw-3827700
Closes #157975

Forward-Port-Of: odoo/odoo#164420
Forward-Port-Of: odoo/odoo#160670

The value of the returned product may be different from the one initially received. In such case, the stock accounting may be broken. To reproduce the issue: (Need account_accountant) 1. Create an auto-FIFO product category 2. Create a storable product 3. Confirm a PO with 1 @ 10 4. Receive it 5. Confirm a PO with 4 @ 25 6. Receive 1 with backorder 7. Return it 8. On the backorder, receive 4 9. Bill Error: Looking at the AML of the stock-in account, some lines are not reconciled and there is a $15 difference between the totald debit and the total credit. Step 7, when returning the product, we actually return the one at $10. Step 8, we then receive 4 products at $25 (hence the difference of $15). So, back to step 7, when returning the product, we should also compensate the stock-in account (with the expense one) in case of a difference. Let's look at another case: after step 7, the user "returns the return". In such case, the value of the new receipt is based on the returned one (see [1]), i.e.: the value of the newly received product will be $10. In such case, we also need to (1) compensate the stock-in account and (2) prevent the pdiff process to generate a pdiff of $15 (otherwise, we would add a value to the received product, which would go against the logic of [1]). This commit does not address the behaviour difference between the two above use cases (-> depending on how the user receives again the returned product, its value is not the same). This would probably need a deeper analysis a change, on master. Note: a third use case does not work either: (step 1-4), PO 1 @ 25, receive, bill, return, refund. [1] https://github.com/odoo/odoo/blob/07464844c69ac3b667adfede0e4e330831819802/addons/purchase_stock/models/stock_move.py#L32-L40 Initially added by https://github.com/odoo/odoo/commit/200aac56771fd1ef759f73b277a6808d96ee5f31 OWP-3698324 Forward-Port-Of: odoo/odoo#162368

PR #140196 modified the extension mechanism when processing files accompanying an invoice, in order to focus on a single relevant file per invoice. Unfortunately this change can break the upload of subsequent files on a new invoice, causing access errors. Typical scenario: - use the Upload Bill feature to create a new vendor bill from a PDF file -> a new draft bill is created, with no lines initially, and with the invoice PDF attached to the new bill. - before adding any lines, and before any automatic extraction process is able to parse the PDF and add lines, use "Log a note" on the draft bill to attach an image - result: the second file (the image) is processed by `_message_post_after_hook` and ends up being added as an attachment on the draft bill. However the first file (the invoice PDF) is now detached from the invoice, and the attachment counter is back to 1. If another non-admin accountant user tries to open the invoice PDF it will fail with an access error, because the file is detached and can only be accessed by the original uploader (or an admin). Fix: instead of replacing all attachments on the invoice, `_message_post_after_hook` should add the new one without discarding the existing ones.

Before this fix, when updating recurrence events in "This and future events" mode, some events vanished. This happened because we were removing all the attendees from the occurrences, and then no event was being shown in the calendar. Additionally, when creating recurrences from Google with the "UNTIL" option, one extra event was being added at the end because the rrule on their side finished on the next day after the end at 23:59:59. After this fix, we no longer delete all attendees when receiving updates from Google. Instead, we update the current attendees for not recreating all of them every time. Thus, when updating recurrent events, they no longer vanished anymore. Creating recurrent events in Google with the "UNTIL" option also no longer adds an extra day at the end because we are subtracting the extra day. Task-id: 3731542 Forward-Port-Of: odoo/odoo#156077

Issue ----- Report creation for multiple invoices fails (e.g. with <AttributeError: "NoneType" object has no attribute "getvalue">) when some, but not all, of the invoices across the selection have a previously generated report as an attachment, and the 'Reload from attachment' option is enabled for the report action. Steps ----- - Enable 'Reload from attachment' from Settings -> Techical -> Actions -> Reports -> invoices. - Create 3 invoices without any previous reports as attachments. - Select the middle invoice and generate a report (Print -> Invoices). An attachment will be created for the invoice. - Select the 3 invoices then generate a report (Print -> Invoices). Cause ----- When "Reload from attachment" is enabled, the algorithm for creating aggregate reports for a number of invoices selects only those that don't have an attachment to generate a pdf for. These are copied into a separate list "res_ids_wo_stream". When the pdfs streams are generated, they're put back into the return value "collected_streams. However, this was done from the original ids list "res_ids" rather than the selected one, which resulted in an indexing issue. opw-3827700 Closes #157975 Forward-Port-Of: odoo/odoo#164420 Forward-Port-Of: odoo/odoo#160670