Odoo Changelog — 2026-03-31

Tuesday, March 31, 2026

13 changes · saas-19.2

Bug Fixes(13)

Resolved issues and error corrections

[FIX] l10n_nl_reports_sbr{,_icp}: Date format and consultant code

Enterprisesaas-19.2l10n_nl_reportsMedium

This update resolves an issue preventing SBR tax reports from submitting correctly. The commit restores the correct date format and limits the consultant name description to ensure compliance with validation requirements. This ensures accurate tax reporting and avoids submission failures.

Original PR description

Description of the issue this commit addresses:

During the tax return flow for the SBR development[^1], we discovered that the date format for the "DateTimeCreation" node had been wrongly readjusted and that the "ProfessionalAssociationForTaxServiceProvidersName" content could be too long due to showing the entire description. Those two issue cause the file to be rejected and make submission impossible.

[^1]: https://www.odoo.com/odoo/967/tasks/6034675

---

Desired behavior after this commit is merged:

This commit reintroduces the old DateTimeCreation format which is the only one that passes the tests done on the xbrl validation service[^2] and replaces the ProfessionalAssociationForTaxServiceProvidersName's value for the abreviation of the order instead of the entire description.

[^2]: https://aansluiten.procesinfrastructuur.nl/site/validaties-digipoort/xbrl-validatie

---

task-none

Forward-Port-Of: odoo/enterprise#112216
Forward-Port-Of: odoo/enterprise#111817

#tax#reporting#SBR

[FIX] l10n_co_edi_pos: DIAN qr crashes receipt

PR #112133

Enterprisesaas-19.2l10n_co_edi_posMedium

This update resolves a critical issue causing receipt generation errors when sending invoices to DIAN (Colombian tax authority). The fix corrects a problem with relative URLs in QR code generation and addresses an outdated code path that was also causing crashes. This ensures accurate receipt creation and compliance with DIAN requirements.

Original PR description

1. When generating the full receipt for a pos order sent to DIAN the receipt generation crashes because the qr code url is a relative path, which makes wkhtmltopdf crash.

2. For invoiced pos orders we were still using old code which would also crash because the `'barcode_src`' key is not returned by `_l10n_co_dian_get_extra_invoice_report_values` anymore

#DIAN#receipts#compliance#Colombia

[FIX] stock_barcode: force lot update if name mismatch

PR #112528

Enterprisesaas-19.2stock_barcodeMedium

This update fixes an issue where scanning a different serial number than the reserved one during batch processing didn't create a new lot. The fix ensures that the correct lot is always used when scanning a batch, preventing incorrect inventory tracking. This improves the reliability of batch operations.

Original PR description

Issue
-----
When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken regardless of setting.

Steps to reproduce
-----
- Enable GS1 nomenclature, lots & batches
- Go to Inventory > Configuration > Operation Types > Delivery Orders
    - Enable Lots/Serial Numbers > Create New
- Create a product
    - Barcode 23456789012344
    - Tracked by SN
    - 1 in stock (SN 1234)
- Create a delivery for the product and add it to a batch
- Open the batch in barcode
- Scan 012345678901234410BATCHSN1
- Confirm the delviery
- Go back to the picking and see the lines' details

> The line used the reserved SN

Cause
-----
The existing line gets matched in `_findLine`

https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1085

because none of the conditions before

https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1402

get matched. This is unexpected but necessary for batches, as it ensures barcode correctly swaps to the correct picking in the batch. If the line was not matched we would be creating a new line in the same picking than the last scanned line, regardless of which picking the reservation is made in.

Because a line is matched, we have to force its' `lot_id` to `false` so that the new one gets created (`lot_name` is used for display but `lot_id` takes precedence).

-----
Ticket:
opw-5216921

Forward-Port-Of: odoo/enterprise#112210
Forward-Port-Of: odoo/enterprise#109671

[FIX] ai: fix file viewer traceback when chatting with ai

PR #112509

Enterprisesaas-19.2ai_documentsaiMedium

This update resolves a previous issue where users interacting with the AI through the file viewer would receive error messages. The fix ensures the correct file ID is passed to the AI, allowing seamless interaction with documents. Additionally, improvements were made to the AI's handling of images to ensure stable performance.

Original PR description

Before this commit, whenever a user tried to interact with the ai regarding a document opened in the file viewer, they would get a traceback with a 404 error.

