Daily updates from Odoo
Monday, March 30, 2026
199 changes
9 changes
Resolved issues and error corrections
This update fixes an issue where quality control failures weren't correctly splitting stock moves, leading to inaccurate demand calculations. The fix ensures that failed quantities are properly reflected in new stock moves, maintaining accurate inventory tracking. This improves the reliability of quality control processes and prevents overestimation of available stock.
Original PR description
**Steps to reproduce:** * Install the `quality_control` module. * Create a storable product. * Configure a Quality Control Point: * Set Control per : Quantity. * Set Operation Type to Receipts. * Set…
**Steps to reproduce:** * Install the `quality_control` module. * Create a storable product. * Configure a Quality Control Point: * Set Control per : Quantity. * Set Operation Type to Receipts. * Set Product to the created product. * Create a Receipt for the product with a demand of 5 units. * Confirm the receipt and mark it as To Do. * Click on the Quality Check button. * Click on Fail and set the failed quantity to 3. * Click on Confirm. **Observed behavior:** * A new stock move is created for the failed quantity. * The original move is split incorrectly: * First move: 2 `product_uom_qty` and 2 `quantity`. * Second move: 2 `product_uom_qty` and 3 `quantity`. * The failed move has a demand of **2** instead of **3**. **Cause:** * Clicking on *Quality Check* triggers `check_quality`, which opens the wizard `action_open_quality_check_wizard`: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/stock_picking.py#L79-L82 * Clicking on *Fail* triggers `do_fail`, opening the confirmation wizard: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/wizard/quality_check_wizard.py#L85-L88 * Clicking on *Confirm* triggers `confirm_fail`, which calls `_move_line_to_failure_location`: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/wizard/quality_check_wizard.py#L97 * In `_move_line_to_failure_location`, a new stock move is created for the failed quantity: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/quality.py#L480 * The demand quantity is computed using the minimum of the failed quantity and the move line quantity. * This leads to an incorrect demand of *2* instead of *3*. * However, the move line quantity was already reduced by the failed quantity: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/quality.py#L472 **Fix:** * Ensure that partial failures properly split stock moves with correct `product_uom_qty` and `quantity` values. --- opw-5492095 Forward-Port-Of: odoo/enterprise#112298 Forward-Port-Of: odoo/enterprise#107493
This update allows users to access and view canceled signature requests within the Odoo portal. Previously, canceled requests were hidden, preventing users from seeing important communication history and document details. The change simplifies the user experience by aligning the display for canceled requests with completed requests.
Original PR description
Previously, users were redirected to the home page if they tried to access a signature request in the 'canceled' state. This prevented them from viewing the communication history or the document metadata. This commit: - Removes the 'canceled' state restriction in the portal controller. - Updates the portal template to show "View Document" instead of "Sign" for canceled requests, similar to the completed state. Task: 6034621 Forward-Port-Of: odoo/enterprise#111534 Forward-Port-Of: odoo/enterprise#110974
A test used in the Odoo Enterprise payroll module failed due to an incorrect date calculation. This fix adjusted the test environment to ensure accurate results, preventing future disruptions to payroll processing. The change addresses a discrepancy in how date ranges were being evaluated during testing.
Original PR description
[FIX] l10n_ch_hr_payroll_elm_transmission: fix avs test for faketime build
Bug reproduction:
1 - v.17->run test_generic_avs_deductions test with faketime 2027-01-01 12:00 UTC->test fails
Bug cause:
1 - In the test, compute_sheet()->_get_payslip_lines->_compute_rule->_get_avs_rates is called
2 - There is a line like that if line.date_from <= target and (not line.date_to or target <= line.date_to)
3 - I looked to avs_line_ids = fields.One2many(default=_get_default_avs_line_ids)
4 - In _get_default_avs_line_ids -> 'date_from': fields.Date.today().replace(month=1, day=1) date_from is calculated like that -> when the year is 2027, the date_from is 2027-01-01 and it is bigger than the target in the test.
Bug solution:
1 - I used @freeze_time("2026-02-28") in my test to prevent this behavior.
Runbot Error Link: https://runbot.odoo.com/odoo/runbot.build.error/240992
task - 6018940
Forward-Port-Of: odoo/enterprise#109975This update fixes an issue in the l10n_pe_edi_pos module that prevented accurate consolidation of Point of Sale (POS) orders. The system now validates order groupings, preventing errors when attempting to combine invoices that don't meet necessary criteria and providing helpful error messages to the user.
Original PR description
Joining the values in the selection field with a coma, and then putting everything in another selection field was plain wrong. We now check a bit better what we're generating, and refrain the user with error messages when they try grouping on the same invoices orders that do not share the necessary key values. Forward-Port-Of: odoo/enterprise#111616
This update resolves a crash issue when opening tax reports in Odoo Enterprise. The fix ensures reports without a defined return type automatically use the company's tax periodicity, preventing errors and improving report stability. This enhances the reliability of financial reporting.
Original PR description
When a report uses 'previous_return_period' date_scope on one of its expressions, if there's no account.return.type linked to that report, the opening of the report crashes. This is a bit stupid,…
When a report uses 'previous_return_period' date_scope on one of its expressions, if there's no account.return.type linked to that report, the opening of the report crashes. This is a bit stupid, since a return type without periodicity will anyway fallback to the the company's tax periodicity field. When there's no return type, we should simply fallback in the same way. To reproduce: - Make a Belgian company, install the CoA and localization - Manually uninstall l10n_be_reports - Try opening the tax report Another message also checked that we couldn't compute this date_scope in case there was more than one return type linked to the report, arguing they have different periodicities, so we can't infer which one to use. However, it they actually shared the same periodicity, that check failed anyway. We refine it to authorize this case, and only raise if they truly have different periodicities. opw-6022150 Forward-Port-Of: odoo/enterprise#111872 Forward-Port-Of: odoo/enterprise#111796
This update fixes an issue where selected failure locations weren't being applied during product repairs. Now, when a quality check fails, the product is automatically moved to the user-specified failure location, ensuring accurate inventory and repair tracking. This improves the reliability of the repair process.
Original PR description
Before this commit: ------------------------- - In the Repair module, when a quality check for a product was marked as failed, Even after selecting a failure location, the failure location is not…
Before this commit: ------------------------- - In the Repair module, when a quality check for a product was marked as failed, Even after selecting a failure location, the failure location is not being set at the final product move. - Instead of showing the selected failure location, the system displayed another location as the move destination after completing the repair process. Steps to reproduce: ------------------------- 1. Install the quality_repair module. 2. In Quality, create a Control Point with: - Type = Pass-Fail - Control Per = Product or Operation - Set at least 1 Failure Location 3. Create a Repair Order for any product and start the repair process. 4. Perform a quality check, set it to Fail, and select a failure location. 5. Open the product moves, the destination location does not match the selected failure location. Cause of the issue: ------------------------- The failure location was not correctly assigned when a quality check failed during the repair process because _move_to_failure_location determines the destination location based on a stock picking (for receipts) or a production_id (for manufacturing). In the Repair module, however, quality checks are linked to a repair order, so the selected failure location was not set correctly. After this commit: ----------------------- - When a quality check fails in a repair order, the product’s destination location is correctly set to the failure location selected by the user. - This ensures that, upon completion of the repair, the product is moved to the selected failure location, maintaining accurate inventory tracking and management. Task ID:5254334 Forward-Port-Of: odoo/enterprise#99235
This update fixes an issue where quarterly VAT returns in the Italian module didn't automatically generate the required XML export files. The fix correctly uses the 'date_to' field for quarter detection, ensuring accurate XML generation. It also improves data accuracy for quarterly reports by simplifying calculations.
Original PR description
## Issue: When the tax return periodicity is set to quarterly and the return is validated, the XML file is not generated and downloaded ## Cause: The quarter detection logic was based on the `date_from` field of the return However, for quarterly returns, the correct reference should be `date_to` Using `date_to` also works correctly for monthly returns ## Steps to reproduce: - Install `l10n_it_xml_export` - Switch to the IT Company - Go in the Tax Report (Monthly VAT Report (IT)) to do a Tax Return (Opening Date: 01/01/2025, Periodicity: Quarterly) - If needed change the Tax Return Periodicity in Settings to Quaterly - Select the first report and ignore the error in Review Before the fix, it is only possible to close the return without generating the XML export opw-5707544 Forward-Port-Of: odoo/enterprise#111370 Forward-Port-Of: odoo/enterprise#108548
This update resolves an issue where searching for deliveries solely by zip code resulted in inaccurate location data being sent to Sendcloud. The system now correctly handles zip codes and includes the city information, ensuring accurate delivery point selection. This improves the reliability of our Sendcloud integration.
Original PR description
Issue ----- Searching for locations by only providing a zip code has unexpected results. Steps to reproduce ----- - Set up Sendcloud with Mondial Relay - Create a sale through the website - Get to the delivery part - Select sendcloud delivery - Search for a zip code only (11000) > Points are all in the 12200 area Cause ----- When searching through the wizard, a temporary address is created in https://github.com/odoo/odoo/blob/89e5038c224d58a2f6be8f3001fd0a2932733cbc/addons/delivery/models/sale_order.py#L108-L112 which always has its' city field set to `False`, as all of the wizard's info is interpreted as the zip code. This leads to the address field sent to Sendcloud being '11000 False' instead of the expected '11000', which Sendcloud fails to interpret correctly. ----- Ticket: opw-5999194 Forward-Port-Of: odoo/enterprise#110459
This update resolves a technical issue preventing invoices with discounts and decimal values (over 2 decimals) from successfully sending to ARCA for Arabic EDI processing. The fix utilizes a truncated unit price for discount calculations, ensuring accurate decimal alignment and preventing errors.
Original PR description
After changes made in Odoo of how the decimal precision works some of the code we use to prepare the data to create EDI invoices now fails. We already adapt the code to fix the data depending of the expected webserive format but we miss a case related to when invovice has discounts. The problem is that any invoice with lines that has more than 2 decimals and also have a discount will fail when trying send it to ARCA because the computed amount has differences in the decimals. Now we use the truncated unit price to compute the discount instead of the full amount with decimal of the `line.price_unit` value. Forward-Port-Of: odoo/enterprise#111518 Forward-Port-Of: odoo/enterprise#110706
16 changes
Resolved issues and error corrections
A recent update caused partner names in the approval request report to overflow, making the report unreadable. This fix adds a column limit to the partner field, ensuring all data displays correctly and preventing visual errors. This improves the report's usability and data presentation.
Original PR description
step to reproduce: - install "approval" with demo data - have a partner with name length > 63 - open one of the approvals and change its type to "general approval" - add this partner in contact field - print approval request report Observation: - the partner overflows out of report Fix: - we limit the partner field with `col-9`. For a safe measure i have added `col-9` for `request_owner_id` and `approver_ids` **Before** <img width="1057" height="326" alt="image" src="https://github.com/user-attachments/assets/a8eea789-5cc7-4658-88b5-78751759d043" /> **After** <img width="994" height="330" alt="image" src="https://github.com/user-attachments/assets/bfbc061b-a6e0-4593-a3cc-c85cb81db6e2" /> opw-6005752 Forward-Port-Of: odoo/enterprise#111130
This update fixes an issue where failed quality checks weren't correctly splitting stock moves, leading to inaccurate demand calculations. The fix ensures that when a partial failure occurs, the stock move is divided accurately, maintaining correct inventory levels. This improves the reliability of quality control processes and prevents stock discrepancies.
Original PR description
**Steps to reproduce:** * Install the `quality_control` module. * Create a storable product. * Configure a Quality Control Point: * Set Control per : Quantity. * Set Operation Type to Receipts. * Set…
**Steps to reproduce:** * Install the `quality_control` module. * Create a storable product. * Configure a Quality Control Point: * Set Control per : Quantity. * Set Operation Type to Receipts. * Set Product to the created product. * Create a Receipt for the product with a demand of 5 units. * Confirm the receipt and mark it as To Do. * Click on the Quality Check button. * Click on Fail and set the failed quantity to 3. * Click on Confirm. **Observed behavior:** * A new stock move is created for the failed quantity. * The original move is split incorrectly: * First move: 2 `product_uom_qty` and 2 `quantity`. * Second move: 2 `product_uom_qty` and 3 `quantity`. * The failed move has a demand of **2** instead of **3**. **Cause:** * Clicking on *Quality Check* triggers `check_quality`, which opens the wizard `action_open_quality_check_wizard`: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/stock_picking.py#L79-L82 * Clicking on *Fail* triggers `do_fail`, opening the confirmation wizard: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/wizard/quality_check_wizard.py#L85-L88 * Clicking on *Confirm* triggers `confirm_fail`, which calls `_move_line_to_failure_location`: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/wizard/quality_check_wizard.py#L97 * In `_move_line_to_failure_location`, a new stock move is created for the failed quantity: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/quality.py#L480 * The demand quantity is computed using the minimum of the failed quantity and the move line quantity. * This leads to an incorrect demand of *2* instead of *3*. * However, the move line quantity was already reduced by the failed quantity: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/quality.py#L472 **Fix:** * Ensure that partial failures properly split stock moves with correct `product_uom_qty` and `quantity` values. --- opw-5492095 Forward-Port-Of: odoo/enterprise#112298 Forward-Port-Of: odoo/enterprise#107493
This update fixes a warning displayed in the tax report when vendor bills have expense lines with different vehicle assignments. The change allows for more flexibility in how tax lines are matched, ensuring accurate reporting even with mixed vehicle expense lines. This improves the reliability of financial reporting.
Original PR description
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other…
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other without a vehicle. * Confirm the vendor bill. * Go to **Accounting > Reporting > Tax Report** and Go to `Account > Tax` report. **Observed behavior:** * The tax report shows: 'This report contains inconsistencies. The affected lines are marked with a warning.' **Cause:** * The `_get_extra_query_base_tax_line_mapping()` override forced vehicle_id matching using `COALESCE(base_line.vehicle_id, 0) = COALESCE(account_move_line.vehicle_id, 0)`. * When lines share a tax but have different vehicle_id values (one set, one NULL), Odoo creates a single tax line with `vehicle_id = NULL`. * The strict COALESCE constraint prevented this tax line from matching either base line (NULL ≠ vehicle_id and NULL ≠ NULL when coalesced to 0), causing the inconsistency. **Fix:** * Changed the constraint to only enforce vehicle_id matching when both the base line and tax line have a vehicle_id set. * If either side is NULL, the match is allowed, letting shared tax lines work correctly across mixed vehicle/non-vehicle expense lines. opw-5956645 Forward-Port-Of: odoo/enterprise#112313 Forward-Port-Of: odoo/enterprise#110616
This update resolves an issue where web_studio would generate an error when users attempted to save reports with empty XML formats. The fix prevents the system from attempting to process invalid XML data, ensuring reports can be saved correctly. This improves the user experience and prevents data loss.
Original PR description
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External…
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External > Type Text in report - Save > Edit Sources > Remove full XML > Save Error: `XMLSyntaxError:Document is empty, line 1, column 1 (<string>, line 1)` This error occurs because line [1] in `web_editor` attempts to access nodes by using `etree.fromstring()` with an empty `view.arch`, which is empty, resulting in an error. In earlier versions, this error was already handled by the `_check_xml` constraint, which raised a validation error when an `etree.ParseError` occurred while parsing `etree.fromstring(view.arch)` with an empty `view.arch` (see code reference [2]). However, recent changes introduced in commit [3] allow `view.arch` to be empty. As a result, this error is no longer handled by the constraint. This commit fixes the issue by adding a condition to prevent calling `etree.fromstring()` when `view.arch` is empty, avoiding attempts to access nodes from invalid data. It also updates the logic in the `web_studio` module's `get_xml_editor_resources` method to ensure resources are processed only when a valid view architecture is available. [1]: https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/web_editor/models/ir_ui_view.py#L367 [2]: https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/odoo/addons/base/models/ir_ui_view.py#L372-L377 [3]: https://github.com/odoo/odoo/commit/8334ea5c777e5a478f12b8bb7a2f54bcae537d0f sentry-6288795955 Forward-Port-Of: odoo/enterprise#112111 Forward-Port-Of: odoo/enterprise#88613
This fix addresses a technical issue where AI response errors triggered 500 Internal Server Errors, impacting user experience. Now, errors are presented as messages from the AI agent, providing a smoother and more user-friendly experience for business users.
Original PR description
Currently, when an error occurs during `/ai/generate_response` calls from the frontend, a `UserError` is logged with its exception stack instead of being emitted as a logger warning. Additionally, an…
Currently, when an error occurs during `/ai/generate_response` calls from the
frontend, a `UserError` is logged with its exception stack instead of being
emitted as a logger warning. Additionally, an `UncaughtPromiseError` is
surfaced on the UI.
Error:
```
Error on request:
Traceback (most recent call last):
File "/home/odoo/src/enterprise/saas-19.1/ai/utils/llm_api_service.py", line 302, in _request
response.raise_for_status()
File "/usr/lib/python3/dist-packages/requests/models.py", line 1021, in raise_for_status
```
The issue originates from the `/ai/generate_response` route, which is
defined as a controller `type="http"` to handling POST requests. When
line [1] raises an exception inside this controller, it automatically converts
the unhandled exception into an HTTP response. As a result, the request
returns a `500 Internal Server Error`, which then propagates to the frontend
and appears as an `UncaughtPromiseError`.
This commit fixes the issue by returning internal errors as chat
messages instead of raising exceptions. As a result, the error is
displayed as a message received from the AI agent, rather than
propagating as a server error to internal users.
[1]: https://github.com/odoo/enterprise/blob/423dee8f565a6ca7cd88ec0625a5059920725f50/ai/controllers/thread.py#L83
Sentry-5691330773This update fixes an issue where tax returns were incorrectly including Italian pension fund taxes, leading to discrepancies between reports and the backend view. The change excludes these taxes from the tax return domain, ensuring accurate calculations and consistent reporting for Italian customers. This resolves a reported inconsistency.
Original PR description
The "amount to pay" incorrectly included the Pension Fund taxes, causing inconsistencies between the report and what the customer was able to see in the backend. Now we exclude them from the tax return domain. Steps to reproduce: - Create an Italian company with the Italian CoA - Install `l10n_it_edi_withholding` (not necessary in v19) - Create an invoice - Set the 4% INPS or 4% F.Pens taxes on a line, along with with a normal 22% VAT - Create a tax return Ticket [link](https://www.odoo.com/odoo/project.task/5909407) opw-5909407 Forward-Port-Of: odoo/enterprise#111311
A test used in the Odoo Enterprise payroll module failed due to an incorrect date calculation. This fix adjusted the test environment to ensure accurate results, preventing future disruptions to payroll processing. The change addresses a discrepancy in how dates were being interpreted during testing.
Original PR description
[FIX] l10n_ch_hr_payroll_elm_transmission: fix avs test for faketime build
Bug reproduction:
1 - v.17->run test_generic_avs_deductions test with faketime 2027-01-01 12:00 UTC->test fails
Bug cause:
1 - In the test, compute_sheet()->_get_payslip_lines->_compute_rule->_get_avs_rates is called
2 - There is a line like that if line.date_from <= target and (not line.date_to or target <= line.date_to)
3 - I looked to avs_line_ids = fields.One2many(default=_get_default_avs_line_ids)
4 - In _get_default_avs_line_ids -> 'date_from': fields.Date.today().replace(month=1, day=1) date_from is calculated like that -> when the year is 2027, the date_from is 2027-01-01 and it is bigger than the target in the test.
Bug solution:
1 - I used @freeze_time("2026-02-28") in my test to prevent this behavior.
Runbot Error Link: https://runbot.odoo.com/odoo/runbot.build.error/240992
task - 6018940
Forward-Port-Of: odoo/enterprise#109975This update corrects an issue where work orders weren't properly tracking consumed components. The previous changes had unintended consequences, so this revert ensures accurate tracking of materials used in work orders. A new test has also been added to prevent similar problems in the future.
Original PR description
Commit [1] has been merged with another commit OC side. However, the latter has impacted some other use cases. This is the reason why we need to revert both. The current commit also improves a test in `test_consume_component.py` to cover the case that has been broken [1] 75febe5a72f091a9940b27c7a59a31f3fe3c407a opw-5939156 Forward-Port-Of: odoo/enterprise#110675
This update fixes a previous error that caused tracebacks when users interacted with the AI using documents opened in the file viewer. The fix ensures the correct file ID is passed to the AI, resolving a 404 error and improving the AI's ability to process documents. Additionally, the AI's behavior when handling images was stabilized.
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
This update ensures that changes to salary information within the Odoo system only affect related calculations, specifically the mobility budget. Previously, changes in other areas could trigger unintended updates, now the system is more consistent and reliable when managing salary configurations. This improves data accuracy and reduces potential errors.
Original PR description
For consistency purposes, we only trigger the inverse on the mobility budget computation if we are in the context of the salary configurator. Changing the wage in the back end or changing the employer cost should only touch the wage and not other benefits
This update resolves a technical issue where a controller in the E-Commerce localization module (l10n_eg_iot) was incorrectly referencing outdated code from a previous Odoo version. This fix ensures the module functions correctly and avoids potential disruptions to the E-Commerce process. It's a routine maintenance update.
Original PR description
`iot_box_setup` override is still calling the previous method names, mistakenly fw ported from 19. This commit fixes it.
This update resolves a crash issue when opening tax reports in Odoo Enterprise. The fix ensures reports without a defined return type automatically use the company's tax periodicity, preventing errors and improving report stability. This enhances the reliability of financial reporting.
Original PR description
When a report uses 'previous_return_period' date_scope on one of its expressions, if there's no account.return.type linked to that report, the opening of the report crashes. This is a bit stupid,…
When a report uses 'previous_return_period' date_scope on one of its expressions, if there's no account.return.type linked to that report, the opening of the report crashes. This is a bit stupid, since a return type without periodicity will anyway fallback to the the company's tax periodicity field. When there's no return type, we should simply fallback in the same way. To reproduce: - Make a Belgian company, install the CoA and localization - Manually uninstall l10n_be_reports - Try opening the tax report Another message also checked that we couldn't compute this date_scope in case there was more than one return type linked to the report, arguing they have different periodicities, so we can't infer which one to use. However, it they actually shared the same periodicity, that check failed anyway. We refine it to authorize this case, and only raise if they truly have different periodicities. opw-6022150 Forward-Port-Of: odoo/enterprise#111872 Forward-Port-Of: odoo/enterprise#111796
This update fixes an issue where selected failure locations weren't being applied during product repairs. Now, when a quality check fails, the product is automatically moved to the user-specified failure location, ensuring accurate inventory and repair tracking. This improves the reliability of the repair process.
Original PR description
Before this commit: ------------------------- - In the Repair module, when a quality check for a product was marked as failed, Even after selecting a failure location, the failure location is not…
Before this commit: ------------------------- - In the Repair module, when a quality check for a product was marked as failed, Even after selecting a failure location, the failure location is not being set at the final product move. - Instead of showing the selected failure location, the system displayed another location as the move destination after completing the repair process. Steps to reproduce: ------------------------- 1. Install the quality_repair module. 2. In Quality, create a Control Point with: - Type = Pass-Fail - Control Per = Product or Operation - Set at least 1 Failure Location 3. Create a Repair Order for any product and start the repair process. 4. Perform a quality check, set it to Fail, and select a failure location. 5. Open the product moves, the destination location does not match the selected failure location. Cause of the issue: ------------------------- The failure location was not correctly assigned when a quality check failed during the repair process because _move_to_failure_location determines the destination location based on a stock picking (for receipts) or a production_id (for manufacturing). In the Repair module, however, quality checks are linked to a repair order, so the selected failure location was not set correctly. After this commit: ----------------------- - When a quality check fails in a repair order, the product’s destination location is correctly set to the failure location selected by the user. - This ensures that, upon completion of the repair, the product is moved to the selected failure location, maintaining accurate inventory tracking and management. Task ID:5254334 Forward-Port-Of: odoo/enterprise#99235
This update fixes an issue where users were incorrectly grouping POS orders in the l10n_pe_edi_pos module. The system now validates order groupings, preventing errors and providing clear messages to users attempting to combine invoices that don't meet the required criteria. This ensures accurate reporting and compliance for Peruvian businesses.
Original PR description
Joining the values in the selection field with a coma, and then putting everything in another selection field was plain wrong. We now check a bit better what we're generating, and refrain the user with error messages when they try grouping on the same invoices orders that do not share the necessary key values. Forward-Port-Of: odoo/enterprise#111616
This update prevents unnecessary rental planning slots from being created when the 'Plan Services' feature is disabled. Previously, updating a rental order would trigger the creation of slots, even without planning. This fix ensures that slots are only generated when 'Plan Services' is enabled, streamlining the rental planning process.
Original PR description
Steps to reproduce: ------------------- 1. Install `sale_renting_planning`. 2. Create a rental service product with: - "Can be Sold" enabled - "Plan Services" disabled - UoM set to "Units" 3. Create and confirm a rental order with this product. 4. Go to Planning and check for slots related to this order. (no slots at this stage) 5. Update the quantity of the rental order. 6. Check Planning again for slots related to this order. Issue: ------ Planning slots are created after updating the quantity of the sale order, even when "Plan Services" is not enabled. Cause: ------ Slot records are created without checking whether "Plan Services" is enabled, which leads to unwanted planning entries. related commit: 74eef70 Solution: --------- Add a condition to ensure planning slots are created only when "Plan Services" is enabled. opw-6051012 Forward-Port-Of: odoo/enterprise#112278
This update clarifies the error message displayed when an upsell's start date is set after the next invoice date. This change ensures users receive clearer guidance, preventing confusion and potential issues with subscription billing. It's a simple fix to improve the user experience.
Original PR description
Update the error message when an upsell start date is on or after the next invoice date, so it be more clear for the users. task-5893032 Forward-Port-Of: odoo/enterprise#106757
8 changes
Resolved issues and error corrections
This update corrects an issue preventing the export of Profit & Loss reports with footnotes enabled in the l10n_lu_reports module. The fix addresses a dependency on an outdated model, ensuring proper XML generation and report functionality. This resolves a technical problem impacting report generation for Luxembourg accounting.
Original PR description
**Steps to reproduce:** * Install the **l10n_lu_reports** module. * Go to **Accounting → Reporting → Profit & Loss**. * Add a footnote on a report line (**⋮ → Annotate**). * Click **Export (XML)** to open the export wizard. * Enable **Import notes as references** and export. **Observed behavior:** * Export fails with `KeyError: 'account.report.manager'`. * XML file cannot be generated when references are enabled. **Cause:** * The export logic relied on the deprecated `account.report.manager` model. * This model was removed in v17([commit](https://github.com/odoo/enterprise/pull/33604/changes#diff-5fc5051f5c0211c0eec96b892e7d29e01b68d804417443502d17bccd8333d7ecL41)) and replaced by `account.report.footnote`. * The footnote retrieval code was not migrated accordingly. **Fix:** * Migrate reference retrieval to use `account.report.footnote`. opw-5890630 Forward-Port-Of: odoo/enterprise#111845 Forward-Port-Of: odoo/enterprise#107765
A recent update caused partner names in the approval request report to be cut off when exceeding a certain length. This fix adds a column limit to the partner field, ensuring all data is displayed correctly and preventing data truncation. This improves the report's accuracy and readability.
Original PR description
step to reproduce: - install "approval" with demo data - have a partner with name length > 63 - open one of the approvals and change its type to "general approval" - add this partner in contact field - print approval request report Observation: - the partner overflows out of report Fix: - we limit the partner field with `col-9`. For a safe measure i have added `col-9` for `request_owner_id` and `approver_ids` **Before** <img width="1057" height="326" alt="image" src="https://github.com/user-attachments/assets/a8eea789-5cc7-4658-88b5-78751759d043" /> **After** <img width="994" height="330" alt="image" src="https://github.com/user-attachments/assets/bfbc061b-a6e0-4593-a3cc-c85cb81db6e2" /> opw-6005752 Forward-Port-Of: odoo/enterprise#111130
This update resolves an inconsistency in the tax report when vendor bills include expense lines with different vehicle assignments. The fix allows for accurate reporting by relaxing a strict matching rule that previously flagged mixed vehicle lines. This ensures all tax calculations are correct, regardless of whether a vehicle is associated with an expense line.
Original PR description
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other…
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other without a vehicle. * Confirm the vendor bill. * Go to **Accounting > Reporting > Tax Report** and Go to `Account > Tax` report. **Observed behavior:** * The tax report shows: 'This report contains inconsistencies. The affected lines are marked with a warning.' **Cause:** * The `_get_extra_query_base_tax_line_mapping()` override forced vehicle_id matching using `COALESCE(base_line.vehicle_id, 0) = COALESCE(account_move_line.vehicle_id, 0)`. * When lines share a tax but have different vehicle_id values (one set, one NULL), Odoo creates a single tax line with `vehicle_id = NULL`. * The strict COALESCE constraint prevented this tax line from matching either base line (NULL ≠ vehicle_id and NULL ≠ NULL when coalesced to 0), causing the inconsistency. **Fix:** * Changed the constraint to only enforce vehicle_id matching when both the base line and tax line have a vehicle_id set. * If either side is NULL, the match is allowed, letting shared tax lines work correctly across mixed vehicle/non-vehicle expense lines. opw-5956645 Forward-Port-Of: odoo/enterprise#112313 Forward-Port-Of: odoo/enterprise#110616
This update fixes an issue where tax returns for Italian companies incorrectly included pension fund taxes, leading to discrepancies between reports and the backend view. The change excludes these taxes from the tax return calculation, ensuring accurate reporting and alignment with customer data. This resolves a prior inconsistency.
Original PR description
The "amount to pay" incorrectly included the Pension Fund taxes, causing inconsistencies between the report and what the customer was able to see in the backend. Now we exclude them from the tax return domain. Steps to reproduce: - Create an Italian company with the Italian CoA - Install `l10n_it_edi_withholding` (not necessary in v19) - Create an invoice - Set the 4% INPS or 4% F.Pens taxes on a line, along with with a normal 22% VAT - Create a tax return Ticket [link](https://www.odoo.com/odoo/project.task/5909407) opw-5909407 Forward-Port-Of: odoo/enterprise#111311
A test used an incorrect date reference (2027) which caused it to fail. This fix adjusted the test's date to 2026-02-28 to accurately reflect the payroll calculations, ensuring the test now passes. This resolves a potential issue with reporting accuracy.
Original PR description
[FIX] l10n_ch_hr_payroll_elm_transmission: fix avs test for faketime build
Bug reproduction:
1 - v.17->run test_generic_avs_deductions test with faketime 2027-01-01 12:00 UTC->test fails
Bug cause:
1 - In the test, compute_sheet()->_get_payslip_lines->_compute_rule->_get_avs_rates is called
2 - There is a line like that if line.date_from <= target and (not line.date_to or target <= line.date_to)
3 - I looked to avs_line_ids = fields.One2many(default=_get_default_avs_line_ids)
4 - In _get_default_avs_line_ids -> 'date_from': fields.Date.today().replace(month=1, day=1) date_from is calculated like that -> when the year is 2027, the date_from is 2027-01-01 and it is bigger than the target in the test.
Bug solution:
1 - I used @freeze_time("2026-02-28") in my test to prevent this behavior.
Runbot Error Link: https://runbot.odoo.com/odoo/runbot.build.error/240992
task - 6018940
Forward-Port-Of: odoo/enterprise#109975This 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 data accuracy and reliability.
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…
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#111956
Forward-Port-Of: odoo/enterprise#109671This update fixes an issue where users were incorrectly grouping POS orders in the l10n_pe_edi_pos module. The system now validates order groupings, preventing errors and providing clear messages to users attempting to combine invoices without the necessary shared identifiers. This ensures accurate reporting and compliance for Peruvian businesses.
Original PR description
Joining the values in the selection field with a coma, and then putting everything in another selection field was plain wrong. We now check a bit better what we're generating, and refrain the user with error messages when they try grouping on the same invoices orders that do not share the necessary key values. Forward-Port-Of: odoo/enterprise#111616
This update clarifies the error message displayed when an upsell's start date is set after the next invoice date. This change ensures users receive clearer guidance, preventing confusion and potential issues with subscription billing. It's a simple fix to improve the user experience.
Original PR description
Update the error message when an upsell start date is on or after the next invoice date, so it be more clear for the users. task-5893032 Forward-Port-Of: odoo/enterprise#106757
27 changes
Resolved issues and error corrections
This update corrects an issue where modifying a recurring event's start time caused duplicate events to be created in Outlook, leading to incorrect meeting notifications. The fix ensures Microsoft IDs are preserved when the base event is an exception, resolving this duplication problem and improving Outlook synchronization.
Original PR description
When an attendee syncs a recurring event where the first occurrence (base event) was modified by the organizer, `_write_from_microsoft` falsely triggers the destructive recreation path. This happens because `_has_base_event_time_fields_changed` compares the exception's modified time against the seriesMaster's pattern time, detecting a "change" even though the master hasn't changed. This causes: - All non-base events lose their microsoft_id and ms_universal_event_id - The base event gets recreated without Microsoft IDs - A duplicate event is pushed to Outlook on the next odoo2microsoft sync - Spurious "join the meeting now" notifications are sent to attendees Add a `follow_recurrence` guard so that when the base event is an exception (follow_recurrence=False), the non-destructive else branch is taken instead, preserving all Microsoft IDs. Forward-Port-Of: odoo/odoo#256263 Forward-Port-Of: odoo/odoo#254414
This update prevents a critical error that occurred when users attempted to create scrap orders without a designated scrap location. The issue stemmed from accessing an empty dictionary after a scrap location was deleted, leading to a traceback. This fix ensures that scrap orders can now be created successfully, regardless of the scrap location setup.
Original PR description
When user tries to create a scrap order without scrap location, A traceback is raised. Steps to reproduce the error: - Install ``stock`` module - Go to Inventory > Configuration > Settings > Enable Storage Locations > Save - Go to Configuration > Locations > Delete Virtual Locations/Scrap > Delete - Go to Operations > Scrap > New Traceback: ```py KeyError: 1 ``` https://github.com/odoo/odoo/blob/7d89c092ac25ffe149fb38fb52863fdaa3b6ed5f/addons/stock/models/stock_scrap.py#L93 When the Scrap location is deleted, ``locations_per_company`` becomes an empty dictionary. Accessing a key from this empty dictionary lead to the above traceback. sentry-7307394327 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252192
This update fixes a problem where PoS orders with additional products prevented successful settlement from the Point of Sale. The system now correctly calculates the total amount based on the PoS order, ensuring sales can be settled properly after down payments and extra items are added. This resolves a scenario where the sale order total was incorrectly calculated.
Original PR description
The following commit introduced a change in compute_unpaid_amount. https://github.com/odoo/odoo/commit/b8b50a797cdc0053643f959eb2d04800163fe005 The unpaid_amount is now computed from the PoS order total instead of the settle payment order line. This causes an issue when the PoS order contains additional product lines besides the settle payment line. In such cases, the total amount may exceed the sale order amount, preventing the sale order from being settled again from the PoS. How to reproduce: - Create a sale order. - Apply a down payment in the PoS. - Add other products before validating the payment. - Ensure the total exceeds the sale order amount. - Pay the order. - Try to settle the same sale order from PoS, cannot find it. opw-5821232
This update corrects an issue preventing the export of Profit & Loss reports with footnotes in the Luxembourg localization. The previous export process relied on an outdated model, causing errors. The fix now correctly utilizes the new `account.report.annotation` model for footnote references, ensuring successful XML generation.
Original PR description
**Steps to reproduce:** * Install the **l10n_lu_reports** module. * Go to **Accounting → Reporting → Profit & Loss**. * Add a footnote on a report line (**⋮ → Annotate**). * Click **Export (XML)** to open the export wizard. * Enable **Import notes as references** and export. **Observed behavior:** * Export fails with `KeyError: 'account.report.manager'`. * XML file cannot be generated when references are enabled. **Cause:** * The export logic relied on the deprecated `account.report.manager` model. * This model was removed in v17([commit](https://github.com/odoo/enterprise/pull/33604/changes#diff-5fc5051f5c0211c0eec96b892e7d29e01b68d804417443502d17bccd8333d7ecL41)) and replaced by `account.report.footnote`. * The footnote retrieval code was not migrated accordingly. **Fix:** * Migrate reference retrieval to use `account.report.footnote`. opw-5890630 Forward-Port-Of: odoo/enterprise#111845 Forward-Port-Of: odoo/enterprise#107765
A recent update caused partner names in the approval request report to overflow, making the report visually unclear. This fix adds a column limit to the partner field, ensuring all data is displayed correctly and preventing the report from becoming unreadable. This improves the report's usability and data accuracy.
Original PR description
step to reproduce: - install "approval" with demo data - have a partner with name length > 63 - open one of the approvals and change its type to "general approval" - add this partner in contact field - print approval request report Observation: - the partner overflows out of report Fix: - we limit the partner field with `col-9`. For a safe measure i have added `col-9` for `request_owner_id` and `approver_ids` **Before** <img width="1057" height="326" alt="image" src="https://github.com/user-attachments/assets/a8eea789-5cc7-4658-88b5-78751759d043" /> **After** <img width="994" height="330" alt="image" src="https://github.com/user-attachments/assets/bfbc061b-a6e0-4593-a3cc-c85cb81db6e2" /> opw-6005752 Forward-Port-Of: odoo/enterprise#111130
This update fixes an issue where invoices created with the 'Pay Later' payment method in the Point of Sale module were missing the necessary QR code for payment. The fix ensures that invoices correctly identify the bank partner, resolving this problem and allowing for proper payment processing. This improves the user experience for customers using this payment option.
Original PR description
Step to reproduce: - Install l10n_ch_pos and make sure swiss company has tax id filled - Create a swiss customer with an email address and vat, add full address - Open a pos session, and make an invoice for a product with tax, - select payment method, which allows `pay_later`, i.e. payment without journal_id Observation: - the invoiced order, do not have qr for payment, because the invoice do not have `bank_partner_id` Cause: - `_get_partner_bank_id` is recently updated in commit[1], which do not considered `pay_later` option [1] https://github.com/odoo/odoo/commit/7e63991dceb6e443b950e6a1b94454a82d5668c7 Fix: - Fixed the fallback logic for `_get_partner_bank_id` opw-6023060 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254892 Forward-Port-Of: odoo/odoo#254117
This update ensures that when creating new analytic items from the gross margin smart button, the correct analytic account is automatically selected. Previously, new records didn't link to an account, requiring manual setup. This change streamlines the process and improves data accuracy within the analytic accounting module.
Original PR description
When accessing analytic items from the gross margin smart button on an analytic account, creating a new record does not pre-fill the analytic account field. This happens because the context does not set `default_account_id` for the active analytic account, leading to newly created lines not being linked at creation time. This commit ensures the analytic account is correctly passed through the context, so it is automatically set when creating a new analytic line from this flow. Steps to reproduce: - Open an analytic account - Click on the gross margin smart button - Create a new analytic item Before: analytic account not set by default After: analytic account is pre-filled via context task-3909624 Forward-Port-Of: odoo/odoo#256091 Forward-Port-Of: odoo/odoo#255726
This update fixes an issue where chatbot restart messages were incorrectly included in new ticket or lead descriptions. Now, only messages sent after the chatbot is restarted are accurately reflected, ensuring ticket descriptions are clean and relevant. This improves the clarity and usability of customer support tickets.
Original PR description
Before this commit: When a chatbot conversation is restarted and the script creates a new ticket/lead, the description also includes messages from the previous session. After this commit: Only the messages sent after the chatbot conversation is restarted are included in the ticket/lead description. Task-5118966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255336 Forward-Port-Of: odoo/odoo#253566
This update fixes an issue where users were incorrectly grouping POS orders in the l10n_pe_edi_pos module. The system now validates order groupings, preventing errors and providing clear messages to users attempting to combine invoices without the necessary shared identifiers. This ensures accurate reporting and compliance for Peruvian businesses.
Original PR description
Joining the values in the selection field with a coma, and then putting everything in another selection field was plain wrong. We now check a bit better what we're generating, and refrain the user with error messages when they try grouping on the same invoices orders that do not share the necessary key values.
This update replaces the old iDEAL logo with the new Wero logo for improved brand consistency. The change ensures that customers see the correct payment brand when using the iDEAL payment method within Odoo, enhancing the user experience.
Original PR description
Before the commit: The iDEAL payment method was using the existed legacy iDEAL logo. After the commit: - Updated the display name to "iDEAL / Wero". - Replaced the legacy iDEAL logo with the new Wero logo. - Introduced a separate "Wero" payment brand. task-5922938 Forward-Port-Of: odoo/odoo#254901 Forward-Port-Of: odoo/odoo#248506
This update resolves an issue where the tax report incorrectly flagged inconsistencies when vendor bills had expense lines with different vehicle assignments. The fix allows for accurate reporting when lines share a tax but have varying vehicle IDs, ensuring consistent tax calculations for all expenses.
Original PR description
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other…
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other without a vehicle. * Confirm the vendor bill. * Go to **Accounting > Reporting > Tax Report** and Go to `Account > Tax` report. **Observed behavior:** * The tax report shows: 'This report contains inconsistencies. The affected lines are marked with a warning.' **Cause:** * The `_get_extra_query_base_tax_line_mapping()` override forced vehicle_id matching using `COALESCE(base_line.vehicle_id, 0) = COALESCE(account_move_line.vehicle_id, 0)`. * When lines share a tax but have different vehicle_id values (one set, one NULL), Odoo creates a single tax line with `vehicle_id = NULL`. * The strict COALESCE constraint prevented this tax line from matching either base line (NULL ≠ vehicle_id and NULL ≠ NULL when coalesced to 0), causing the inconsistency. **Fix:** * Changed the constraint to only enforce vehicle_id matching when both the base line and tax line have a vehicle_id set. * If either side is NULL, the match is allowed, letting shared tax lines work correctly across mixed vehicle/non-vehicle expense lines. opw-5956645 Forward-Port-Of: odoo/enterprise#112313 Forward-Port-Of: odoo/enterprise#110616
This update resolves an issue where credit notes created via '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 maintains consistent data across invoices and sales orders.
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,…
### 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#254290
This update ensures that the system correctly checks archived accounts when creating unaffected earnings accounts. Previously, this caused validation errors, particularly during upgrades with the `l10n_sa` module, due to a search for duplicate account codes including archived ones.
Original PR description
Archived accounts are also searched when looking for duplicate codes since https://github.com/odoo/odoo/commit/cd8d9718427e48aaa79be21f9a08e89b79b573f9 We need to check archived accounts as well when creating the unaffected earnings account, to avoid triggering the validation if an archived account has the same code. This is failing on upgrades with `l10n_sa` installed where the account `sa_account_999999` has been archived.
This update resolves an issue where the VAT partner listing report was not displaying all relevant customers. The fix involves adjusting a setting within the report to load all partners, ensuring accurate reporting of financial data. This improves data visibility and reporting accuracy for tax compliance.
Original PR description
With l10n_be company: - Create at least two invoices for two different customers (companies) for whom you will add a fake VAT number. Make sure the total on both your invoices is more than 250€ and…
With l10n_be company: - Create at least two invoices for two different customers (companies) for whom you will add a fake VAT number. Make sure the total on both your invoices is more than 250€ and set their Accounting date to last year. - Go check the VAT partner Listing report (Accounting > Reporting); make sure you see both partners in the listing. - Click on returns > Check that report return then Submit and download the XML file: both partners & amounts will appear. - Now with dev mode, go to Accounting reports, open the Partner VAT listing form > Options > set the "load more limit" to 1. Download the XML again: only the first partner appears (the only that was loaded with the load more limit. This commit is a backport of bugfix: PR odoo/enterprise#106134 commit e532750fe3dc1f2d10d995d01446b04a3a227a72 Original problem introduced in `saas-18.3`: PR odoo/enterprise#111783 commit 4c927b389252b595bcbb44d020899ae5abf0aa89 Ticket [link](https://www.odoo.com/odoo/project.task/6051120) opw-6051120
We've been experiencing an increase in failed payments due to an issue with the Flutterwave payment processor. This change updates how the phone number is sent to Flutterwave, aligning with a recent API update that requires an unformatted phone number. 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#256315
This update fixes an issue where the barcode scanner was incorrectly using the user's company instead of the current business context. This resulted in incorrect barcode lookups. The fix ensures the scanner uses the correct company information, resolving the problem of incorrect product identification.
Original PR description
### Issue: The company used in the main barcode menu is the `company_id` of the user rather than the current contextual company of the session. This is problematic as we might endup using the wrong…
### Issue: The company used in the main barcode menu is the `company_id` of the user rather than the current contextual company of the session. This is problematic as we might endup using the wrong barcode nomenclature. ### Steps to reproduce: - Have 2 companies: company 1 and company 2 - Set the barcode nomenclature of company 1: default, company 2: GS1 - Incarnate a user allowed in both companies but with default company 1 - With company 2, create a product and set its barcode to 36939282410106 - From the main menu open the barcode app and scan 0136939282410106 #### > No product was found (even thought it is correct in GS1) ### Cause of the issue: Scanning from the main barcode menu will trigger a call of the `main_menu` method relying on the nomenclature of the contextual company of the request: https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/static/src/main_menu/main_menu.js#L98-L99 https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/controllers/stock_barcode.py#L15-L21 However, when opening the main barcode menu from the app menu, no contextual warehouse was set to the view: https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/views/stock_barcode_views.xml#L6-L11 As such, the environment of the request will be set here: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/http.py#L2083 based on the company of the user rather than the one of the context: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/api.py#L694-L722 ### Fix: Setting the company slices the `current_company` in first position of the `allowed_company_ids`: https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L33-L39 https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L68-L81 which can be recovered from the cookies via the `_get_allowed_company_ids`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L432-L442 precisely used by the `_get_barcode_nomenclature`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L485-L491 Note that passing the context in the arguments of the `main_menu` JSON route will not really solve the issue by it self since the context is no longer shared with the request: c8cd1d4a83de7a5798cbb910a788fbb6fe208d2f ### Additional Issue: The type `dest_location` does not exist on barcode types: https://github.com/odoo/odoo/blob/485a64b6a1e91feb4310f282c6dd1cd021f1780b/addons/barcodes_gs1_nomenclature/models/barcode_rule.py#L16-L20 so that the type used by these lines can not work: https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L29-L30 https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L52-L56 ### Steps to reproduce: - In the settings enable: Multi-Steps Routes - Set the barcode nomenclature to GS1 - Set your warehouse in receipt in two steps and add a barcode to the WH/Input: 3033710074365 - From the main menu open the barcode app and scan 4133033710074365 #### > No product or picking was found (even thought it is correct in GS1 that should create an internal transfer with WH/INPUT as destination) opw-5847529 Forward-Port-Of: odoo/enterprise#112006 Forward-Port-Of: odoo/enterprise#111662
A test used in the payroll module (l10n_ch_hr_payroll_elm_transmission) was failing due to an incorrect date calculation. The fix involved adjusting the test's time setting to ensure accurate calculations for future payroll years, preventing a disruption in reporting.
Original PR description
[FIX] l10n_ch_hr_payroll_elm_transmission: fix avs test for faketime build
Bug reproduction:
1 - v.17->run test_generic_avs_deductions test with faketime 2027-01-01 12:00 UTC->test fails
Bug cause:
1 - In the test, compute_sheet()->_get_payslip_lines->_compute_rule->_get_avs_rates is called
2 - There is a line like that if line.date_from <= target and (not line.date_to or target <= line.date_to)
3 - I looked to avs_line_ids = fields.One2many(default=_get_default_avs_line_ids)
4 - In _get_default_avs_line_ids -> 'date_from': fields.Date.today().replace(month=1, day=1) date_from is calculated like that -> when the year is 2027, the date_from is 2027-01-01 and it is bigger than the target in the test.
Bug solution:
1 - I used @freeze_time("2026-02-28") in my test to prevent this behavior.
Runbot Error Link: https://runbot.odoo.com/odoo/runbot.build.error/240992
task - 6018940
Forward-Port-Of: odoo/enterprise#109975This update fixes a labeling issue with the 0% VAT rate for sales outside the EU in Sweden. The tax name has been corrected to '0% EX RS' to accurately reflect its usage, and the associated grid has been updated. This ensures accurate tax reporting and compliance for Swedish customers.
Original PR description
Currently, the tax for "VAT Sale of service outside EU 0%" has the 0% EU RS name and is associated with the se_39 grid. Since it is for outside the EU, it's name should be 0% EX RS and the grid should be se_40 opw-5798152 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251750
This update fixes an issue where Chrome logs weren't reliably captured during shutdown, particularly when errors occurred. The changes also address Chrome's log buffering behavior and add resilience to ensure a smoother shutdown process, preventing data loss.
Original PR description
odoo/odoo#255054 saved the chrome log at the end of a tour (logging that as `INFO` on success and `RUNBOT` on failure). However as it turns out there are a few issues with that: 1. In case of chrome error during termination (`stop`), those errors can not be in the log, since the log was already saved. 2. Chrome buffers logs a lot more than anticipated, and because `--v=0` logs are a lot less chatty than `--v=1` the logs routinely show essentially nothing (a few tour steps are logged then nothing). Also make `stop` a bit more resilient to chrome issues: - handle errors around ws shutdown - wait for chrome to shut down before we try to remove the data directory - also add a fallback *killing* chrome if it doesn't seem to be shutting down Forward-Port-Of: odoo/odoo#256306 Forward-Port-Of: odoo/odoo#256061
This update resolves an issue that prevented the creation of contracts when a working schedule had zero hours. The fix prevents a division-by-zero error during hourly wage computation, ensuring contracts can be created correctly. This improves the reliability of the Australian payroll module.
Original PR description
When a working schedule has 0 working hours, creating a contract raises a traceback during hourly wage computation. Steps to reproduce the error: - Install ``l10n_au_hr_payroll`` module - Switch to ``My Australian Company`` - Create a working schedule without any working hours - Create an employee and assign this working schedule > Save - Click on Contracts smart button Traceback: ```py ZeroDivisionError: float division by zero ``` https://github.com/odoo/enterprise/blob/bd746aa43f549c4f7813a849e00447b55e084f21/l10n_au_hr_payroll/models/hr_contract.py#L113-L115 The hourly wage is computed using the working schedule’s hours per day. When this value is 0, it results in the above traceback. sentry-7355577930 Forward-Port-Of: odoo/enterprise#111629
This update fixes an issue where URLs in emails were incorrectly encoded, potentially leading to display problems. The change utilizes modern URL handling techniques for accurate URL construction and display, ensuring correct links are presented to users. This improves the reliability of email communications within Odoo.
Original PR description
Before this commit, the URL was fully encoded using encodeUrl. This commit replaces this approach with the more modern [URL api](https://developer.mozilla.org/en-US/docs/Web/API/URL), which [handles encoding](https://url.spec.whatwg.org/#dom-url-href) properly. This commit also removes decodeUrl. It was possible for a user to send a URL and have a different one displayed in the UI due to decoding. Task-6041689 Forward-Port-Of: odoo/odoo#254383
This update fixes an error in the Point of Sale session reports where discount amounts were calculated incorrectly. The fix ensures that discounts are applied accurately after the fiscal position is applied, leading to more reliable financial reporting. This improves the accuracy of sales data and reduces potential discrepancies.
Original PR description
Steps: ---- - Create a fiscal position with 2 different taxes - Add a line in POS - Apply fiscal position and add line discount - Finish the order cycle - Download the session report Issue: ---- - The discount amount was calculated incorrectly in the session report Cause: ---- - The discount amount calculation used taxes before applying the fiscal position Fix: ---- - Used `tax_ids_after_fiscal_position` for tax calculation while computing the discount amount task-5421215 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247072 Forward-Port-Of: odoo/odoo#244650
This update resolves an issue where confirming quantities of archived products through the barcode app would trigger an error. The fix ensures that archived products are included in product searches, allowing users to accurately manage and confirm quantities, maintaining consistent functionality.
Original PR description
Currently, when a user confirms the quantity of an archived product using the product selector in the barcode app, a traceback error occurs. ## Steps to replicate: - Install Inventory - Go to…
Currently, when a user confirms the quantity of an archived product using the product selector in the barcode app, a traceback error occurs. ## Steps to replicate: - Install Inventory - Go to Settings and enable Multi-Step Routes > Set Warehouse Routes. - Configure 2 steps for outgoing shipments. - Go to Inventory and create a new delivery with - **Source Location:** WH/Stock - **Product:** [E-COM10] Pedal Bin with demand 1 - Mark as Todo then Archive the Pedal Bin product. - Open that delivery in barcode app - Pencil icon > +1 > Confirm ## Observed behavior: TypeError: Cannot read properties of undefined (reading 'qty_available') ## Root cause: After this [commit], an override was added to the product selector. As a result, when [2] calls the `search_read` method, it only retrieves non-archived products Consequently, if the result is an empty array, attempting to access `qty_available` causes the type error mentioned above. ## Solution: Adding` active_test = false `to the context ensures that archived products are included in search results. This prevents empty results and avoids the error. It also allows quantities to be added and confirmed,maintaining the same behavior as when using the increment button followed by validation, ensuring consistency. [commit]: https://github.com/odoo/enterprise/commit/6aa814f59f8641d7b57af160e38b50d5bdfc8a97 [2]- https://github.com/odoo/enterprise/blob/e13b44b353e734a6533f7d627ed69b6e7b033ee2/stock_barcode/static/src/js/stock_barcode_sml_form.js#L40-L45 opw-5980428 Forward-Port-Of: odoo/enterprise#109204
A test tour was failing because the test user lacked the necessary security group (`group_production_lot`) to enable line grouping in the stock barcode model. This fix adds the required group, allowing the tour to complete successfully and ensuring proper functionality for lot scanning and packaging.
Original PR description
```js ---------- FAILED: [7/19] Tour test_quality_check_packages_lots_tour → Step .o_barcode_line_summary ---------- { 'trigger': '.o_barcode_line_summary', 'run': 'click' },…
```js
---------- FAILED: [7/19] Tour test_quality_check_packages_lots_tour →
Step .o_barcode_line_summary ----------
{
'trigger': '.o_barcode_line_summary',
'run': 'click'
},
------------------------------------------------------------------------
```
The tour `test_quality_check_packages_lots_tour` was failing at the step
waiting for `.o_barcode_line_summary` after calling `o_put_in_pack`.
**Root cause:**
the JS barcode model sets `groupingLinesEnabled` directly from
the `group_production_lot` security group flag returned by the backend:
https://github.com/odoo/enterprise/blob/bd35e9c16a6c0fd743c934024db2821b8ae21fdc/stock_barcode/static/src/models/barcode_model.js#L53
When `groupingLinesEnabled` is false, `groupLines()` skips the grouping
logic entirely and individual move lines are rendered as flat
`LineComponent` instances. The `.o_barcode_line_summary` element only
exists inside `GroupedLineComponent`, which is only rendered when lines
are actually grouped (i.e. a parent line has `line.lines` sublines).
The test setup already granted `group_tracking_lot` (required to show the
`o_put_in_pack` button) but was missing `group_production_lot`. Without
it, after scanning `lot-01` twice and packing, the two lot sub-lines were
never merged into a `GroupedLineComponent`, so `.o_barcode_line_summary`
never appeared in the DOM and the tour timed out.
Fix: add `group_production_lot` alongside `group_tracking_lot` in the
test user's groups so that line grouping is enabled in the JS model,
allowing `GroupedLineComponent` to render `.o_barcode_line_summary` as
expected by the tour.
similar fix - https://github.com/odoo/enterprise/pull/82677/changes/05883b2c9cadb1187df404a4bef638f933922755
---
runbot error:241926This update fixes an issue where the Field Service onboarding tour would stop after redirects to the portal. The change ensures the tour state is preserved in the user's session, allowing the tour to resume seamlessly when returning to the Field Service app. This enhances the user experience for new Field Service users.
Original PR description
**Steps to reproduce:**
1. Go to Field Service app.
2. Check the worksheet template in settings and start the onboarding tour
of Field Service.
**Issue:**
The backend tour is not resuming on the frontend side.
**Fix:**
This commit ensures the tour is enabled and the current tour is added to the frontend session. When the tour resumes, it will fetch the tour enabled and current tour details from the session.
**Technical:**
In the tour service, the tour resumes only if the mode is set to "auto" or toursEnabled is present in the session. To handle this, we added the tour details to the session.
tour_service.js
``` js
if (tourState.getCurrentConfig().mode === "auto" || toursEnabled) {
resumeTour();
}
````
task-4489657
Forward-Port-Of: odoo/odoo#202484This update resolves a bug that prevented the FSM reporting tour from completing correctly when run without demo data. A new worksheet was added to stop the "Explore Worksheets" wizard from appearing, ensuring the tour flows as intended. This improves the user experience for accessing the FSM reporting features.
Original PR description
**Reason for creating the worksheet:** ------------- When the tour runs without demo data, only one worksheet exists, so the **“Explore Worksheets Using an Example Template”** wizard opens and stops the tour. To avoid this, I created an extra worksheet so the wizard does not open and the tour continues normally. https://github.com/odoo/enterprise/blob/85bd9d80a1a784f1baff1493b2eaec4a17ea9c9b/industry_fsm_report/models/project_task.py#L122-L135 task-4489657 Forward-Port-Of: odoo/enterprise#81823
This update clarifies the error message displayed when an upsell's start date is set after the next invoice date. This change ensures users receive clearer guidance, preventing confusion and potential issues with subscription billing. It’s a simple fix to improve user experience.
Original PR description
Update the error message when an upsell start date is on or after the next invoice date, so it be more clear for the users. task-5893032 Forward-Port-Of: odoo/enterprise#106757
2 changes
Resolved issues and error corrections
This update corrects an issue preventing the export of Profit & Loss reports with footnotes enabled in the l10n_lu_reports module. The fix addresses a dependency on an outdated model, ensuring the export process now functions correctly and generates the necessary XML files. This resolves a technical problem impacting report generation for Luxembourg accounting.
Original PR description
**Steps to reproduce:** * Install the **l10n_lu_reports** module. * Go to **Accounting → Reporting → Profit & Loss**. * Add a footnote on a report line (**⋮ → Annotate**). * Click **Export (XML)** to open the export wizard. * Enable **Import notes as references** and export. **Observed behavior:** * Export fails with `KeyError: 'account.report.manager'`. * XML file cannot be generated when references are enabled. **Cause:** * The export logic relied on the deprecated `account.report.manager` model. * This model was removed in v17([commit](https://github.com/odoo/enterprise/pull/33604/changes#diff-5fc5051f5c0211c0eec96b892e7d29e01b68d804417443502d17bccd8333d7ecL41)) and replaced by `account.report.footnote`. * The footnote retrieval code was not migrated accordingly. **Fix:** * Migrate reference retrieval to use `account.report.footnote`. opw-5890630 Forward-Port-Of: odoo/enterprise#111845 Forward-Port-Of: odoo/enterprise#107765
A recent update caused partner names in the approval request report to overflow and display incorrectly when names exceeded a certain length. This fix adds a column limit to the partner field in the report, ensuring all data is displayed correctly and preventing visual errors. This improves the report's readability and accuracy.
Original PR description
step to reproduce: - install "approval" with demo data - have a partner with name length > 63 - open one of the approvals and change its type to "general approval" - add this partner in contact field - print approval request report Observation: - the partner overflows out of report Fix: - we limit the partner field with `col-9`. For a safe measure i have added `col-9` for `request_owner_id` and `approver_ids` **Before** <img width="1057" height="326" alt="image" src="https://github.com/user-attachments/assets/a8eea789-5cc7-4658-88b5-78751759d043" /> **After** <img width="994" height="330" alt="image" src="https://github.com/user-attachments/assets/bfbc061b-a6e0-4593-a3cc-c85cb81db6e2" /> opw-6005752 Forward-Port-Of: odoo/enterprise#111130
25 changes
Resolved issues and error corrections
This update fixes a visual issue on the employee insurance form within the payroll module, ensuring the layout is correctly displayed on smaller screens. The problem stemmed from a technical issue with how input fields were being rendered, and the fix utilizes a different layout structure to resolve this. This ensures a consistent and user-friendly experience for all employees.
Original PR description
Step to reproduce: Employee -> Payrol Tab -> Insurance section -> Company contribution, Employee Contribution, Employee Voluntary Amount -> views not okay in small screens Cause: o_input_box not working with field as o_input_box_overlay_end Solution: using o_row Task: 6070539
This update fixes an issue where failed quality checks weren't correctly splitting stock moves when partial failures occurred. Specifically, the demand quantity was miscalculated, leading to incorrect move splitting. The fix ensures that failed quantities are properly handled, maintaining accurate stock movements and demand calculations. This improves the reliability of quality control processes.
Original PR description
**Steps to reproduce:** * Install the `quality_control` module. * Create a storable product. * Configure a Quality Control Point: * Set Control per : Quantity. * Set Operation Type to Receipts. * Set…
**Steps to reproduce:** * Install the `quality_control` module. * Create a storable product. * Configure a Quality Control Point: * Set Control per : Quantity. * Set Operation Type to Receipts. * Set Product to the created product. * Create a Receipt for the product with a demand of 5 units. * Confirm the receipt and mark it as To Do. * Click on the Quality Check button. * Click on Fail and set the failed quantity to 3. * Click on Confirm. **Observed behavior:** * A new stock move is created for the failed quantity. * The original move is split incorrectly: * First move: 2 `product_uom_qty` and 2 `quantity`. * Second move: 2 `product_uom_qty` and 3 `quantity`. * The failed move has a demand of **2** instead of **3**. **Cause:** * Clicking on *Quality Check* triggers `check_quality`, which opens the wizard `action_open_quality_check_wizard`: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/stock_picking.py#L79-L82 * Clicking on *Fail* triggers `do_fail`, opening the confirmation wizard: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/wizard/quality_check_wizard.py#L85-L88 * Clicking on *Confirm* triggers `confirm_fail`, which calls `_move_line_to_failure_location`: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/wizard/quality_check_wizard.py#L97 * In `_move_line_to_failure_location`, a new stock move is created for the failed quantity: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/quality.py#L480 * The demand quantity is computed using the minimum of the failed quantity and the move line quantity. * This leads to an incorrect demand of *2* instead of *3*. * However, the move line quantity was already reduced by the failed quantity: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/quality.py#L472 **Fix:** * Ensure that partial failures properly split stock moves with correct `product_uom_qty` and `quantity` values. --- opw-5492095 Forward-Port-Of: odoo/enterprise#112298 Forward-Port-Of: odoo/enterprise#107493
This update fixes an issue where manufacturing order notes with only images were being hidden in the Shop Floor view. The change ensures that notes containing images or text are always displayed, improving the clarity and usability of this important production information.
Original PR description
In the Shop Floor view, manufacturing order notes containing only images were being hidden. The logic was stripping all HTML tags to check for text content; if no text was found, the entire note was treated as empty and returned false. This commit: - Updates `logNote` in `MRPDisplayRecord` to ensure the note is returned if it contains either visible text or an `<img>` tag. task-6048473 Forward-Port-Of: odoo/enterprise#111617
This update aligns the user interface of the Sign Now wizard with the Send Request wizard, creating a more uniform experience for users regardless of how they initiate the process (Sign Now or Send Request). This enhances usability and provides a clearer, more consistent workflow for users completing legal agreements.
Original PR description
in this commit i alligned the UI of sign send request wizard to look similar for both cases when the user click sign now and when the user click send request (self sign and send request) Task: 5942397 Forward-Port-Of: odoo/enterprise#108832
This update ensures the Helpdesk module correctly relies on the Portal Rating module following a recent system merge. Explicitly defining this dependency resolves a potential issue and maintains the stability of the Helpdesk functionality. This change is a routine maintenance update.
Original PR description
Before this commit, the helpdesk module now needs `portal_rating` module in its dependencies due to the merge of #112269 This commit updates the dependencies of helpdesk module to explicitly set the `portal_rating` in its dependencies.
This update fixes a visual inconsistency in the Sign app's PDF viewer. Previously, the viewer didn't follow the user's Odoo theme preference. Now, the PDF viewer automatically adapts to light or dark mode based on the user's Odoo settings, ensuring a consistent and professional user experience.
Original PR description
this PR includes 2 Fixes: 1- restore the sign item placeholder initialization that was removed by mistake in a previous refactoring 2- sync the pdf viewer theme with the global odoo theme ( the pdf viewer is an isolated iframe thus its not aware of any theme changes that happens in the parent html so we needed a js bridge to inject the theme values to the viewer) task: 6064905
This update ensures that public holidays are not considered when calculating time off for 'Unpaid' leaves. This change improves the accuracy of leave balances and simplifies the process for employees requesting unpaid leave. It addresses a previous inconsistency in how unpaid leave was handled.
Original PR description
-Public Holidays are set to be ignored in "Unpaid" leaves.
This update resolves problems with the trial balance PDF and working file exports in Odoo Enterprise. Specifically, incorrect dates in the working file exports and issues with the custom template were addressed, ensuring accurate reporting.
Original PR description
Steps to reproduce: - Export the PDF of the trial balance OR - Export a working file Both use the custom template of the trial balance. The date of the working file was also incorrect. Forward-Port-Of: odoo/enterprise#111409
This update fixes an issue where users were incorrectly grouping POS orders. The system now validates order groupings, preventing errors and providing helpful messages to users attempting to combine invoices that don't meet the required criteria. This ensures accurate reporting and data integrity for Peru-specific tax processing.
Original PR description
Joining the values in the selection field with a coma, and then putting everything in another selection field was plain wrong. We now check a bit better what we're generating, and refrain the user with error messages when they try grouping on the same invoices orders that do not share the necessary key values. Forward-Port-Of: odoo/enterprise#111616
This update resolves a problem where percentage fields in contract salaries were not loading correctly or displaying accurate values. The fix ensures that salary calculations and data display within the HR contract management module are now functioning as intended, improving data accuracy and usability.
Original PR description
Forward-Port-Of: odoo/enterprise#110940 Forward-Port-Of: odoo/enterprise#110785
A test used in the Swiss payroll module (l10n_ch_hr_payroll) was failing due to an incorrect date calculation within the AVS deduction process. This fix adjusts the test's time setting to ensure accurate results, preventing future test failures and maintaining the correct AVS calculations.
Original PR description
[FIX] l10n_ch_hr_payroll_elm_transmission: fix avs test for faketime build
Bug reproduction:
1 - v.17->run test_generic_avs_deductions test with faketime 2027-01-01 12:00 UTC->test fails
Bug cause:
1 - In the test, compute_sheet()->_get_payslip_lines->_compute_rule->_get_avs_rates is called
2 - There is a line like that if line.date_from <= target and (not line.date_to or target <= line.date_to)
3 - I looked to avs_line_ids = fields.One2many(default=_get_default_avs_line_ids)
4 - In _get_default_avs_line_ids -> 'date_from': fields.Date.today().replace(month=1, day=1) date_from is calculated like that -> when the year is 2027, the date_from is 2027-01-01 and it is bigger than the target in the test.
Bug solution:
1 - I used @freeze_time("2026-02-28") in my test to prevent this behavior.
Runbot Error Link: https://runbot.odoo.com/odoo/runbot.build.error/240992
task - 6018940
Forward-Port-Of: odoo/enterprise#109975This update fixes an error that prevented users from completing the offer signing process due to a database issue. The problem occurred when an empty field for UAN/PAN/ESIC was stored as a string instead of a null value, triggering a duplicate key error. The fix ensures empty fields are correctly stored as NULL, resolving the error and allowing offer signing to proceed smoothly.
Original PR description
**Version:** master **Issue:** An error occurs during the offer signing process stating that the UAN/PAN/ESIC already exists. **Cause:** When a unique Char field is submitted empty in the salary configurator form, it is stored as an empty string in the database instead of NULL. Since PostgreSQL's unique constraint treats empty strings as real values, any subsequent configurator form opened for a new applicant triggers a duplicate key violation error. **Fix:** Explicitly convert empty unique Char field values to NULL before storing them in the database. **Task-5924388** Forward-Port-Of: odoo/enterprise#111296
This update fixes a technical issue that caused a traceback error when generating the 281.10 report in the Belgian payroll module. The fix ensures accurate report generation by adjusting how the system determines if a payslip is associated with a vehicle, resolving a dependency issue related to the absence of the fleet module.
Original PR description
[FIX] l10n_be_payroll: fix traceback in 281.10 sheets
Bug reproduction: Go to any version>=17.0 -> select belgium company -> install only belgium payroll (don't install fleet one) -> fill in niss, certification level, address, Time in R&D -> generate payslip and confirm it -> try to generate 281.10 report -> traceback
Bug cause:
1 - In traceback it was saying payslip doesn't have vehicle_id, in 281.10 sheet preparation (in function _get_atn_nature), there is a term like that
2 - Payslip doesn't have it because fleet module is not there.
Bug solution:
1 - Instead of checking the payslip has vehicle like that, we calculated it by using paylsip line_ids
2 - If the code ATN.CAR is there and the total of it is not zero, which means this payslip has a vehicle indeed.
task - 6037206
Forward-Port-Of: odoo/enterprise#111960
Forward-Port-Of: odoo/enterprise#110860This update allows users to access and view canceled signature requests within the Odoo portal. Previously, canceled requests were hidden, preventing access to important communication history and document details. Now, users will see the document and can review the request's status.
Original PR description
Previously, users were redirected to the home page if they tried to access a signature request in the 'canceled' state. This prevented them from viewing the communication history or the document metadata. This commit: - Removes the 'canceled' state restriction in the portal controller. - Updates the portal template to show "View Document" instead of "Sign" for canceled requests, similar to the completed state. Task: 6034621 Forward-Port-Of: odoo/enterprise#111534 Forward-Port-Of: odoo/enterprise#110974
This update fixes an issue where product locations weren't correctly set after a quality check failed during the repair process. Now, when a quality check fails, the product is automatically moved to the selected failure location, ensuring accurate inventory management and preventing misrouted products. This improves repair efficiency and data integrity.
Original PR description
Before this commit: ------------------------- - In the Repair module, when a quality check for a product was marked as failed, Even after selecting a failure location, the failure location is not…
Before this commit: ------------------------- - In the Repair module, when a quality check for a product was marked as failed, Even after selecting a failure location, the failure location is not being set at the final product move. - Instead of showing the selected failure location, the system displayed another location as the move destination after completing the repair process. Steps to reproduce: ------------------------- 1. Install the quality_repair module. 2. In Quality, create a Control Point with: - Type = Pass-Fail - Control Per = Product or Operation - Set at least 1 Failure Location 3. Create a Repair Order for any product and start the repair process. 4. Perform a quality check, set it to Fail, and select a failure location. 5. Open the product moves, the destination location does not match the selected failure location. Cause of the issue: ------------------------- The failure location was not correctly assigned when a quality check failed during the repair process because _move_to_failure_location determines the destination location based on a stock picking (for receipts) or a production_id (for manufacturing). In the Repair module, however, quality checks are linked to a repair order, so the selected failure location was not set correctly. After this commit: ----------------------- - When a quality check fails in a repair order, the product’s destination location is correctly set to the failure location selected by the user. - This ensures that, upon completion of the repair, the product is moved to the selected failure location, maintaining accurate inventory tracking and management. Task ID:5254334 Forward-Port-Of: odoo/enterprise#99235
This update resolves a crash issue when opening tax reports without a linked return type. The system now automatically falls back to the company's tax periodicity, ensuring reports open reliably. This improves the overall stability and usability of our tax reporting functionality.
Original PR description
When a report uses 'previous_return_period' date_scope on one of its expressions, if there's no account.return.type linked to that report, the opening of the report crashes. This is a bit stupid,…
When a report uses 'previous_return_period' date_scope on one of its expressions, if there's no account.return.type linked to that report, the opening of the report crashes. This is a bit stupid, since a return type without periodicity will anyway fallback to the the company's tax periodicity field. When there's no return type, we should simply fallback in the same way. To reproduce: - Make a Belgian company, install the CoA and localization - Manually uninstall l10n_be_reports - Try opening the tax report Another message also checked that we couldn't compute this date_scope in case there was more than one return type linked to the report, arguing they have different periodicities, so we can't infer which one to use. However, it they actually shared the same periodicity, that check failed anyway. We refine it to authorize this case, and only raise if they truly have different periodicities. opw-6022150 Forward-Port-Of: odoo/enterprise#111872 Forward-Port-Of: odoo/enterprise#111796
This update resolves a recurring issue where the Italian POS printer experienced errors when offline. The fix adds a safety mechanism to gracefully handle network disruptions during receipt printing, preventing tracebacks and ensuring smoother operation for users. This improves the reliability of the Italian POS system.
Original PR description
When loosing internet connexion a lot of tracebacks appear is the pos if we use the italian fiscal printer. Steps to reproduce: ------------------- * Setup italian fiscal printer for a shop * Open shop * Turn wi-fi off * Add items to cart * Go to payment screen > Traceback * Add a payment and validate > Traceback Why the fix: ------------ Don't try to reach the printer if we're offline regarding the price to pay. We add a try catch block around the call for printing the receipt. If the try block fails when the network is offline we assume it's just because of the offline mode. If it failed while online we raise the error. opw-5432090 Forward-Port-Of: odoo/enterprise#112076 Forward-Port-Of: odoo/enterprise#105515
This update fixes a potential issue where automated email systems (Mail Defender) could unintentionally cancel or reschedule appointments. The system now uses a form instead of a direct link, preventing these automated actions. This ensures appointments are handled correctly and reliably.
Original PR description
…ointments Mail defender services may click URLs in emails to verify their contents. Additionally they may sometimes interact with the page and visit related pages. For this reason URLs sent in emails should not trigger any action directly nor contain any simple link that could trigger an action. The "cancel/reschedule" anchor URL is replaced with a form which bots should not click. We also port the fix done in appointment to the view in appointment as it replaces the original view in this module. task-4555579 Forward-Port-Of: odoo/enterprise#112202 Forward-Port-Of: odoo/enterprise#79831
This update resolves issues causing warnings and tracebacks in several Odoo reports. By correcting how report parameters are defined, the system now handles warnings correctly, preventing errors and ensuring consistent report data. This improves the reliability and accuracy of key financial and tax reports.
Original PR description
Following odoo/enterprise#110087, `this.` was added before the warningParams, however it's defined in the ctx using t-set resulting in undefined values in a lot of reports. In the worst case, a traceback could occur when the report loaded like in l10n_lu_reports and the best case, the warning would just be missing (which isn't blocking but is wrong). The params to reportAction could also be set to undefined like in account_intrastat.
This update fixes an issue where archived employee versions were incorrectly appearing in payroll pay run reports. The change filters out archived employees from the domain, ensuring that only active employees are included in pay run calculations. This prevents inaccurate payroll reporting and maintains data integrity.
Original PR description
Steps to reproduce: 1. Create an employee with a contract for this month 2. Archive the employee (but not the version) 3. Create a pay run 4. The employee's version will appear in the list Cause: The domain takes versions for archived employees. Fix: Add active_employee in the domain. Task: 6022437 Forward-Port-Of: odoo/enterprise#110709 Forward-Port-Of: odoo/enterprise#110073
This update clarifies the error message displayed when an upsell start date is set too close to the next invoice date. This change ensures users receive clearer guidance, preventing potential issues with subscription setup and improving the overall user experience. It's a simple fix to enhance usability.
Original PR description
Update the error message when an upsell start date is on or after the next invoice date, so it be more clear for the users. task-5893032 Forward-Port-Of: odoo/enterprise#106757
This update fixes a calculation error related to paid leave time off, specifically for employees using the UAE Monthly pay structure. The change ensures that hourly wage calculations are accurate, preventing incorrect salary adjustments when computing payslips, particularly when multiple payslips are involved.
Original PR description
### Steps to reproduce: - Install the l10n_ae_hr_payroll module. - Configure at least two employees, who'll use the UAE Monthly pay structure. - On at least one of the employees, set the work entry…
### Steps to reproduce: - Install the l10n_ae_hr_payroll module. - Configure at least two employees, who'll use the UAE Monthly pay structure. - On at least one of the employees, set the work entry source to attendance. - Register a paid leave time off entry, for the employee whose work entry source is set to attendance. - Compute a payslip batch using the UAE Monthly pay structure. - Go to the payslip of the employee with the work entry source set to attendance and compute the sheet again. - The 'Paid Leave' salary rule results, will change given that the computation of the field l10n_ae_hourly_wage is different when the computation is done for batches and individually. ### Cause: In 'Paid Leave' rule we use l10n_ae_hourly_wage to compute its result and while computing this field we use self.worked_days_line_ids instead of record inside the loop. This leads to an issue when self has more than one payslip it will take into account all the worked days for each payslip for different employees ### Fix: We use record instead of self to avoid taking other payslips into consideration while computing the hourly wage. opw-5979631 Forward-Port-Of: odoo/enterprise#112229 Forward-Port-Of: odoo/enterprise#111280
This update fixes an issue where long product names in the Master Production Schedule would cause other schedule columns to disappear. The fix wraps long text within product names to ensure the entire schedule remains visible and functional. This improves the usability of the production planning tool.
Original PR description
Problem: In the master production schedule, if a product on the schedule has a name that would extend to the right edge of the screen, all of the other colums for the schedule will be completely hidden. Solution: We will wrap the text in the <a> tag containing the product name. Steps to Replicate (Runbot v19): 1. Open the Master Production Schedule 2. Click the pencil on one of the products 3. Click into the product and change its name to be something very, very long 4. Navigate back to the MPS and notice that you cannot see the actual schedule elements, even if you scroll to the end. opw-6066088 Forward-Port-Of: odoo/enterprise#112386 Forward-Port-Of: odoo/enterprise#111896
This update resolves an issue where night shift slots (e.g., 20PM - 4AM) were not visible in the weekly planning view. The fix adjusts how the system displays multi-day slots, ensuring all scheduled hours are accurately shown. This improves the planning experience for employees with flexible work arrangements.
Original PR description
**Steps to reproduce** 1. Have an employee using a flexible schedule 2. Create a slot from e.g. 20PM to 4AM for this employee. Make sure this is the only slot that week for the employee. 3. Publish…
**Steps to reproduce** 1. Have an employee using a flexible schedule 2. Create a slot from e.g. 20PM to 4AM for this employee. Make sure this is the only slot that week for the employee. 3. Publish the Schedule and send it to the employee. Open the outgoing mail to access the link to the planning view. Issue: the slot is not visible in the week view. **Cause** https://github.com/odoo/enterprise/blob/04a885dbb6eed96297cb5ce9a155ebf8e169427c/planning/controllers/main.py#L193-L194 The `event_hour_min` and `event_hour_max` returned by `planning_get` and used to control the min/max hours displayed in the week view, didn't account for slots over multiple days. For a slot between 20pm and 4am, the `event_hour_max` should be the end of the day, and the `event_hour_min` should be the start of the day. **Solution** - we change the `event_hour_min` and `event_hour_max` for multi-day slots to display the full days in the week view - the previous point has the drawback of displaying the full days for non-flexible employees even when not necessary. This is because `slots_start_datetime` and `slots_end_datetime` contained the `planning.slot` start and end. Instead, we can look at the actual slot values displayed (by `_get_slots_vals`). For example, a 5 day slot for a non-flexible employee may contain actual slot values corresponding to a typical 8-17 working day. opw-5245985 Forward-Port-Of: odoo/enterprise#111876 Forward-Port-Of: odoo/enterprise#99784
This update resolves an issue where the system incorrectly identified Swift accounts due to changes in Wise's API. By handling both 'swift_code' and 'SwiftCode' variations, the system now reliably processes direct deposit payments, preventing errors and ensuring accurate account identification.
Original PR description
Internally, Wise has changed their return value of their API to sometimes return `swift_code` and other times return `SwiftCode` depending on the create time of the recipient account. If the account is older than a few months it will use `SwiftCode` as the return value of GET /v2/accounts when they are created with type `swift_code` in the POST. As such, to be defensive this code handles both cases to not make any assumptions in case users have old or new accounts. This stops a traceback where the system doesn't think it's a swift account and tries to access abartn even though it doesn't exists. task-6070033 Forward-Port-Of: odoo/enterprise#112075
9 changes
Resolved issues and error corrections
This pull request fixes inaccuracies in the PEPOL XML files generated for Peru (l10n_pe_edi). Specifically, it adjusts the number of digits used for unit prices and multiplier factors to ensure accurate calculations, resolving discrepancies in tax amounts. This improves the reliability of financial reporting.
Original PR description
PR https://github.com/odoo/odoo/pull/255358 introduce a fix that increase the unit price number of digits in the peppol xml if they are significants. It also increases the precision for MultiplierFactorNumeric, which fixes some xml in l10n_pe_edi. For example, previously: MultiplierFactorNumeric = 0.00965 BaseAmount = 10097.46 Amount = 97.46 But `0.00965 * 10097.46 = 97.440489 ≃ 97.44 != 97.46` Now we have multiplierFactorNumeric = 0.00965193227 `0.00965193227 * 10097.46 = 97.4600000190342 ≃ 97.46` Overall, we are more precise, which means the computation are correct now. opw-6009771
A recent update caused long partner names in approval reports to overflow, making the reports visually unreadable. This fix adds a column limit to the partner field in the report, ensuring all data is displayed correctly and preventing formatting issues. This improves the report's usability and data clarity.
Original PR description
step to reproduce: - install "approval" with demo data - have a partner with name length > 63 - open one of the approvals and change its type to "general approval" - add this partner in contact field - print approval request report Observation: - the partner overflows out of report Fix: - we limit the partner field with `col-9`. For a safe measure i have added `col-9` for `request_owner_id` and `approver_ids` **Before** <img width="1057" height="326" alt="image" src="https://github.com/user-attachments/assets/a8eea789-5cc7-4658-88b5-78751759d043" /> **After** <img width="994" height="330" alt="image" src="https://github.com/user-attachments/assets/bfbc061b-a6e0-4593-a3cc-c85cb81db6e2" /> opw-6005752 Forward-Port-Of: odoo/enterprise#111130
This update corrects a bug where planning slots were incorrectly created for rental orders, even when 'Plan Services' was disabled. The fix ensures that slots are only generated when 'Plan Services' is enabled, streamlining the rental planning process and preventing potential confusion. This change improves the accuracy of rental order planning.
Original PR description
Steps to reproduce: ------------------- 1. Install `sale_renting_planning`. 2. Create a rental service product with: - "Can be Sold" enabled - "Plan Services" disabled - UoM set to "Units" 3. Create and confirm a rental order with this product. 4. Go to Planning and check for slots related to this order. (no slots at this stage) 5. Update the quantity of the rental order. 6. Check Planning again for slots related to this order. Issue: ------ Planning slots are created after updating the quantity of the sale order, even when "Plan Services" is not enabled. Cause: ------ Slot records are created without checking whether "Plan Services" is enabled, which leads to unwanted planning entries. related commit: 74eef70 Solution: --------- Add a condition to ensure planning slots are created only when "Plan Services" is enabled. opw-6051012 Forward-Port-Of: odoo/enterprise#112278
This update resolves an issue where users without write access to the Point of Sale (PoS) in the AT (Austria) version of Fiskaly would receive an access error when attempting to authenticate after a token expiration. The fix ensures that access errors are handled correctly, preventing disruptions to sales transactions for our AT customers.
Original PR description
When trying to auth directly from the PoS when the token expires, if you are logged in with a user that doesn't have write access to the PoS. You would get an access error. Steps to reproduce: ------------------- * Setup Fiskaly in an AT company * Open PoS and try to make a sale * To fake the token expiration I modified the code so that the request always return 401 status code > Observation: You get an access error opw-5925203
This update resolves an issue where kitchen tickets were being printed multiple times when orders were rejected. The fix prevents duplicate printing by ensuring the print token is properly managed during order rejection, improving the reliability of order processing. Preparation messages are now correctly sent after order acceptance.
Original PR description
Bug fix: - Prevent duplicate kitchen ticket printing on order rejection. When a user rejects an order, the reject RPC triggers a webhook that calls _fetchPlatformOrder on all devices. This led to deleteOrders being called twice (once by the reject flow, once by the webhook). Fix: claim the print token via mark_platform_prep_order_as_printed in _rejectOrder before sending the reject RPC, so no device gets isReadyToPrint=true from the webhook. - Preparation needs to be sent after PoS accepts the order. ticket-6071740
This update resolves an inconsistency in the tax report when creating vendor bills with mixed vehicle and non-vehicle expense lines. The fix allows for accurate reporting by relaxing a strict matching rule for vehicle IDs, ensuring shared tax lines are correctly processed regardless of whether a vehicle is assigned. This improves the reliability of financial reporting.
Original PR description
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other…
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other without a vehicle. * Confirm the vendor bill. * Go to **Accounting > Reporting > Tax Report** and Go to `Account > Tax` report. **Observed behavior:** * The tax report shows: 'This report contains inconsistencies. The affected lines are marked with a warning.' **Cause:** * The `_get_extra_query_base_tax_line_mapping()` override forced vehicle_id matching using `COALESCE(base_line.vehicle_id, 0) = COALESCE(account_move_line.vehicle_id, 0)`. * When lines share a tax but have different vehicle_id values (one set, one NULL), Odoo creates a single tax line with `vehicle_id = NULL`. * The strict COALESCE constraint prevented this tax line from matching either base line (NULL ≠ vehicle_id and NULL ≠ NULL when coalesced to 0), causing the inconsistency. **Fix:** * Changed the constraint to only enforce vehicle_id matching when both the base line and tax line have a vehicle_id set. * If either side is NULL, the match is allowed, letting shared tax lines work correctly across mixed vehicle/non-vehicle expense lines. opw-5956645 Forward-Port-Of: odoo/enterprise#112313 Forward-Port-Of: odoo/enterprise#110616
This update strengthens security by adding validation when bank statements are automatically synchronized with a journal. Previously, any bank account linked to a journal using online synchronization was automatically trusted. Now, the system will validate the bank account to improve data integrity and reduce potential risks.
Original PR description
When a journal is configured to register bank statements using online synchronization, the bank account linked to the bank journal is automatically trusted. task-6017819
This update fixes an issue related to how dates and times are displayed, specifically the inclusion of seconds. The change restores the previous behavior of showing seconds when desired, and clarifies the datetime format system. This ensures consistent and accurate time formatting across Odoo.
Original PR description
In this [commit] the short format has been removed from misc methods because there was no more _short format fields in res.lang. But the short format was used to remove seconds from the res.lang format. Now, this behaviour has been restored with the new datetime format system and the unused format 'long' and 'full' has been removed from the doc string to avoid misunderstanding. The formatDateTime from the JS use the format from the res.lang too. So the same behaviour has been implemented there to be able to show seconds through the option 'showSeconds'. It's also fix the fact that this option didn't have any effect when the datetime was shown in numeric mode. [commit]: odoo/odoo@062b140 opw-6030342
This update fixes an issue where tax returns for Italian companies incorrectly included pension fund taxes, leading to discrepancies between reports and the backend view. The change excludes these taxes from the tax return calculation, ensuring accurate reporting and alignment with customer data. This resolves a previous inconsistency impacting financial reporting.
Original PR description
The "amount to pay" incorrectly included the Pension Fund taxes, causing inconsistencies between the report and what the customer was able to see in the backend. Now we exclude them from the tax return domain. Steps to reproduce: - Create an Italian company with the Italian CoA - Install `l10n_it_edi_withholding` (not necessary in v19) - Create an invoice - Set the 4% INPS or 4% F.Pens taxes on a line, along with with a normal 22% VAT - Create a tax return Ticket [link](https://www.odoo.com/odoo/project.task/5909407) opw-5909407 Forward-Port-Of: odoo/enterprise#111311
4 changes
Resolved issues and error corrections
This update ensures that payment references are automatically updated when an invoice name is changed, improving invoice tracking and reconciliation. Currently, only the invoice name was updated, but this fix synchronizes the payment reference and related account move lines for accurate payment processing. This resolves an issue where payment details weren't consistently reflecting name changes.
Original PR description
Issue: Updating the invoice name should update the payment reference if the invoice isn't already sent. Step to reproduce: - Create an invoice, - Post it, - Draft it, - Change name, - Post it again, Current behavior: only the invoice name change Expected behavior: - invoice name change - payment_reference update - linked account_move_line labeled payment_term are updated as payment_term _inverse_payment_reference trigger a recompute of the right account move line name. opw-5428471
This update resolves a test failure related to the calculation of AVS deductions in the Swiss payroll module. The issue stemmed from an incorrect date calculation within the test environment, specifically when simulating data from 2027. The fix uses a temporary date freeze to ensure consistent test results.
Original PR description
[FIX] l10n_ch_hr_payroll_elm_transmission: fix avs test for faketime build
Bug reproduction:
1 - v.17->run test_generic_avs_deductions test with faketime 2027-01-01 12:00 UTC->test fails
Bug cause:
1 - In the test, compute_sheet()->_get_payslip_lines->_compute_rule->_get_avs_rates is called
2 - There is a line like that if line.date_from <= target and (not line.date_to or target <= line.date_to)
3 - I looked to avs_line_ids = fields.One2many(default=_get_default_avs_line_ids)
4 - In _get_default_avs_line_ids -> 'date_from': fields.Date.today().replace(month=1, day=1) date_from is calculated like that -> when the year is 2027, the date_from is 2027-01-01 and it is bigger than the target in the test.
Bug solution:
1 - I used @freeze_time("2026-02-28") in my test to prevent this behavior.
Runbot Error Link: https://runbot.odoo.com/odoo/runbot.build.error/240992
task - 6018940
Forward-Port-Of: odoo/enterprise#109975This update optimizes the process of validating purchase orders with related stock movements, significantly reducing database load and improving speed. Previously, each stock movement triggered multiple database operations, now a single batch process handles all movements, resulting in faster order validation, especially for large orders.
Original PR description
Before this PR, `button_validate` was using a `write()` call per matched stock move. On every `write()` there is a Command.create and Command.delete which is resulting in N database round-trips for the unlinks and N for the creates, followed by N separate `_apply_putaway_strategy()` calls. This is problematic for pickings with many move_ids. This PR attempts to accumulates all move lines to delete and to create. Then performs a single `unlink()` and `create()`, followed by a single `_apply_putaway_strategy()` for all pickings. Unlink is done using `.sudo()` to preserve the superuser context that was previously inherited implicitly through the `purchase_order.sudo().search` that produced the recordset used to obtain the `receipt_move`(s). Benchmarks: | No. move lines in delivery | Before | After | | -------------------------- | ------- | ----- | | 7579 | Timeout | < 200 s | opw-5826905 Forward-Port-Of: odoo/enterprise#110153
This update clarifies the error message displayed when an upsell start date is set after the next invoice date. This change ensures users receive clearer guidance, preventing potential issues with subscription setup and improving the overall user experience. It's a simple fix to enhance usability.
Original PR description
Update the error message when an upsell start date is on or after the next invoice date, so it be more clear for the users. task-5893032 Forward-Port-Of: odoo/enterprise#106757