This was caused by the file id that we passed in the `openAIChat` method of the `AIChatLauncher` service. The id is negative on purpose by the documents team - there is a comment stating that it "prevents a reload from resolving to a real record". Also, the id doesn't reflect the attachment_id, but rather another id dedicated to the file_viewer.

On the AI side, when using the id to search for the attachment to send to the AI, we get an error because the id is negative. This bubbles up to the user.

We fix this by replacing the `this.file.id` with the `this.file.documentData.attachment_id.id` which is the correct value of the id associated with this document's attachment.

Task-6030598

Forward-Port-Of: odoo/enterprise#111167

#AI#Document Viewer#Chat

[FIX] account, purchase: catalog remove button not removing order line

PR #253238

Coresaas-19.2accountpurchaseMedium

This update resolves an issue where removing a product from an order (SO/PO/Invoice) didn't correctly update the order line. The fix ensures the correct section ID is used, preventing incorrect updates. Additionally, a related test tour was failing, which has been addressed by adding a wait for the catalog to fully initialize before asserting prices.

Original PR description

Steps to reproduce: 1. Create a new SO/PO/Invoice and add a product. 2. Add a new section below the product. 3. Open the catalog and click the Remove button for the added product. Issue: - The…

Steps to reproduce:
1. Create a new SO/PO/Invoice and add a product.
2. Add a new section below the product.
3. Open the catalog and click the Remove button for the added product.

Issue:
- The product is not removed from the SO/PO/Invoice.

Cause:
- When removing the product, the 'No section' entry is also removed if it becomes empty.
- As a result, `this.env.searchModel.selectedSection.sectionId` point to the first remaining section in the order.
- Because of this incorrect reference, the wrong `section_id` is passed in the params, and `update_order_line_info` does not update the intended order line.

Fix:
- Use `this.env.selectedSectionId` instead of `searchModel.selectedSection.sectionId` to ensure the correct `section_id` is always passed.

After applying this fix, `test_catalog_vendor_uom` tour was failing because in tour execution the kanban records are mounted before the search panel finishes initializing the selected section. As a result, the initial section state is not yet stabilized when the price is asserted.

To address this:
- Update the tour to explicitly wait until the "No section" entry is marked as selected in the search panel before asserting      the product price, ensuring the catalog is fully initialized.

opw-5960140

Forward-Port-Of: odoo/odoo#250103

[FIX] im_livechat: show looking for help timer for member agents

PR #256633

Coresaas-19.2im_livechatMedium

This update ensures the 'Looking for Help' timer is consistently displayed to live chat agents, regardless of whether they're already involved in the conversation. Previously, the timer was hidden when an agent joined, hindering their ability to track service level agreements. This fix corrects a server-side issue, guaranteeing accurate timer calculations and improving agent efficiency.

Original PR description

**Description of the issue this PR addresses:**
Ensure the `Looking for Help` timer is shown even when the current 
user is already a member of the livechat channel.

**Steps to Reproduce:**
1. Log in as a visitor and as Mitchell Admin (Live Chat operator).
2. From the visitor side, select I have a pricing question.
3. From the admin side, mark the conversation as Looking for Help.
4. The channel appears in the Looking for Help category.
5. Observe that the timer should be visible there (e.g., 1m).

**Current behavior before PR:**
- The timer was hidden when an agent was already a member of the 
conversation, assuming that once an agent joined, the `waiting for help` 
phase was over.

- However, in escalation workflows an analyst may escalate a chat and 
remain a member while the channel returns to the `Looking for Help` 
state for another expert. In this case, the escalating analyst could not 
see the timer needed to track SLA requirements (e.g., creating a 
ticket after 10 minutes).

- Also, the mock server did not recompute
`livechat_looking_for_help_since_dt` when `livechat_status`
changes, leading to incorrect timer values (e.g., showing 2d
instead of < 1m after switching back to Looking for Help).

**Desired behavior after PR is merged:**

- The timer is displayed whenever the channel is in `need_help` 
and `livechat_looking_for_help_since_dt` is set, regardless of 
whether the current user is a member of the channel.
- The mock server now mirrors server-side behavior by updating
`livechat_looking_for_help_since_dt` when livechat_status changes,
prevents missing recomputations and ensuring consistent test
behavior.

task-[6009851](https://www.odoo.com/odoo/project/1519/tasks/6009851)


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#252738

[FIX] account: associate source invoice to credit notes

PR #256710

Coresaas-19.2accountMedium

This update resolves an issue where credit notes created through 'Reverse and create invoice' didn't correctly show the original invoice's source information. The fix ensures that the source document is accurately reflected in the generated invoice PDF, improving reporting and traceability. This ensures consistent financial record keeping.

Original PR description

### Issue before this commit:
When creating a credit note using “Reverse and create invoice”, the generated invoice loses the Source field. While the original invoice correctly displays the source, the new invoice created after reversal does not, leading to missing information in the report.

### Steps to reproduce the issue:
1. Create a sales order for product A
2. Deliver product A
3. Create invoice
4. Create credit note by clicking on "Reverse and create invoice"
5. The new invoice correctly remains linked to the Sales order
6. However, the source document disapear on the PDF

### Cause of the issue:
In the reversal flow, the new invoice is created using copy_data() without explicitly preserving the invoice_origin field. As a result, the newly created invoice does not inherit the source information from the original invoice, even though it is still logically linked.

### Reason to introduce the fix:
To ensure consistency between invoices and preserve important traceability information, the invoice_origin field must be propagated to the new invoice created during the reversal process. This guarantees that the Source is correctly displayed in the PDF.

opw-6034574

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#256284
Forward-Port-Of: odoo/odoo#254290

[FIX] payment_flutterwave: fix `invalid billToPhone` error

PR #256740

Coresaas-19.2payment_flutterwaveMedium

We've been experiencing an increase in failed payments due to an issue with Flutterwave. This update corrects the way phone numbers are sent to Flutterwave, aligning with a recent change in their API requirements. This resolves the 'invalid billToPhone' error and ensures smoother payment processing.

Original PR description

With are recently seeing an increasing number of payments that fail with an `invalid billToPhone` error.

It's unclear if it's a recent change of flutterwave API or of any intermediary payment processor, but the flutterwave v4.0.0-beta API now state to send the phone number "unformatted" - even if there is no such statement for the v3.0.0 API (that we are using), based on testing, sending the phone number "unformatted" do so seems do solve the issue.

So this commit, sanitize the phone number to send it unformatted.

opw-6074825



---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#256478
Forward-Port-Of: odoo/odoo#256315

#payment#flutterwave#error

19.0 perf valo arm

PR #254552

Coresaas-19.2stock_accountMedium

This pull request focuses on optimizing the way Odoo calculates stock valuations, particularly within our inventory management modules. The changes improve the speed and efficiency of these calculations, leading to faster reporting and a smoother user experience. This enhancement addresses a known performance bottleneck and ensures accurate and timely stock valuation data.

Original PR description

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#252635
Forward-Port-Of: odoo/odoo#249790

#stock#valuation#performance

[PERF] stock_account: Prevent memory error when computing average cost

PR #255193

Coresaas-19.2stock_accountMedium

This update fixes a memory issue that could occur when generating the inventory valuation report for companies with a large number of products and stock movements. By processing data in smaller batches, the system now avoids running out of memory, ensuring faster and more reliable report generation.

Original PR description

Related Ticket: https://www.odoo.com/odoo/project/49/tasks/5416006

Issue:
If a database has products that use the average cost method, and those products have millions of stock moves, a memory error can occur when the inventory valuation report is opened.

Explanation:
When the inventory valuation report is opened, the `_run_average_batch` method is invoked on batches of up to 1000 AVCO products at a time. Previously, all matching stock moves for those products were fetched in a single query and kept in cache for the duration of the computation. For large databases, even a single invocation of `_run_average_batch` can exhaust available memory if the products involved have enough stock moves.

Solution:
Moves are now fetched and processed in batches of 50,000 records, with the cache for `stock.move` and `stock.move.line` invalidated between each batch.

For memory:
| # Input data | Before PR | After PR |
|:-------------:|:----------:|:---------:|
| 100 products with 61,024 moves | 280 MB | 274 MB |
| 500 products with 535,250 moves | 983 MB | 301 MB |
| 500 products with 912,405 moves | 1.7 GB | 337 MB |
| 1000 products with 1,447,655 moves | Mem error | 393 MB |

For speed (in m:ss):
| # Input data | Before PR | After PR |
|:-------------:|:----------:|:---------:|
| 100 products with 61,024 moves | 0:15 | 0:16 |
| 500 products with 535,250 moves | 1:12 | 1:17 |
| 500 products with 912,405 moves | 2:02 | 2:10 |
| 1000 products with 1,447,655 moves | N/A | 3:53 |

opw-5416006

Co-authored by Cooper Spinelli (spco)

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#250526

[IMP] l10n_jo_edi_pos: make l10n_jo_edi_pos_{state, return_reason} readonly

PR #256778

Coresaas-19.2l10n_jo_edi_posMedium

This update enhances the process for managing demo transactions in the l10n_jo_edi_pos module. Previously, users were blocked indefinitely with demo orders. Now, users can either delete the demo transaction or sync it to the live system, providing greater control and flexibility.

Original PR description

Before this commit:
- The fields `l10n_jo_edi_pos_{state, return_reason}` were readonly when 
  `l10n_jo_edi_pos_qr` was set. However, we did not take into account the fact
  that `pos.order` cannot be reset once `done/paid/invoiced`; thereby blocking
  the user with a demo transaction forever without any alternative.

After this commit:
- The fields `l10n_jo_edi_pos_{state, return_reason}` are readonly when
  `l10n_jo_edi_pos_qr and l10n_jo_edi_state == 'sent'`. Additionally, an 
  onchange is introduced on `l10n_jo_edi_pos_state` to clear 
  `l10n_jo_edi_pos_qr`. This gives back flexibility to the user to either delete
   the demo mode transaction or sync them to the production endpoint.

task-5958427

Forward-Port-Of: odoo/odoo#250808

#edi#pos#jo

[FIX] pos_self_order: fix qr for pos_self_order

PR #256654

Coresaas-19.2pos_self_orderMedium

This update corrects an issue where QR codes generated for self-ordering pickup orders included incorrect URLs with table information. The fix ensures QR codes are generated correctly for pickup zones, preventing errors in downloaded PDFs and improving the customer ordering experience. This resolves a previous problem impacting order accuracy.

Original PR description

Step to reproduce: - setup Restaurant and do the following config - set "self-ordering" -> "Qr Menu + Ordering" - set "service At" -> "pickup zone" - save and print the qr-code ( option is right…

Step to reproduce:
- setup Restaurant and do the following config
- set "self-ordering" -> "Qr Menu + Ordering"
- set "service At" -> "pickup zone"
- save and print the qr-code ( option is right there below these configs)

Observation:
- in downloaded pdf, we see a wrong url, which includes table_id, which shouldn't be.
- QRs do not have table_id

Cause:
- there is issue in `generate_qr_codes_page` method, which uses table_id even if ordering mode is "pickup zone"

Fix:
- we only use table_id when ordering_mode = 'table'.

**Before:** 
<img width="1002" height="397" alt="image" src="https://github.com/user-attachments/assets/e6dc50e5-6384-45b8-8ee5-817526769dc2" />


**After**
<img width="1021" height="405" alt="image" src="https://github.com/user-attachments/assets/0be9b902-3870-4fc7-a409-e01265b7a1b3" />


opw-5095607


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#254897
Forward-Port-Of: odoo/odoo#247184

[FIX] purchase_{mrp, stock}: fix kit valuation after vendor bill posting

PR #252853

Coresaas-19.2purchase_stockstock_accountMedium

This update corrects a bug where kit valuations were incorrectly calculated after vendor bills were processed. The system was failing to properly account for the individual components within a kit, leading to inaccurate cost reporting. This fix ensures accurate valuation of kits and their components during billing.

Original PR description

**Issue**:
Billing a PO containing kit with several components can lead to incorrect
valuation of its components

**Steps to reproduce**:
- Create a kit product (by creating a BOM with 2 components) with AVCO valuation
- Create a PO for 1 unit at unit price 10
- Confirm PO and validate the receipt
- Go to the BOM of the kit product and check BOM overview
-> The cost of the two components are 5, which is correct
- Go to Accounting > Vendors > Bill
- Create a new bill by indicating the PO in "Auto-Complete" field and validate
- Go back to the BOM of the kit product and check BOM overview
-> The cost of the two components are 10, which is correct

This also occurs with FIFO valuation

**Cause**:
While computing the value of the move:
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L282
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L313-L314
It checks the value of the Bill:
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L357-L358
Which relies directly on the AML price of the kit:
https://github.com/odoo/odoo/blob/a2b3a10255dba290ea462b9193ae11c54d8dd5e0/addons/purchase_stock/models/stock_move.py#L170
This ignores the `cost_share` of each BOM component. As a result,
each component receives the full kit value instead of its proportional
share

This means that the value of the move is 10 instead of 10/2=5, which makes the valuation computation wrong:
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/product.py#L393

**Aditionnal note**
The computation of the quantity is also incorrect:
https://github.com/odoo/odoo/blob/a2b3a10255dba290ea462b9193ae11c54d8dd5e0/addons/purchase_stock/models/stock_move.py#L169
since it assumes the quantity of component of the kit is the same than the quantity of the kit itself,
which is not true in the general case.

opw-5924940

Forward-Port-Of: odoo/odoo#252246
Forward-Port-Of: odoo/odoo#249264

Description of the issue this commit addresses: During the tax return flow for the SBR development[^1], we discovered that the date format for the "DateTimeCreation" node had been wrongly readjusted and that the "ProfessionalAssociationForTaxServiceProvidersName" content could be too long due to showing the entire description. Those two issue cause the file to be rejected and make submission impossible. [^1]: https://www.odoo.com/odoo/967/tasks/6034675 --- Desired behavior after this commit is merged: This commit reintroduces the old DateTimeCreation format which is the only one that passes the tests done on the xbrl validation service[^2] and replaces the ProfessionalAssociationForTaxServiceProvidersName's value for the abreviation of the order instead of the entire description. [^2]: https://aansluiten.procesinfrastructuur.nl/site/validaties-digipoort/xbrl-validatie --- task-none Forward-Port-Of: odoo/enterprise#112216 Forward-Port-Of: odoo/enterprise#111817

1. When generating the full receipt for a pos order sent to DIAN the receipt generation crashes because the qr code url is a relative path, which makes wkhtmltopdf crash. 2. For invoiced pos orders we were still using old code which would also crash because the `'barcode_src`' key is not returned by `_l10n_co_dian_get_extra_invoice_report_values` anymore

Issue ----- When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken regardless of setting. Steps to reproduce ----- - Enable GS1 nomenclature, lots & batches - Go to Inventory > Configuration > Operation Types > Delivery Orders - Enable Lots/Serial Numbers > Create New - Create a product - Barcode 23456789012344 - Tracked by SN - 1 in stock (SN 1234) - Create a delivery for the product and add it to a batch - Open the batch in barcode - Scan 012345678901234410BATCHSN1 - Confirm the delviery - Go back to the picking and see the lines' details > The line used the reserved SN Cause ----- The existing line gets matched in `_findLine` https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1085 because none of the conditions before https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1402 get matched. This is unexpected but necessary for batches, as it ensures barcode correctly swaps to the correct picking in the batch. If the line was not matched we would be creating a new line in the same picking than the last scanned line, regardless of which picking the reservation is made in. Because a line is matched, we have to force its' `lot_id` to `false` so that the new one gets created (`lot_name` is used for display but `lot_id` takes precedence). ----- Ticket: opw-5216921 Forward-Port-Of: odoo/enterprise#112210 Forward-Port-Of: odoo/enterprise#109671

Before this commit, whenever a user tried to interact with the ai regarding a document opened in the file viewer, they would get a traceback with a 404 error. This was caused by the file id that we passed in the `openAIChat` method of the `AIChatLauncher` service. The id is negative on purpose by the documents team - there is a comment stating that it "prevents a reload from resolving to a real record". Also, the id doesn't reflect the attachment_id, but rather another id dedicated to the file_viewer. On the AI side, when using the id to search for the attachment to send to the AI, we get an error because the id is negative. This bubbles up to the user. We fix this by replacing the `this.file.id` with the `this.file.documentData.attachment_id.id` which is the correct value of the id associated with this document's attachment. Task-6030598 Forward-Port-Of: odoo/enterprise#111167

Steps to reproduce: 1. Create a new SO/PO/Invoice and add a product. 2. Add a new section below the product. 3. Open the catalog and click the Remove button for the added product. Issue: - The product is not removed from the SO/PO/Invoice. Cause: - When removing the product, the 'No section' entry is also removed if it becomes empty. - As a result, `this.env.searchModel.selectedSection.sectionId` point to the first remaining section in the order. - Because of this incorrect reference, the wrong `section_id` is passed in the params, and `update_order_line_info` does not update the intended order line. Fix: - Use `this.env.selectedSectionId` instead of `searchModel.selectedSection.sectionId` to ensure the correct `section_id` is always passed. After applying this fix, `test_catalog_vendor_uom` tour was failing because in tour execution the kanban records are mounted before the search panel finishes initializing the selected section. As a result, the initial section state is not yet stabilized when the price is asserted. To address this: - Update the tour to explicitly wait until the "No section" entry is marked as selected in the search panel before asserting the product price, ensuring the catalog is fully initialized. opw-5960140 Forward-Port-Of: odoo/odoo#250103

**Description of the issue this PR addresses:** Ensure the `Looking for Help` timer is shown even when the current user is already a member of the livechat channel. **Steps to Reproduce:** 1. Log in as a visitor and as Mitchell Admin (Live Chat operator). 2. From the visitor side, select I have a pricing question. 3. From the admin side, mark the conversation as Looking for Help. 4. The channel appears in the Looking for Help category. 5. Observe that the timer should be visible there (e.g., 1m). **Current behavior before PR:** - The timer was hidden when an agent was already a member of the conversation, assuming that once an agent joined, the `waiting for help` phase was over. - However, in escalation workflows an analyst may escalate a chat and remain a member while the channel returns to the `Looking for Help` state for another expert. In this case, the escalating analyst could not see the timer needed to track SLA requirements (e.g., creating a ticket after 10 minutes). - Also, the mock server did not recompute `livechat_looking_for_help_since_dt` when `livechat_status` changes, leading to incorrect timer values (e.g., showing 2d instead of < 1m after switching back to Looking for Help). **Desired behavior after PR is merged:** - The timer is displayed whenever the channel is in `need_help` and `livechat_looking_for_help_since_dt` is set, regardless of whether the current user is a member of the channel. - The mock server now mirrors server-side behavior by updating `livechat_looking_for_help_since_dt` when livechat_status changes, prevents missing recomputations and ensuring consistent test behavior. task-[6009851](https://www.odoo.com/odoo/project/1519/tasks/6009851) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252738

### Issue before this commit: When creating a credit note using “Reverse and create invoice”, the generated invoice loses the Source field. While the original invoice correctly displays the source, the new invoice created after reversal does not, leading to missing information in the report. ### Steps to reproduce the issue: 1. Create a sales order for product A 2. Deliver product A 3. Create invoice 4. Create credit note by clicking on "Reverse and create invoice" 5. The new invoice correctly remains linked to the Sales order 6. However, the source document disapear on the PDF ### Cause of the issue: In the reversal flow, the new invoice is created using copy_data() without explicitly preserving the invoice_origin field. As a result, the newly created invoice does not inherit the source information from the original invoice, even though it is still logically linked. ### Reason to introduce the fix: To ensure consistency between invoices and preserve important traceability information, the invoice_origin field must be propagated to the new invoice created during the reversal process. This guarantees that the Source is correctly displayed in the PDF. opw-6034574 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256284 Forward-Port-Of: odoo/odoo#254290

With are recently seeing an increasing number of payments that fail with an `invalid billToPhone` error. It's unclear if it's a recent change of flutterwave API or of any intermediary payment processor, but the flutterwave v4.0.0-beta API now state to send the phone number "unformatted" - even if there is no such statement for the v3.0.0 API (that we are using), based on testing, sending the phone number "unformatted" do so seems do solve the issue. So this commit, sanitize the phone number to send it unformatted. opw-6074825 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256478 Forward-Port-Of: odoo/odoo#256315

Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252635 Forward-Port-Of: odoo/odoo#249790

Related Ticket: https://www.odoo.com/odoo/project/49/tasks/5416006 Issue: If a database has products that use the average cost method, and those products have millions of stock moves, a memory error can occur when the inventory valuation report is opened. Explanation: When the inventory valuation report is opened, the `_run_average_batch` method is invoked on batches of up to 1000 AVCO products at a time. Previously, all matching stock moves for those products were fetched in a single query and kept in cache for the duration of the computation. For large databases, even a single invocation of `_run_average_batch` can exhaust available memory if the products involved have enough stock moves. Solution: Moves are now fetched and processed in batches of 50,000 records, with the cache for `stock.move` and `stock.move.line` invalidated between each batch. For memory: | # Input data | Before PR | After PR | |:-------------:|:----------:|:---------:| | 100 products with 61,024 moves | 280 MB | 274 MB | | 500 products with 535,250 moves | 983 MB | 301 MB | | 500 products with 912,405 moves | 1.7 GB | 337 MB | | 1000 products with 1,447,655 moves | Mem error | 393 MB | For speed (in m:ss): | # Input data | Before PR | After PR | |:-------------:|:----------:|:---------:| | 100 products with 61,024 moves | 0:15 | 0:16 | | 500 products with 535,250 moves | 1:12 | 1:17 | | 500 products with 912,405 moves | 2:02 | 2:10 | | 1000 products with 1,447,655 moves | N/A | 3:53 | opw-5416006 Co-authored by Cooper Spinelli (spco) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250526

Before this commit: - The fields `l10n_jo_edi_pos_{state, return_reason}` were readonly when `l10n_jo_edi_pos_qr` was set. However, we did not take into account the fact that `pos.order` cannot be reset once `done/paid/invoiced`; thereby blocking the user with a demo transaction forever without any alternative. After this commit: - The fields `l10n_jo_edi_pos_{state, return_reason}` are readonly when `l10n_jo_edi_pos_qr and l10n_jo_edi_state == 'sent'`. Additionally, an onchange is introduced on `l10n_jo_edi_pos_state` to clear `l10n_jo_edi_pos_qr`. This gives back flexibility to the user to either delete the demo mode transaction or sync them to the production endpoint. task-5958427 Forward-Port-Of: odoo/odoo#250808

Step to reproduce: - setup Restaurant and do the following config - set "self-ordering" -> "Qr Menu + Ordering" - set "service At" -> "pickup zone" - save and print the qr-code ( option is right there below these configs) Observation: - in downloaded pdf, we see a wrong url, which includes table_id, which shouldn't be. - QRs do not have table_id Cause: - there is issue in `generate_qr_codes_page` method, which uses table_id even if ordering mode is "pickup zone" Fix: - we only use table_id when ordering_mode = 'table'. **Before:** <img width="1002" height="397" alt="image" src="https://github.com/user-attachments/assets/e6dc50e5-6384-45b8-8ee5-817526769dc2" /> **After** <img width="1021" height="405" alt="image" src="https://github.com/user-attachments/assets/0be9b902-3870-4fc7-a409-e01265b7a1b3" /> opw-5095607 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254897 Forward-Port-Of: odoo/odoo#247184

**Issue**: Billing a PO containing kit with several components can lead to incorrect valuation of its components **Steps to reproduce**: - Create a kit product (by creating a BOM with 2 components) with AVCO valuation - Create a PO for 1 unit at unit price 10 - Confirm PO and validate the receipt - Go to the BOM of the kit product and check BOM overview -> The cost of the two components are 5, which is correct - Go to Accounting > Vendors > Bill - Create a new bill by indicating the PO in "Auto-Complete" field and validate - Go back to the BOM of the kit product and check BOM overview -> The cost of the two components are 10, which is correct This also occurs with FIFO valuation **Cause**: While computing the value of the move: https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L282 https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L313-L314 It checks the value of the Bill: https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L357-L358 Which relies directly on the AML price of the kit: https://github.com/odoo/odoo/blob/a2b3a10255dba290ea462b9193ae11c54d8dd5e0/addons/purchase_stock/models/stock_move.py#L170 This ignores the `cost_share` of each BOM component. As a result, each component receives the full kit value instead of its proportional share This means that the value of the move is 10 instead of 10/2=5, which makes the valuation computation wrong: https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/product.py#L393 **Aditionnal note** The computation of the quantity is also incorrect: https://github.com/odoo/odoo/blob/a2b3a10255dba290ea462b9193ae11c54d8dd5e0/addons/purchase_stock/models/stock_move.py#L169 since it assumes the quantity of component of the kit is the same than the quantity of the kit itself, which is not true in the general case. opw-5924940 Forward-Port-Of: odoo/odoo#252246 Forward-Port-Of: odoo/odoo#249264