Daily updates from Odoo
Friday, March 27, 2026
258 changes
11 changes
Resolved issues and error corrections
This update corrects a bug where payments for invoices paid within 30 days (PUE) were incorrectly sent to the Mexican tax authority (CFDI). The fix disables a feature that allowed this, ensuring accurate tax reporting and compliance. This resolves an issue impacting Mexican businesses using Odoo.
Original PR description
Issue: Sending PUE payments to CFDI/SAT is no more suitable Step to reproduce: - In a Mexican company - Create an invoice (Invoice A) - Add a line - Set Payment Terms to "Immediate payment" - Confirm…
Issue: Sending PUE payments to CFDI/SAT is no more suitable Step to reproduce: - In a Mexican company - Create an invoice (Invoice A) - Add a line - Set Payment Terms to "Immediate payment" - Confirm - Duplicate (Invoice B) - Confirm - Duplicate again (Invoice C) - Set Payment Terms to "30 days" - Confirm - Go to Invoice A - Pay it. It should appear as "Paid" - Send it to CFDI - Go to Accounting > Customer > Invoices - Select Invoice B and C - Pay and select the "Group Payments". They should appear as paid. - In every invoice, click the "Update Payment" button Current behavior: - In Invoice A -> Sheet CFDI: A button "Force CFDI" allow sending the payment to CFDI - In Invoice B/C -> sheet CFDI: Click on the "Download" part of the Payment line, the XML that was sent to CFDI include both invoice B and C Expected behavior: - It shouldn't be possible to send payment for invoice A to CFDI. - Payment for invoice B shouldn't be sent to CFDI Cause: Payment for invoice paid in less than 30 days, referred as PUE, shouldn't be sent to CFDI. Solution: Disable the force sending to CFDI About tests: l10n_mx_edi_cfdi_invoice_try_update_payments already send payment to CFDI for PPD invoices. Calling action_force_payment_cfdi was pointless and causing a mess. opw-5381600 Forward-Port-Of: odoo/enterprise#109429 Forward-Port-Of: odoo/enterprise#104628
This update corrects a bug where report exports were incorrectly using previous months instead of the specified dates. The fix ensures that explicit date ranges take priority, preventing date shifts and guaranteeing accurate report data. This improves the reliability of financial reporting.
Original PR description
Description of the issue this commit addresses: Happens since https://github.com/odoo/enterprise/commit/40484f985f511edd7ba2ae759ce63ef564bcf1f7 When rebuilding report options, _init_options_date…
Description of the issue this commit addresses: Happens since https://github.com/odoo/enterprise/commit/40484f985f511edd7ba2ae759ce63ef564bcf1f7 When rebuilding report options, _init_options_date applies the default_opening_date even when explicit date_from/date_to are provided. This can trigger an unintended shift (e.g. previous_month), causing exports to use incorrect periods. ---- Steps to reproduce (exemple among many more): 1. Install l10n_nl_reports and go on the NL Company. 2. Create an invoice for a belgian partner in February. 3. Go to the EC Sales List report and select february 1st to 28/29. 4. Export for XBRL (cog icon) and download file. Invoice values are not in. 5. When debugging the export, you can see the exported dates are January. ---- Desired behavior after this commit is merged: This commit ensures explicit dates take precedence by inferring the period_type instead of applying default_opening_date, preventing unexpected date shifts during export and preserving the selected period. ---- task-6065382
This update resolves an issue where the Dutch EC Sales (ICP) report was incorrectly exporting data using a previous month's date. The fix ensures that specified export dates are respected, accurately aligning the exported data with the selected reporting period and preventing data discrepancies. This improves the reliability of the ICP export process.
Original PR description
Description of the issue this commit addresses: Since Faulty Commit[^1], rebuilding report options may apply default_opening_date even when explicit date_from/date_to are provided. This causes ICP export to shift the period (e.g. Feb → Jan), resulting in empty or incorrect exported data. [^1]: https://github.com/odoo/enterprise/commit/40484f985f511edd7ba2ae759ce63ef564bcf1f7 --- Steps to reproduce: 1. Create an invoice in February 2. Open the Dutch EC Sales (ICP) report for February 3. Export via XBRL wizard 4. Observe that export uses January instead of February --- Desired behavior after this commit is merged: This commit ensures explicit export dates are respected by passing period_type='custom', preventing unintended shifts and aligning the exported data with the selected report period. --- task-6065382
This update resolves an error that occurred when users removed the interval setting from expense cards. The fix ensures the system defaults to 'all_time' when no interval is specified, preventing a KeyError and ensuring the expense card functionality continues to work correctly. This improves the user experience and data integrity.
Original PR description
Currently, an error occurs when the user removes the interval from the expense card. **Steps to Reproduce:** - Install the `hr_expense_stripe` module. - Go to `Expenses` > `Cards`. - Click `New` and remove the `interval value (All Time)`. `KeyError: False` When the user removes the interval, the system attempts to access the interval from `interval_multiplier_map`. However, since the interval becomes False, it raises a KeyError at [1]. This commit ensures that when no interval is set, the system defaults to `all_time` as the interval, since `all_time` is ignored as the default value. [1]:- https://github.com/odoo/enterprise/blob/06be616bb4d74f0a089e8e318d25c2424594f813/hr_expense_stripe/models/hr_expense_stripe_card.py#L287 Forward-Port-Of: odoo/enterprise#110639
This update removes a redundant icon path from the l10n_tw_reports module. This streamlining simplifies the module's configuration and improves its performance. The change ensures a cleaner and more efficient reporting experience for users in Taiwan.
Original PR description
Remove the hardcoded icon path from the manifest. Task-6007589 CE PR: https://github.com/odoo/odoo/pull/254826 Forward-Port-Of: odoo/enterprise#112207 Forward-Port-Of: odoo/enterprise#111264
This update resolves a technical problem in the Odoo Enterprise payroll accounting module. A test was failing due to relying on non-existent data records, which has now been corrected by directly defining the necessary account information within the test itself. This ensures the test runs reliably and accurately.
Original PR description
The test that was introduced in the following PR (https://github.com/odoo/enterprise/pull/111140), under some circumstances, was causing problems due to some records not being present. Indeed it was bad practice to use records not defined in the test, so we fix it here by defining the analytic accounts and their plan directly in the test instead of searching for them. Runbot Error: 242151 Forward-Port-Of: odoo/enterprise#112134
A recent test was failing intermittently because the system wasn't consistently loading all relevant partner data due to a limit on the number of users loaded. This fix increases the loading limit to ensure the correct partner is always available during testing, preventing test failures. This improves the reliability of our POS settlement testing process.
Original PR description
In the test, test_pos_settle_due_with_rounding, the partner that we want to check was sometimes not loaded in the frontend due to the default limit of 100 users loaded. Those users are loaded by priority of number of orders and then name. In the test, no order has been made before so we only check the alphabetical order of the names and the partner we want to check is not always in the first 100. In the fix, we change the limits to a very big number to be sure that the partner is loaded. runbot-error: 241039 Forward-Port-Of: odoo/enterprise#110130
This update resolves an issue where discounts weren't correctly applied in the self-order point-of-sale flow. The fix ensures that discount information is properly passed through the system, preventing errors and guaranteeing accurate discount calculations. This improves the reliability of the self-order functionality.
Original PR description
In the pos self-order flow, `_check_pos_order_lines` does not forward the `discount` field when sanitizing order lines. This caused `_merge_order_lines` to raise a `KeyError` when using `itemgetter('discount')` on lines that lack the key.
opw-6052719
Forward-Port-Of: odoo/enterprise#111591This update fixes an issue where audit reports in the Denmark localization were incorrectly displaying global account reports instead of the Denmark-specific versions. The change ensures that embedded account reports, like the Balance Sheet, now accurately reflect the company settings of the audit report, improving reporting accuracy for Danish users.
Original PR description
Currently, when creating an audit report, the system does not use the audit report's company when generating the options for the account reports embedded in the new articles. As a result, the system may not load the account report variant that is specific to the audit report's company. Steps to reproduce: 1. Install the Denmark localization module (`l10n_dk`) 2. Switch to the Denmark company using the navbar 3. Create an audit report 4. Open the article "Balance Sheet" of your report 5. Open the embedded account report of that article => The system opens the global balance sheet. **TO BE**: it should open the balance sheet that is specific to the Denmark. To fix the issue, we will set the company to use when generating the account report options via the context and the `forced_companies` option. These changes should ensure that the account reports embedded in the articles load the right variants. Task-5901886 Forward-Port-Of: odoo/enterprise#101377
This update fixes a display issue in the external value pop-up, ensuring it uses the correct decimal separator based on the user's language settings. Previously, the pop-up always used a dot, which could cause confusion for users in regions that use a comma as a decimal separator. This change improves the user experience and data accuracy.
Original PR description
Description of the issue this commit addresses: The external value pop up doesn't take into account the locale to chose which decimal separator to use. --- Desired behavior after this commit is merged: The decimal separator is the one determined by the language of the user rather than always a dot. --- task-6010533 Forward-Port-Of: odoo/enterprise#111997 Forward-Port-Of: odoo/enterprise#109948
This update fixes a minor issue that prevented users from successfully updating timesheet entries while a timer was running. The fix ensures that the system handles urgent saves properly, preventing an error that would disrupt the timesheet update process. This improves the reliability of timesheet management.
Original PR description
Steps to reproduce: 1. Install `timesheet_grid` 2. Open timesheet and start timer 3. Update any cell by clicking on seach icon. 4. Now after updating go back by clicking "My Timesheet" breadcrumb Issue: - Tracback: `Uncaught Promise > Cannot convert undefined or null to object` Cause: : - The error was occurring because the updateTimerState function in timesheet_timer_service.js was trying to iterate over timerState.data when it was undefined or null. This happens when the list view's urgent save is triggered. Solution: - added a safeguard to updateTimerState so that it simply returns early if timerState.data is empty opw-6018970 Forward-Port-Of: odoo/enterprise#110637
9 changes
Resolved issues and error corrections
This update corrects an issue where searching for deliveries solely by zip code resulted in inaccurate location suggestions. The fix ensures that the city field is properly populated when a zip code is provided, allowing Sendcloud to correctly identify the delivery location. This improves the reliability of our website's delivery options.
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 prevents a system error that occurred when users removed the interval setting from expense cards. The fix ensures the system defaults to 'all_time' when no interval is specified, improving the user experience and preventing data inconsistencies. This resolves a technical issue impacting expense reporting.
Original PR description
Currently, an error occurs when the user removes the interval from the expense card. **Steps to Reproduce:** - Install the `hr_expense_stripe` module. - Go to `Expenses` > `Cards`. - Click `New` and remove the `interval value (All Time)`. `KeyError: False` When the user removes the interval, the system attempts to access the interval from `interval_multiplier_map`. However, since the interval becomes False, it raises a KeyError at [1]. This commit ensures that when no interval is set, the system defaults to `all_time` as the interval, since `all_time` is ignored as the default value. [1]:- https://github.com/odoo/enterprise/blob/06be616bb4d74f0a089e8e318d25c2424594f813/hr_expense_stripe/models/hr_expense_stripe_card.py#L287 Forward-Port-Of: odoo/enterprise#110639
This update fixes a bug where flexible schedules with different time zones were incorrectly displaying an inflated expected hour count (48 hours instead of 40). The fix ensures accurate hour calculations by properly accounting for time zone differences, preventing incorrect hour displays in the Attendances app.
Original PR description
__ ## Short functional explanation of the error When the time zone of an employee's schedule is different from the employee's time zone, and that the employee's time zone has more than 9 hours of…
__ ## Short functional explanation of the error When the time zone of an employee's schedule is different from the employee's time zone, and that the employee's time zone has more than 9 hours of difference with UTC. The schedule is flexible and is set to 40 hours per week. When we open the Attendances app, the expected hours for this employee show 48. ## Reproduction Steps 1. Create an employee. The time zone of the employee should be different from the one on his work schedule. To be sure to replicate the bug, set the time zone of employee's time zone to Pyongyang. 2. Open the work schedule and set it to Flexible. Set the weekly hours to 40, and the full time equivalent to 40. Set the work schedule to Europe/Brussels time. 3. Open Attendances. ### Expected behavior When we hover the name of our employee, we can see in white on green background 0/40h. ### Unexpected behavior Instead, we see 0/48h. ## Origin of the issue This line: https://github.com/odoo/odoo/blob/e49536031f61b90212eb6f0d1a8a3e15927e723d/addons/resource/models/resource_calendar.py#L419 is used to retrieve the correct date. We assume that `end_datetime` will be set at midnight, so subtracting one second gives us the day before, allowing us to ignore the date of `end_dt`, for which we don't need to compute the intervals. However, this doesn't take into account different time zones. Indeed, we compute `end_datetime_adjusted` from `end_datetime`, which has the user timezone, and not UTC, as defined here: https://github.com/odoo/odoo/blob/e49536031f61b90212eb6f0d1a8a3e15927e723d/addons/resource/models/resource_calendar.py#L402 As a result, if we set the user timezone to Pyongyang, `end_datetime` will be set at 8am, and `end_datetime_adjusted` will lead to the same date, instead of a day before. Hence, we would compute an additional interval for an additional day, which would in the end give us 48 hours expected instead of the 40 hours indicated in the contract. Therefore, we have to take into account the time zones, hours, minutes and seconds when checking the start and end dates. __ opw-5937298 Forward-Port-Of: odoo/enterprise#110011
This update resolves a technical problem in the Odoo Enterprise payroll analytics testing process. The previous test was failing due to relying on test data that wasn't consistently available. The fix ensures the test uses defined analytic accounts, improving the reliability of the payroll reporting.
Original PR description
The test that was introduced in the following PR (https://github.com/odoo/enterprise/pull/111140), under some circumstances, was causing problems due to some records not being present. Indeed it was bad practice to use records not defined in the test, so we fix it here by defining the analytic accounts and their plan directly in the test instead of searching for them. Runbot Error: 242151 Forward-Port-Of: odoo/enterprise#112134
This update resolves an issue where the Customer Ratings reporting form in Helpdesk displayed a duplicate 'Comment' field. The fix made the redundant 'publisher_comment' field invisible, streamlining the form and improving data clarity. This ensures a consistent and accurate user experience.
Original PR description
**Steps to reproduce:** - Go to helpdesk > Reporting > Customer Ratings. - Open any rating record. - Observe that the 'Comment' field is displayed twice. **Issue:** - The form view contains a two different field with same string i.e feedback and publisher_comment **Fix:** - Made the publisher_comment field invisible in helpdesk's customer rating **Task-id: 5359052** Forward-Port-Of: odoo/enterprise#100823
This update resolves an issue where users with limited access (Invoicing Users) were encountering errors when validating invoices while audit reports were present. The fix ensures proper invoice validation functionality without requiring additional user permissions, improving usability for all users.
Original PR description
An issue occurs when an Invoicing User tries to validate a bill while an audit report exists, resulting in an access error because the user does not have permission to access account.report. Steps to reproduce: - Create an audit report for the current year - Create a user with only the “Accounting / Invoicing” access - Log in with this user and attempt to validate a bill, the access error appears on account.report since only Bookkeeper, Invoicing & Banks and Read-only accounting group has access to return. This fix ensures the validation works correctly without requiring extra access. opw-6049259 Forward-Port-Of: odoo/enterprise#111782
This update resolves a recurring error that occurred when the POS system in Italy (l10n_it_pos) lost its internet connection. By adding a safety mechanism to handle offline printing attempts, the system now gracefully manages errors instead of crashing, ensuring smoother transactions for Italian retailers.
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#111487 Forward-Port-Of: odoo/enterprise#105515
This update resolves an issue where discounts weren't correctly processed in the self-order point-of-sale flow. The fix ensures that discount information is properly handled, preventing errors and ensuring accurate order totals. This improves the reliability of the self-order functionality.
Original PR description
In the pos self-order flow, `_check_pos_order_lines` does not forward the `discount` field when sanitizing order lines. This caused `_merge_order_lines` to raise a `KeyError` when using `itemgetter('discount')` on lines that lack the key.
opw-6052719
Forward-Port-Of: odoo/enterprise#111591This update fixes an issue where audit reports weren't using the correct company-specific account report variants. Now, when creating an audit report in the Denmark localization, the system will automatically load the correct balance sheet report, ensuring accurate financial reporting for Danish businesses. This improves the reliability of financial data generated within the system.
Original PR description
Currently, when creating an audit report, the system does not use the audit report's company when generating the options for the account reports embedded in the new articles. As a result, the system may not load the account report variant that is specific to the audit report's company. Steps to reproduce: 1. Install the Denmark localization module (`l10n_dk`) 2. Switch to the Denmark company using the navbar 3. Create an audit report 4. Open the article "Balance Sheet" of your report 5. Open the embedded account report of that article => The system opens the global balance sheet. **TO BE**: it should open the balance sheet that is specific to the Denmark. To fix the issue, we will set the company to use when generating the account report options via the context and the `forced_companies` option. These changes should ensure that the account reports embedded in the articles load the right variants. Task-5901886 Forward-Port-Of: odoo/enterprise#101377
14 changes
Resolved issues and error corrections
This update fixes an issue where the delivered quantity on sale orders wasn't accurately reflecting dropship deliveries between companies. The fix ensures that dropship moves are correctly accounted for in the delivery calculations, resolving a discrepancy where the quantity delivered was incorrectly shown as zero.
Original PR description
**Steps to reproduce:** - Make sure you have 3 companies (comp A, B and C) - Navigate to Settings/Users & Companies/ Companies - for each company in the 'Inter Company Transactions' tab: check…
**Steps to reproduce:** - Make sure you have 3 companies (comp A, B and C) - Navigate to Settings/Users & Companies/ Companies - for each company in the 'Inter Company Transactions' tab: check 'generate Sale Orders', 'generate purchase orders' and 'synchronize Deliveries to your receipts' then select a warehouse and a receipt operation type From company A - create a storable product - in the Purchase tab, set the company B as a vendor From company B - in the Purchase tab of the product, set company C as a vendor From company C - set a positive on hand quantity From Company A - create a SO for 1 quantity of your product - on the sale order line, unhide de route_id column and set it to dropship - confirm the SO and the linked PO From company B - on the SO created with company A as customer (you might need to remove the 'my quotations filter to find it), set the dropship route in the route_id column of the sale order line - confirm the SO and the linked PO From company C - confirm SO created with company B as customer - validate the delivery From company B - validate the dropship **Current behavior:** the quantity delivered on the sale order line is 0 **Expected behavior:** it should be 1 **Cause of the issue:** inside _compute_qty_delivered, we fetch the incoming and outgoing moves using _get_outgoing_incoming_moves() https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/sale_stock/models/sale_order_line.py#L200 There, for the move of the dropship picking, inside the if condition, move._is_dropshipped_returned() will be True https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/sale_stock/models/sale_order_line.py#L348-L354 That's because the move is going from transit to transit https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/stock_account/models/stock_move.py#L186-L195 So it will not be added to the outgoing moves and qty_delivered will stay 0. **fix** is_dropshipped_returned should not prevent the move to be added to the outgoing moves if is_dropshipped() is aslo true (i.e. it's a transit to transit move) opw-5023215 Forward-Port-Of: odoo/enterprise#111835 Forward-Port-Of: odoo/enterprise#111108
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 distributed across new stock moves, maintaining accurate inventory tracking. This prevents overestimation of available stock and improves the reliability of demand forecasting.
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#112125 Forward-Port-Of: odoo/enterprise#107493
This update corrects an issue preventing SBR tax reports from submitting due to incorrect date formatting and overly long consultant information. The commit restores the original date format, which is now validated, and simplifies the consultant name to only display the abbreviation. This ensures reports pass validation and can be successfully submitted.
Original PR description
Description of the issue this commit addresses: During the tax return flow for the SBR development[^1], we discovered that the date format for the "DateTimeCreation" node had been wrongly readjusted and that the "ProfessionalAssociationForTaxServiceProvidersName" content could be too long due to showing the entire description. Those two issue cause the file to be rejected and make submission impossible. [^1]: https://www.odoo.com/odoo/967/tasks/6034675 --- Desired behavior after this commit is merged: This commit reintroduces the old DateTimeCreation format which is the only one that passes the tests done on the xbrl validation service[^2] and replaces the ProfessionalAssociationForTaxServiceProvidersName's value for the abreviation of the order instead of the entire description. [^2]: https://aansluiten.procesinfrastructuur.nl/site/validaties-digipoort/xbrl-validatie --- task-none Forward-Port-Of: odoo/enterprise#111923 Forward-Port-Of: odoo/enterprise#111817
This update resolves an issue where the 'Comment' field was appearing twice on the Customer Ratings reporting form. The fix made the duplicate 'publisher_comment' field invisible, streamlining the form and improving the user experience. This ensures consistent and accurate data reporting.
Original PR description
**Steps to reproduce:** - Go to helpdesk > Reporting > Customer Ratings. - Open any rating record. - Observe that the 'Comment' field is displayed twice. **Issue:** - The form view contains a two different field with same string i.e feedback and publisher_comment **Fix:** - Made the publisher_comment field invisible in helpdesk's customer rating **Task-id: 5359052** Forward-Port-Of: odoo/enterprise#100823
This update prevents the automatic creation of rental planning shifts before a rental order is fully confirmed. Previously, changes to order quantities could trigger shift creation even without confirmation. This fix ensures shifts are created only when the rental order is finalized, improving planning accuracy and reducing potential errors.
Original PR description
**Steps to reproduce:**
- Install sale_renting_planning
- Create a product of type Goods with rental enabled
- Create a rental order and set quantity
- Update the quantity before confirming the order
- Check the planning shifts
**Issue:**
planning shifts are created even when the rental order is not confirmed and the quantity is updated.
**Cause:**
while creating shifts, the system does not check:
whether the rental order is confirmed whether planning is enabled on the product
**Fix:**
ensure that planning shifts are created only when:
the rental order is confirmed, and planning is enabled on the productThis update resolves an issue where discounts weren't correctly applied in the self-order point-of-sale flow. The fix ensures that discount information is properly passed through, preventing errors and guaranteeing accurate pricing calculations. This improves the reliability of the self-order process.
Original PR description
In the pos self-order flow, `_check_pos_order_lines` does not forward the `discount` field when sanitizing order lines. This caused `_merge_order_lines` to raise a `KeyError` when using `itemgetter('discount')` on lines that lack the key.
opw-6052719
Forward-Port-Of: odoo/enterprise#111591This update prevents the system from incorrectly syncing ‘e-Cobranza’ documents (collection notes) as vendor bills in the Uruguay localization. This change aligns with how delivery guides and withholdings are handled, ensuring data consistency and accuracy for financial reporting.
Original PR description
This pull request improves the synchronization process of vendor bills within the Uruguayan localization (`l10n_uy_edi`). Currently, the system might fetch documents that are not technically bills during synchronization. With this change, the system will explicitly avoid synchronizing `e-Cobranza` (Collection notes or Receipts) documents as vendor bills. Reasoning: `e-Cobranza` documents function conceptually more like payment receipts rather than actual vendor bills. Pulling them into the system as bills creates inconsistencies. This update aligns the handling of `e-Cobranza` with the existing behavior for `e-Remito` (Delivery Guides) and `e-Resguardos` (Withholdings), which are also appropriately excluded from bill synchronization. **Related Tasks** LATAM Task: 1367 ADHOC Task: 58906 Forward-Port-Of: odoo/enterprise#100549
This update resolves a technical issue where the AI system incorrectly identified the current user as a potential correspondent. The fix prevents this misconfiguration, ensuring accurate AI interactions and improving the reliability of the system. This change focuses on internal AI processes.
Original PR description
The fallback logic in computeCorrespondent was unintentionally allowing cases where the current user could be returned as the correspondent for AI.
This update resolves an issue where planning slots were unexpectedly created for rental orders, even when 'Plan Services' was disabled. The fix ensures that slots are only generated when 'Plan Services' is enabled, preventing unnecessary planning entries and improving the accuracy of rental order scheduling. This change impacts 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
This update corrects an issue where Web Studio exports were incorrectly formatting property data. The fix ensures that properties are exported in the correct XML format, improving the reliability and accuracy of exported configurations. This resolves a technical problem that could have impacted the ability to properly recreate Web Studio setups.
Original PR description
Since this commit*, properties are exported as an orm field object, while this method is meant to export the fields into xml records. This commit fixes this by converting the value before exporting it (using hidden _values). *https://github.com/odoo/odoo/commit/6f5e7aa783b336941f95c66ae70cb4ee160c00f4 Forward-Port-Of: odoo/enterprise#110336
This update fixes an issue where the XML generated for Mexican invoices wasn't correctly incorporating the issued address's zip code. Previously, the zip code was not being populated in the 'LugarExpedicion' field, which is a required data element for Mexican tax compliance. This change ensures accurate invoice data for tax reporting.
Original PR description
**STEP TO REPRODUCE** 1. install l10n_mx_edi_extended. 2. Add an issued address on the customer invoice journal, with a zip code. 3. Create invoices, and create a global invoice with them. 4. download the xml, and notice the field LugarExpedicion is not using the zip from the issued address while it should. opw-5956837 Forward-Port-Of: odoo/enterprise#112107 Forward-Port-Of: odoo/enterprise#108732
This update corrects a payroll calculation issue for Swiss businesses using the Odoo Enterprise system. Specifically, it adds a 200% overtime wage type, aligning with Swiss labor regulations and ensuring accurate payroll processing for employees working overtime. This change improves compliance and reporting accuracy for our Swiss clients.
Original PR description
Forward-Port-Of: odoo/enterprise#110796
This update resolves an issue where tax lines within the bank reconciliation widget couldn't be manually unmatched when the related tax account was set to 'reconcilable'. Previously, this prevented users from correctly reconciling transactions. Now, users can unmatch these tax lines, ensuring accurate bank reconciliation and tax reporting.
Original PR description
In the bank reconciliation widget, tax lines are protected from unreconciliation to maintain tax integrity. However, when the tax account is set as reconcileable the user may need to manually unmatch transactions. Steps to reproduce: - Open the 'Tax Paid' account and enable 'Allow Reconciliation' - Create a bill using a tax and post it - Go to the Bank Reconciliation widget - Select a statement line and match it with the tax line from the bill Issue: The line cannot be unmatched because the related button is missing opw-5871821 Forward-Port-Of: odoo/enterprise#110186
This update resolves a crash issue in tax reports when a report lacks a defined return type. The fix ensures reports automatically fall back to the company's tax periodicity, providing greater stability and reliability for financial reporting. This change addresses a previously identified bug related to date scope calculations.
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, 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#111796
20 changes
Resolved issues and error corrections
This update fixes an issue where invoices sent via Peppol were creating duplicate documents in our system. The change ensures attachments are synchronized only once during the standard document linking process, streamlining the Peppol invoice workflow and improving data accuracy.
Original PR description
When sending an invoice via Peppol, the PDF and XML attachments are logged in the chatter. This automatically triggers a synchronization with the Documents app. However, the Peppol sending flow also includes a dedicated document linking step later in the process. This caused the same attachments to be registered as documents twice. This commit skips the document synchronization during the initial chatter logging step. The attachments will now only be synchronized once during the dedicated linking phase. Note: ec6e559 prevented duplicate attachments in the chatter with some cleanup code, but this cleanup code runs after the document has already been created and does not remove the document, resulting in duplicate documents, which this commit fixes. Task-6030468 Forward-Port-Of: odoo/odoo#256057 Forward-Port-Of: odoo/odoo#254893
This update corrects an issue where the Odoo module upgrade would fail if the country names (Peru, Ecuador) were changed in the system settings. The fix replaces country names in the CSV data files with stable XML IDs, ensuring consistent resolution during module upgrades and preventing upgrade failures.
Original PR description
### Steps to reproduce ------------------ - Install `l10n_pe` or `l10n_ec` module. - Go to *Settings → Countries* and rename the country (e.g. "Peru" → "PERÚ", "Ecuador" → "ECUADOR"). - Upgrade the…
### Steps to reproduce
------------------
- Install `l10n_pe` or `l10n_ec` module.
- Go to *Settings → Countries* and rename the country (e.g. "Peru" → "PERÚ",
"Ecuador" → "ECUADOR").
- Upgrade the module.
### Issue
-----
The files `l10n_pe/data/res.bank.csv` and `l10n_ec/data/res.bank.csv`
reference countries using their names (e.g. "Peru", "Ecuador").
During module upgrade, the CSV import resolves many2one relations using
the country name. If the country name has been modified by the user,
the lookup fails and the module upgrade crashes with:
```python3
2026-03-06 23:48:11,112 27 CRITICAL db_3950261 odoo.service.server: Failed to initialize database `db_3950261`.
Traceback (most recent call last):
File "/home/odoo/src/odoo/19.0/odoo/service/server.py", line 1510, in preload_registries
registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
File "/home/odoo/src/odoo/19.0/odoo/tools/func.py", line 88, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/19.0/odoo/orm/registry.py", line 199, in new
load_modules(
File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 456, in load_modules
load_module_graph(
File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 216, in load_module_graph
load_data(env, idref, mode, kind='data', package=package)
File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 59, in load_data
convert_file(env, package.name, filename, idref, mode, noupdate=kind == 'demo')
File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 689, in convert_file
convert_csv_import(env, module, pathname, fp.read(), idref, mode, noupdate)
File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 754, in convert_csv_import
raise Exception(env._(
Exception: Module loading l10n_pe failed: file l10n_pe/data/res.bank.csv could not be processed:
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
select id,name,code from res_country where code='PE'
+-----+----------------------------------------------------------------------+------+
| id | name | code |
|-----+----------------------------------------------------------------------+------|
| 173 | {"de_DE": "Peru", "en_US": "PERÚ", "es_ES": "PERÚ", "es_PE": "Perú"} | PE |
+-----+----------------------------------------------------------------------+------+
```
### Root Cause
----------
Using translatable/display names in CSV data is not reliable, as these
values can be customized or translated.
### Fix
---
Replace country name references with stable XMLIDs:
- `base.pe` for Peru
- `base.ec` for Ecuador
Using XMLIDs ensures consistent resolution regardless of name changes
or translations.
opw-6015302
upg-3950261
tbg-2492
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#256029
Forward-Port-Of: odoo/odoo#254096This update fixes an issue where invoices generated from timesheets incorrectly displayed the total hours instead of the correct number of days. The change ensures that timesheet hours are converted to the Sale Order Line's unit of measure (Days) before being applied to the invoice quantity, resulting in accurate invoice calculations. This improves the reliability of invoicing for timesheet-based products.
Original PR description
Steps to reproduce: -------------------------- 1. Install sale_timesheet 2. Create a quotation with a timesheet-based product - Set quantity = 3 - Set UoM to Days (timesheet UoM is Hours) 3. Confirm…
Steps to reproduce: -------------------------- 1. Install sale_timesheet 2. Create a quotation with a timesheet-based product - Set quantity = 3 - Set UoM to Days (timesheet UoM is Hours) 3. Confirm the quotation and click on the smart button Recorded. 4. Record 16 hours of timesheets. 5. Create an invoice using a timesheet period (starting from SO date) 6. Check the invoice quantity Issue: ----------- The invoice quantity is incorrect. It assigns the hour value (e.g., 16) to the invoice line even though the SOL is configured in "Days" (expected 2 days for 16 hours). Cause: ----------- After this commit c3b6053, The `_recompute_qty_to_invoice` method sums timesheet `unit_amount` (in hours) and assigns it directly to `qty_to_invoice` without converting it to the sale order line UoM when a timesheet period is applied. Solution: --------------- Convert the aggregated timesheet hours into the SOL UoM before assigning it to qty_to_invoice. opw-6024804 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255790 Forward-Port-Of: odoo/odoo#254273
This update fixes a restriction in the bank reconciliation process. When a 'Tax Paid' account is set to allow reconciliation, users can now manually unmatch tax lines that were previously protected. This improves usability for users managing tax accounts that need to be reconciled.
Original PR description
In the bank reconciliation widget, tax lines are protected from unreconciliation to maintain tax integrity. However, when the tax account is set as reconcileable the user may need to manually unmatch transactions. Steps to reproduce: - Open the 'Tax Paid' account and enable 'Allow Reconciliation' - Create a bill using a tax and post it - Go to the Bank Reconciliation widget - Select a statement line and match it with the tax line from the bill Issue: The line cannot be unmatched because the related button is missing opw-5871821
This update resolves an issue where the Chrome debug log file wasn't always created, potentially causing problems with Odoo's internal diagnostics. The change ensures Odoo correctly handles situations where the log file might be missing, improving the reliability of debugging and troubleshooting.
Original PR description
Follow up to #255054 [Apparently][] on old versions of chrome `chrome_debug.log` may not exist if the verbosity is not at least 1 (or chrome otherwise has had things to write to the log). Thus handle the possibility of the file being missing instead of assuming it's present just because we've told chrome to generate one. [Apparently]: https://github.com/odoo/odoo/pull/255054#pullrequestreview-4001460518 Forward-Port-Of: odoo/odoo#255846 Forward-Port-Of: odoo/odoo#255736
This update streamlines the testing process for the Live Chat module by pre-generating a key asset bundle. Previously, this bundle was rebuilt repeatedly during tests, causing performance slowdowns. This change significantly reduces test execution time and improves overall system stability.
Original PR description
This commit sets the `im_livechat.assets_embed_external` bundle to be pregenerated while running tests to avoid rebuilding it at runtime (i.e. +280 times with a db "all"). Forward-Port-Of: odoo/odoo#256149 Forward-Port-Of: odoo/odoo#255847
This update resolves an issue where upgrading the `l10n_ae` module would fail if the user had renamed the 'United Arab Emirates' country in Odoo's settings. The fix replaces references to country names in a key data file with a stable XMLID, ensuring consistent module upgrades regardless of user customizations.
Original PR description
### Steps to reproduce ------------------ - Install `l10n_ae` module. - Go to *Settings → Countries* and rename the country "United Arab Emirates" (e.g. change it to "UAE"). - Upgrade the `l10n_ae`…
### Steps to reproduce
------------------
- Install `l10n_ae` module.
- Go to *Settings → Countries* and rename the country "United Arab Emirates" (e.g. change it to "UAE").
- Upgrade the `l10n_ae` module.
### Issue
-----
The file `l10n_ae/data/res.bank.csv` references the country using its name ("United Arab Emirates"). During the module upgrade, the CSV import tries to resolve the country relation using the country name. If the country name has been modified by the user (for example to "UAE"), the lookup fails and the module upgrade crashes with:
```python3
No matching record found for name 'United Arab Emirates' in field 'Country'
```
### Root Cause
----------
Using translatable/display names in CSV data is unreliable, as these values can be customized or translated by users.
### Fix
---
Replace the country name reference with the stable XMLID `base.ae` in `res.bank.csv`.
Using XMLIDs ensures consistent resolution regardless of name changes or translations.
opw-6015302
upg-3950261
tbg-2492
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#255993This 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 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
This update addresses a potential issue in our Point of Sale (POS) testing process. Previously, a refresh action prematurely ended IndexedDB transactions, leading to test failures. This change increases the timeout for these transactions, ensuring they complete successfully and improving the reliability of our POS test suite.
Original PR description
In some tests, we use refresh which will refresh the page after letting the indexedDB finish its transactions. In some cases, the transactions take more time than expected. In this commit, we increase this timeout to avoid failures that could be caused by not letting the time to the db to finish its transactions. runbot-errors: 240911, 240912 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253095
This update resolves an issue where discounts weren't correctly applied in the self-order point-of-sale flow. The fix ensures that discount information is properly passed through the system, preventing errors and guaranteeing accurate discount calculations during self-order transactions. This improves the reliability of the self-order functionality.
Original PR description
In the pos self-order flow, `_check_pos_order_lines` does not forward the `discount` field when sanitizing order lines. This caused `_merge_order_lines` to raise a `KeyError` when using `itemgetter('discount')` on lines that lack the key.
opw-6052719
Forward-Port-Of: odoo/enterprise#111591This update fixes a technical error that caused a crash when settling subscription orders through the Point of Sale (PoS) system. The issue stemmed from incorrectly processing a discount line, leading to a template error. Now, the system correctly handles these discount lines as notes, ensuring smooth order settlement.
Original PR description
**Steps to reproduce:** - Make a subscription product - Make a quotation with it, confirm it, then invoice it - Go back to the sale order and upsell it - Add another product - Go to the PoS to settle the order - A traceback appears **Why the fix:** Why tried to treat the informative line that says that this is a discount as a normal pos order line. We then tried to access the line's template, which caused a crash as the line's template was undefined. We now treat the line as we do a note, meaning to add it to the previous line in the order. We create a function to check if the line is a note and we override it in the **pos_sale_subscription** module. Enterprise PR: https://github.com/odoo/enterprise/pull/107002 opw-5582448
This update corrects a technical issue related to how subscription discounts are handled when importing sales data from the Sales module into the Point of Sale (POS) system. The change ensures that subscription-specific discounts are correctly processed, preventing potential errors and improving data accuracy. This resolves a reported problem impacting subscription-based sales.
Original PR description
This is a test for the related community fix and an override of the **isSaleOrderLineNote** method to add the subscription specific **subscription_discount** lines to be treated as a note when importing it from the Sales module. https://github.com/odoo/odoo/pull/247846 opw-5582448
This update resolves a technical issue that caused a traceback when deleting a title within a toggle list in the To-Do module. The fix ensures the system handles cases where there isn't a subsequent sibling element, preventing the error and improving stability. This change ensures a smoother user experience when managing toggle lists.
Original PR description
Steps to Reproduce: - Go to To-Do → Create New - Create a toggle list - Type something in the title - Press the delete button Description of the issue: - A traceback occurs. Cause: - In `handleDeleteForwardTitleEnd`, there is a check to verify whether the toggle title’s next sibling matches the toggle selector. However, when there is no next sibling, calling `matches()` results in a traceback. Solution: - Only check `matches()` if the next sibling exists. task-6040479
This update prevents the system from incorrectly syncing ‘e-Cobranza’ documents (collection notes) as vendor bills in the Uruguayan localization. This change aligns with how other related documents like ‘e-Remito’ and ‘e-Resguardos’ are handled, ensuring data consistency and accuracy.
Original PR description
This pull request improves the synchronization process of vendor bills within the Uruguayan localization (`l10n_uy_edi`). Currently, the system might fetch documents that are not technically bills during synchronization. With this change, the system will explicitly avoid synchronizing `e-Cobranza` (Collection notes or Receipts) documents as vendor bills. Reasoning: `e-Cobranza` documents function conceptually more like payment receipts rather than actual vendor bills. Pulling them into the system as bills creates inconsistencies. This update aligns the handling of `e-Cobranza` with the existing behavior for `e-Remito` (Delivery Guides) and `e-Resguardos` (Withholdings), which are also appropriately excluded from bill synchronization. **Related Tasks** LATAM Task: 1367 ADHOC Task: 58906 Forward-Port-Of: odoo/enterprise#100549
This update ensures that customer invoices can be properly updated by regenerating the associated XML file during import. Previously, the system reused imported XML, causing issues when invoices were modified. This change guarantees accurate invoice data and proper processing.
Original PR description
Problem --------- Currently, when importing a move, `ubl_cii_xml_file` gets set with said XML. This XML is then re-used during the export rather that regenerate a new XML each time. This is fine for customer bills as those are not meant to be modified. This is not the case of customer invoices. Client may import an invoice XML and later update that invoice. In such a case, we want to regenerate the XML and not reuse the imported version. Solution --------- Only set `ubl_cii_xml_file` for purchase move during the import. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256052
This update resolves an issue preventing the Spanish SII demo environment from working correctly. We've successfully tested a new environment mirroring the AEAT's requirements, ensuring it functions without requiring changes to the demo company's VAT number. This allows for more reliable testing of the l10n_es_edi_sii module.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255765 Forward-Port-Of: odoo/odoo#255377
This update fixes an issue where icons were removed when creating links from selections within the HTML editor. The change ensures icons are treated like images during link creation, maintaining their appearance in the final output. This improves the user experience and consistency of links.
Original PR description
Problem: When a selection contains both text and an icon, creating a link removes the icon from the content. Cause: Icons should be treated the same way as images during link creation. If an icon is present in the selection but not handled like an image, it gets removed when the link is applied. Solution: Handle icons in the same way as images when processing selections for link creation, ensuring they are preserved. Steps to reproduce: - Add text "abc" followed by an icon. - Select both the text and the icon. - Create a link. - Observe that the icon is removed and only the text remains. opw-6066195 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256002
This update ensures the HTML editor's testing environment consistently uses the Roboto font. Previously, variations in font settings could cause test failures. This change improves the reliability of our tests and guarantees a uniform user experience for the HTML editor.
Original PR description
Purpose of this PR: - Explicitly load Roboto using FontFace in indent.test.js to avoid fallback fonts (e.g. Ubuntu) across environments. This ensures consistent rendering and prevents flaky failures caused by font-dependent computed values. task-5916115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This pull request updates the core spreadsheet library used within Odoo. The changes address several bugs and performance improvements related to how spreadsheets are rendered and exported, specifically focusing on Excel compatibility and data handling. This ensures consistent and reliable spreadsheet functionality across the Odoo platform.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/778fcde50a [REL] 18.3.40 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/778fcde50a [REL] 18.3.40 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/cf46880a22 [FIX] grid_renderer_store: keep wrapping width with explicit align [Task: 6032407](https://www.odoo.com/odoo/2328/tasks/6032407) https://github.com/odoo/o-spreadsheet/commit/fcf19a9283 [FIX] functions: stop debugging context [Task: 6052128](https://www.odoo.com/odoo/2328/tasks/6052128) https://github.com/odoo/o-spreadsheet/commit/c0a274790c [FIX] config: fix release flow [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/9cba5f14d8 [FIX] SheetView: dirtify sheet viewport at UPDATE_CELL [Task: 5953775](https://www.odoo.com/odoo/2328/tasks/5953775) https://github.com/odoo/o-spreadsheet/commit/9fb65d6112 [FIX] xlsx: do not export dynamic tables to excel [Task: 5214240](https://www.odoo.com/odoo/2328/tasks/5214240) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update modifies the Swiss payroll module to include a 200% overtime wage type, aligning with Swiss tax regulations. This change ensures accurate reporting of overtime earnings for employees in Switzerland, improving compliance and financial reporting. The update was implemented as a bug fix to address a specific requirement.
Original PR description
Forward-Port-Of: odoo/enterprise#110796
13 changes
Resolved issues and error corrections
This update resolves an issue where saving a report with an empty XML format in the Web Studio tool would generate an error. The fix prevents the system from attempting to process empty XML data, ensuring a smoother user experience when creating reports.
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#88613
This update resolves an issue where the POS scale integration was not accurately displaying product weights, particularly with newer IoT box versions. The fix adjusts how the scale's measurement data is handled, ensuring correct weight readings are shown in the system. This improves the accuracy of product tracking for businesses using the POS scale feature.
Original PR description
Steps to reproduce - Use a localisation other than a european one (l10n_eu_iot_scale_cert must not be installed) - Setup the scale for the POS - Open the POS - Add a product to be weighted by scale to the order - Add product to the physical scale - The displayed weight is always 0 Cause: New versions of the IoT box uses the field result to return the scale measure instead of value. Fix for version 18.0 and its intermediary versions. [opw-5990467](https://www.odoo.com/odoo/project/49/tasks/5990467) Forward-Port-Of: odoo/enterprise#111963
This update fixes a display issue in the SEPA payment file generation process. Previously, the UI incorrectly showed an empty field for the PAIN 09 version, even when a valid value existed in the database. This change ensures the correct PAIN 09 version is consistently displayed, improving data accuracy for financial transactions.
Original PR description
https://github.com/odoo/enterprise/commit/80f9f966d7db793ae82e65c76514323cb10e34ab tried to fix the issue, but assumed the field would be returned empty by the ORM when the value was inconsistent with the db. It's not true: it returns the database value ; only the UI shows the field as empty. Forward-Port-Of: odoo/enterprise#112141
This update fixes an issue where global invoices generated from customer invoices weren't correctly using the issued address's zip code in the required XML format for Mexican tax reporting. The change ensures accurate data transmission for compliance with Mexican regulations, preventing potential errors and delays in processing.
Original PR description
**STEP TO REPRODUCE** 1. install l10n_mx_edi_extended. 2. Add an issued address on the customer invoice journal, with a zip code. 3. Create invoices, and create a global invoice with them. 4. download the xml, and notice the field LugarExpedicion is not using the zip from the issued address while it should. opw-5956837 Forward-Port-Of: odoo/enterprise#108732
This update fixes an issue where paid leave calculations were inaccurate for employees using the UAE Monthly pay structure. The change ensures that worked days are correctly accounted for in individual payslips, preventing incorrect salary adjustments. This improves the accuracy of payroll processing for UAE-based employees.
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#111280
This update corrects a previous issue where partner totals were incorrectly hidden, regardless of their value. Now, all partners with totals exceeding €3,005.06 are included, and insurance operations accurately track sales and purchase journal amounts for more complete reporting. This ensures greater accuracy in BOE file generation.
Original PR description
Before this PR: - Partners were only shown if their total was positive and above 3,005.06 €. Negative totals were hidden, even if they were lower than -3,005.06 €. - Insurance operations only took Purchase journal amounts into account. Amounts from Sales journals were ignored, and there was no distinction between the two types of operations. After this PR: - The report now uses the absolute value of the total. Partners with amounts exceeding 3,005.06 €, whether positive or negative, are now shown correctly. - Insurance operations are now divided into two distinct sections: Sales and Purchases. Amounts from both Sales and Purchase journals are now correctly taken into account and reported in their respective sections. task-5214023 Forward-Port-Of: odoo/enterprise#111983 Forward-Port-Of: odoo/enterprise#100413
This update resolves an issue where only administrators could delete work entry types within the payroll module. Now, users with SUPERUSER permissions can also delete these types, streamlining payroll administration. This change improves operational efficiency and reduces reliance on specific user roles.
Original PR description
Forward-Port-Of: odoo/enterprise#111967
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 readings. The fix ensures the scanner uses the correct company information, resolving the problem of misidentified products and enabling accurate barcode scanning across different company setups.
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#111662
This update resolves an issue preventing SBR tax reports from submitting correctly. The commit restores the correct date format and limits the consultant name description to the abbreviation, ensuring compliance with validation requirements and allowing successful tax return submissions.
Original PR description
Description of the issue this commit addresses: During the tax return flow for the SBR development[^1], we discovered that the date format for the "DateTimeCreation" node had been wrongly readjusted and that the "ProfessionalAssociationForTaxServiceProvidersName" content could be too long due to showing the entire description. Those two issue cause the file to be rejected and make submission impossible. [^1]: https://www.odoo.com/odoo/967/tasks/6034675 --- Desired behavior after this commit is merged: This commit reintroduces the old DateTimeCreation format which is the only one that passes the tests done on the xbrl validation service[^2] and replaces the ProfessionalAssociationForTaxServiceProvidersName's value for the abreviation of the order instead of the entire description. [^2]: https://aansluiten.procesinfrastructuur.nl/site/validaties-digipoort/xbrl-validatie --- task-none Forward-Port-Of: odoo/enterprise#111923 Forward-Port-Of: odoo/enterprise#111817
This update resolves an issue where the self-order process in the German POS module incorrectly handled discounts. The fix ensures that discount information is properly passed, preventing errors and ensuring accurate order totals. This improves the reliability of the self-order functionality.
Original PR description
In the pos self-order flow, `_check_pos_order_lines` does not forward the `discount` field when sanitizing order lines. This caused `_merge_order_lines` to raise a `KeyError` when using `itemgetter('discount')` on lines that lack the key.
opw-6052719
Forward-Port-Of: odoo/enterprise#111591This update prevents the system from incorrectly syncing ‘e-Cobranza’ documents (collection notes) as vendor bills in the Uruguayan localization. This change aligns with how other related documents like ‘e-Remito’ and ‘e-Resguardos’ are handled, ensuring data consistency and accuracy.
Original PR description
This pull request improves the synchronization process of vendor bills within the Uruguayan localization (`l10n_uy_edi`). Currently, the system might fetch documents that are not technically bills during synchronization. With this change, the system will explicitly avoid synchronizing `e-Cobranza` (Collection notes or Receipts) documents as vendor bills. Reasoning: `e-Cobranza` documents function conceptually more like payment receipts rather than actual vendor bills. Pulling them into the system as bills creates inconsistencies. This update aligns the handling of `e-Cobranza` with the existing behavior for `e-Remito` (Delivery Guides) and `e-Resguardos` (Withholdings), which are also appropriately excluded from bill synchronization. **Related Tasks** LATAM Task: 1367 ADHOC Task: 58906 Forward-Port-Of: odoo/enterprise#100549
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 search results, allowing users to accurately add and confirm quantities, maintaining consistent functionality. This improves the usability of the barcode app for all product types.
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
This update corrects a payroll calculation issue for Swiss businesses using the Odoo Enterprise module. It adds a new wage type allowing for 200% overtime pay, ensuring accurate Swiss tax and social security reporting (ELM). This change aligns with Swiss labor regulations and improves payroll accuracy for our Swiss clients.
Original PR description
Forward-Port-Of: odoo/enterprise#110796
7 changes
Resolved issues and error corrections
This update addresses a minor visual issue on mobile devices where the last barcode in a work order list would appear hidden behind the work order card due to excessive spacing. The change reduces this spacing, ensuring all barcodes are fully visible and improving the user experience. This is a simple UX fix.
Original PR description
small UX improvements: - change button labels - prevent empty scroll on MO barcodes Decrease margin bottom on last barcode item to prevent empty scroll. Previous margin was too big and made it possible to scroll up too far so that the last barcode was out of view, 'hidden' behind MO card. task-5974291
This update removes a redundant column ('No Follow-Up') from the Customer Statement report. This simplifies the report for users, eliminating potential confusion and ensuring a clearer presentation of customer invoicing data. The change improves the overall user experience.
Original PR description
Currently, the `Customer Statement report` includes the `No Follow-Up` column. **Steps to reproduce:** - Install the `account_reports` module. - Go to Invoicing> Customers > Customers and open any company partner. (e.g., Azure Interior) - Click the `Payable` smart button. - Select `Report: Customer Statement`. **Observation:** The `No Follow-Up` column appears in the `Customer Statement report`. However, this column is only relevant for the `Open Items`. In the Customer Statement report it has no functional purpose and may create `confusion`. **Fix:** This commit removes the `No Follow-Up` column from the `Customer Statement report`. Upgrade PR: https://github.com/odoo/upgrade/pull/9733 opw-5743390
This update optimizes how Odoo counts knowledge articles, ensuring faster loading times and a smoother user experience. The change addresses a technical issue related to data retrieval, meaning the update doesn't introduce new queries. This results in a performance improvement for the Knowledge module.
This update corrects an issue in the payroll calculations by ensuring ormcache keys accurately include all necessary parameters. Specifically, the system now handles dynamic date calculations correctly, preventing caching problems and improving the stability of payroll processing. This change ensures more reliable and efficient payroll operations.
Original PR description
[FIX] hr_payroll: fix ormcache key for _get_parameter_from_code 1. ormcache key should contain all parameters, `raise_if_not_found` is not a valid exception 2. `data=None` will fallback to `fields.Date.today()` which is dynamic and shouldn't be ormcached. https://github.com/odoo/odoo/pull/255514
This update resolves an issue where payroll data was incorrectly relying on outdated XML references. By adding a specific parameter, the system now loads data more reliably, ensuring accurate payroll calculations. This improves the stability and accuracy of HR payroll processing.
Original PR description
For now some data depend on xml ref and the code run on loading before the actual recoreds are loaded so we need to add `, raise_if_not_found=False` Task: 6072212
This update resolves an issue where clicking the 'X' button in the pay run confirmation wizard unexpectedly continued the process instead of closing it. The fix ensures the 'X' button correctly closes the wizard, improving user experience and preventing unintended actions. This change ensures consistent and reliable pay run confirmation.
Original PR description
Steps to reproduce: - Install the hr_payroll module. - Create a new Pay Run with all employees - Click on Continue for Time Off, which opens the confirmation wizard - Click on the “X” (close button) at the top right corner Issue: Clicking on the “X” in the confirmation wizard continues the process instead of simply closing the wizard. Cause: The issue occurs because the dismiss action is not properly handled when opening the confirmation wizard. Fix: This PR handles the dismiss action by passing an empty function. task-6036649
A bug in report calculations was causing errors when editing values within reports. This update corrects a mismatch between how report data is sent and received, ensuring accurate calculations after manual changes. This improves report reliability and data accuracy for users.
Original PR description
…getting column_group_totals from json Backport of f91e98fe645768db4af590fa4cdfe2ddfe85f888 // Bug The following flow failed: 1) Create a report with 3 lines: - Line 1: using the "domain" engine -…
…getting column_group_totals from json
Backport of f91e98fe645768db4af590fa4cdfe2ddfe85f888
// Bug
The following flow failed:
1) Create a report with 3 lines:
- Line 1: using the "domain" engine
- Line 2: using the "external" engine, with subformula="editable"
- Line 3: an aggregation summing lines 1 and 2
2) Open the report, and edit the amount in line 2
===> Error message, stating Line 1 cannot be evaluated while evaluating Line 3's formula.
// Cause of the issue
When editing a manual value, to avoid recomputing the whole report uselessly, the client sends the column_groups_totals that were computed to render report back to the server. When modifying the external value, that data structure is used to get the results of all other expressions, and reevaluate the aggregations that depend on the modified external value. json is used to send the column_group_totals.
json conversion always forces the keys to be strings. In the past, this was no problem, since the column_group_totals' keys were column group keys, which were also strings server-side. However, https://github.com/odoo/enterprise/commit/ec3581cd759d8c4e03db9e08f6f95546e5724e1f now makes those key indices of a list, hence integers. So, when column_group_totals were sent from the client, they basically were ignored, since none of their keys matched any column group index, causing the bug.
Forward-Port-Of: odoo/enterprise#11184116 changes
Resolved issues and error corrections
This update fixes a minor issue where the SEPA payment file version was incorrectly displayed as empty in the Odoo interface. The fix ensures the correct 'PAIN 09' version is generated, aligning with data stored in the database. This improves the accuracy of payment file generation.
Original PR description
https://github.com/odoo/enterprise/commit/80f9f966d7db793ae82e65c76514323cb10e34ab tried to fix the issue, but assumed the field would be returned empty by the ORM when the value was inconsistent with the db. It's not true: it returns the database value ; only the UI shows the field as empty. Forward-Port-Of: odoo/enterprise#112141
This update resolves an error that occurred when users removed the interval setting from expense cards. The fix ensures the system defaults to 'all_time' when no interval is specified, preventing a KeyError and maintaining smooth expense card functionality. This improves the user experience and prevents data inconsistencies.
Original PR description
Currently, an error occurs when the user removes the interval from the expense card. **Steps to Reproduce:** - Install the `hr_expense_stripe` module. - Go to `Expenses` > `Cards`. - Click `New` and remove the `interval value (All Time)`. `KeyError: False` When the user removes the interval, the system attempts to access the interval from `interval_multiplier_map`. However, since the interval becomes False, it raises a KeyError at [1]. This commit ensures that when no interval is set, the system defaults to `all_time` as the interval, since `all_time` is ignored as the default value. [1]:- https://github.com/odoo/enterprise/blob/06be616bb4d74f0a089e8e318d25c2424594f813/hr_expense_stripe/models/hr_expense_stripe_card.py#L287
This update ensures that audit reports in the Denmark localization module correctly display account report variants specific to the company being used. Previously, the system defaulted to a global balance sheet, which is now fixed by correctly applying the company context when generating account report options. This improves accuracy and relevance for financial reporting in the Denmark locale.
Original PR description
Currently, when creating an audit report, the system does not use the audit report's company when generating the options for the account reports embedded in the new articles. As a result, the system may not load the account report variant that is specific to the audit report's company. Steps to reproduce: 1. Install the Denmark localization module (`l10n_dk`) 2. Switch to the Denmark company using the navbar 3. Create an audit report 4. Open the article "Balance Sheet" of your report 5. Open the embedded account report of that article => The system opens the global balance sheet. **TO BE**: it should open the balance sheet that is specific to the Denmark. To fix the issue, we will set the company to use when generating the account report options via the context and the `forced_companies` option. These changes should ensure that the account reports embedded in the articles load the right variants. Task-5901886
This update resolves an issue in the Odoo payroll testing process where records weren't consistently available, leading to test failures. The fix ensures the test uses defined analytic accounts and plans directly, improving the reliability and stability of the payroll testing environment. This enhances the accuracy of payroll calculations.
Original PR description
The test that was introduced in the following PR (https://github.com/odoo/enterprise/pull/111140), under some circumstances, was causing problems due to some records not being present. Indeed it was bad practice to use records not defined in the test, so we fix it here by defining the analytic accounts and their plan directly in the test instead of searching for them. Runbot Error: 242151
This update fixes a problem where users with limited accounting access would encounter errors when validating invoices due to restricted access to audit reports. The change ensures bill validation functions correctly without requiring additional user permissions, improving usability for standard users.
Original PR description
An issue occurs when an Invoicing User tries to validate a bill while an audit report exists, resulting in an access error because the user does not have permission to access account.report. Steps to reproduce: - Create an audit report for the current year - Create a user with only the “Accounting / Invoicing” access - Log in with this user and attempt to validate a bill, the access error appears on account.report since only Bookkeeper, Invoicing & Banks and Read-only accounting group has access to return. This fix ensures the validation works correctly without requiring extra access. opw-6049259
This update resolves a potential error where the 'signRequestToken' value wasn't consistently being sent to the signing process. The change ensures that the correct token is always transmitted, improving the reliability of the digital signature functionality. This prevents potential issues with users initiating or completing the signing process.
Original PR description
Before this commit, the `this.signInfo.get("signRequestToken")` variable could be undefined in some cases. This commit ensure the correct values are always sent to the controller in the propagation.
task-6064181This update resolves an issue caused by changes in how Wise's API returns Swift code information. The system now consistently handles both 'swift_code' and 'SwiftCode' formats, preventing errors and ensuring accurate direct deposit processing. This improves stability and reliability of the direct deposit feature.
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
This update corrects a problem with the demo data used for the l10n_ch_hr_payroll module. Specifically, an incorrect reference was removed, ensuring the demo data accurately reflects the insurance group setup. This ensures consistent and reliable demo data for testing and training.
Original PR description
This commit removes an unnecessary record and fix wrong reference to the insurance line of the insurance group in the demo data of the l10n_ch_hr_payroll module. task-6070942
This update resolves an issue preventing superuser administrators from deleting obsolete work entry types within the Odoo payroll module. This change improves administrative efficiency by allowing for cleaner management of payroll configurations. It ensures that payroll data remains accurate and up-to-date.
Original PR description
Forward-Port-Of: odoo/enterprise#111967
This update resolves an issue where the XML generated for Swiss payments (iso20022_ch) incorrectly used an outdated payment schema. The fix ensures the XML adheres to current Swiss banking standards, specifically the pain.001.001.09 format, and adds necessary validation attributes for accurate processing. This improves the reliability of payment processing for Swiss customers.
Original PR description
**PROBLEM** According to documentation (https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-credit-transfer-sps-2025-en.pdf) PstlAdr must be structured. This isn't the case when generating a xml for the payment method iso20022_ch. **STEP TO REPRODUCE** 1. install l10n_ch and account_iso20022. 2. Create a swiss contact with a full address. And activate payment on the bank account of this contact. 3. Select the Company CH, and set a bank account in the bank journal configuration. 4. Create a vendor payment to the swiss contact. 5. Create a batch payment with it, and validate to get the xml. 6. Open the xml, and notice the PstlAdr isn't structured. Ticket [link](https://www.odoo.com/odoo/project.task/5880247) opw-5880247 Forward-Port-Of: odoo/enterprise#111158 Forward-Port-Of: odoo/enterprise#107025
This update resolves an issue where documents couldn't be opened after their names were changed. The fix corrects a technical error in the document management system related to how attachments were handled. This ensures documents can be reliably opened and used after being renamed, improving user workflow.
Original PR description
Steps to reproduce: 1. Install `documents` 2. Open a document in full screen and click on info icon on top right 3. Edit the name and close full screen document and chatter 4. Try to open the same document Issue: - Traceback occures `TypeError: Cannot read properties of undefined (reading 'insert')` Cause: - In file document_service `this.store.Attachment` was used instead of `this.store["ir.attachment"]` After this commit https://github.com/odoo/odoo/commit/70153559c34ffd18c67b83c39ee397ecb0a90b4a we renamed the Attachment model opw-5483625 Forward-Port-Of: odoo/enterprise#110001 Forward-Port-Of: odoo/enterprise#105602
This update fixes a problem where the helpdesk tour would sometimes fail to correctly create new tickets. The fix ensures the tour waits for the kanban view to fully load before attempting to click the 'New' button, preventing errors and improving tour reliability. This ensures a smoother experience for users creating tickets through the tour.
Original PR description
This PR fixes a flickering failure in the `helpdesk_tour` ### Problem In the kanban view, the tour occasionally tried to click the "New" (quick create) button before the view's internal structure was fully painted. This caused the tour to click a wrong element. ### Solution Updated the step trigger to include a selector for the kanban group (`.o_kanban_group`). By requiring the presence of the group container, we ensure that: 1. The page content has actually loaded. 2. The specific "New" button within the kanban context is visible and ready. **Runbot ID: 223081** Forward-Port-Of: odoo/enterprise#110333
This update resolves an issue where dropship orders weren't accurately reflecting delivered quantities. The fix adjusts how the system tracks moves during dropship transactions, ensuring the correct quantity is displayed on the sale order line. This ensures accurate order fulfillment and reporting.
Original PR description
**Steps to reproduce:** - Make sure you have 3 companies (comp A, B and C) - Navigate to Settings/Users & Companies/ Companies - for each company in the 'Inter Company Transactions' tab: check…
**Steps to reproduce:** - Make sure you have 3 companies (comp A, B and C) - Navigate to Settings/Users & Companies/ Companies - for each company in the 'Inter Company Transactions' tab: check 'generate Sale Orders', 'generate purchase orders' and 'synchronize Deliveries to your receipts' then select a warehouse and a receipt operation type From company A - create a storable product - in the Purchase tab, set the company B as a vendor From company B - in the Purchase tab of the product, set company C as a vendor From company C - set a positive on hand quantity From Company A - create a SO for 1 quantity of your product - on the sale order line, unhide de route_id column and set it to dropship - confirm the SO and the linked PO From company B - on the SO created with company A as customer (you might need to remove the 'my quotations filter to find it), set the dropship route in the route_id column of the sale order line - confirm the SO and the linked PO From company C - confirm SO created with company B as customer - validate the delivery From company B - validate the dropship **Current behavior:** the quantity delivered on the sale order line is 0 **Expected behavior:** it should be 1 **Cause of the issue:** inside _compute_qty_delivered, we fetch the incoming and outgoing moves using _get_outgoing_incoming_moves() https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/sale_stock/models/sale_order_line.py#L200 There, for the move of the dropship picking, inside the if condition, move._is_dropshipped_returned() will be True https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/sale_stock/models/sale_order_line.py#L348-L354 That's because the move is going from transit to transit https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/stock_account/models/stock_move.py#L186-L195 So it will not be added to the outgoing moves and qty_delivered will stay 0. **fix** is_dropshipped_returned should not prevent the move to be added to the outgoing moves if is_dropshipped() is aslo true (i.e. it's a transit to transit move) opw-5023215 Forward-Port-Of: odoo/enterprise#111835 Forward-Port-Of: odoo/enterprise#111108
This update fixes a display issue in the external value pop-up, ensuring it uses the correct decimal separator based on the user's language settings. Previously, the pop-up always displayed numbers with a dot, regardless of the user's locale. This change ensures a more accurate and user-friendly experience for international users.
Original PR description
Description of the issue this commit addresses: The external value pop up doesn't take into account the locale to chose which decimal separator to use. --- Desired behavior after this commit is merged: The decimal separator is the one determined by the language of the user rather than always a dot. --- task-6010533 Forward-Port-Of: odoo/enterprise#111997 Forward-Port-Of: odoo/enterprise#109948
This update corrects a technical issue where the system incorrectly handled VAT numbers for certain countries like Switzerland. The change ensures that VAT numbers, which can be longer than 18 characters, are properly transmitted to FedEx, preventing delivery errors. This ensures accurate data submission and avoids potential shipping delays.
Original PR description
Issue ----- Fedex limits VAT numbers to 18 char long strings. This is contradictory with how they are stored in db for some countries (eg Switzerland, where the format is CHE-123.456.788 VAT -> 19 char long). Steps to reproduce ----- - Setup Fedex - Create a customer - Company (for VAT number) - VAT number: CHE-123.456.788 TVA - Create a delivery and confirm it Cause ----- VAT number is retrieved as is in https://github.com/odoo/enterprise/blob/0220d413988708c662ffca3c7fb38641c3d9870a/delivery_fedex_rest/models/fedex_request.py#L332-L343 ----- Ticket: opw-5926452 Forward-Port-Of: odoo/enterprise#111864 Forward-Port-Of: odoo/enterprise#109999
This update fixes an issue where duplicating a product template automatically published it, even if the original wasn't. The change ensures that duplicated products remain unpublished by default, aligning with expected behavior and preventing accidental product listings. This improves data consistency and simplifies product management.
Original PR description
Issue: --- Duplicate product template creates a published product which is not expected. Duplicated products should be unpublished by default. #### Steps to reproduce: 1- Create a product and add a…
Issue: --- Duplicate product template creates a published product which is not expected. Duplicated products should be unpublished by default. #### Steps to reproduce: 1- Create a product and add a eCommerce category. 2- Without publishing the product duplicate it. Even though the original product is not published, the duplicated one is published. Expected: Regardless of published state of original product, the duplicated product should not be published. Cause: --- This regression is introduced in https://github.com/odoo/enterprise/pull/66218 to create a `is_published` product if `public_categ_ids` is set. However this was only supposed to be when creating a new product using form. It makes the create to ignore `is_published` default value even in copy. Fix: --- We can make sure if `is_published` is in create vals, don't force `is_published` to be set True. However, as `copy=False` in `is_published` field definition, it won't be in vals in copy. By overriding `copy_data`, we can ensure vals is present in copy. #### Note: `product_barcodelookup` doesn't depend on `website_sale`. However, `product_categ_ids` is used in this module. In the test for the same case we only run the test if the module is installed. This would be fine as this is a post-install test. opw-6014789 Forward-Port-Of: odoo/enterprise#111340
8 changes
Resolved issues and error corrections
This update fixes an issue where barcode scans didn't correctly apply putaway rules, resulting in incorrect destination locations for new stock moves. The fix ensures that barcode-created moves now automatically use the designated shelf location as defined in the putaway rules, improving inventory accuracy.
Original PR description
**Steps to reproduce:** * Install the `stock` module. * Go to Inventory → Configuration → Settings and enable Storage Locations(warehouse). * Create a new tracked product: * Enable Track Inventory by…
**Steps to reproduce:**
* Install the `stock` module.
* Go to Inventory → Configuration → Settings and enable Storage
Locations(warehouse).
* Create a new tracked product:
* Enable Track Inventory by Lots.
* Assign a Barcode to the product.
* Go to Inventory → Configuration → Putaway Rules and create a rule:
* When Product arrives in:`WH/Stock`
* Store to: `WH/Stock/Shelf 1`
* Go to Inventory → Configuration → Operations Types → Internal
Transfers and enable Create New under Lots/Serial Numbers.
* Open the Barcode application.
* Navigate to Operations → Internal Transfers and create a New
transfer.
* Scan the product barcode.
* Scan lot lot1.
* Scan lot lot2.
**Issue:**
The barcode flow sets a wrong destination location on the generated move lines.
Current:
- `WH/Stock`
Expected:
- `WH/Stock/Shelf 1`
The destination should follow the putaway rule, but barcode-created lines
keep the raw operation destination instead of the putaway-resolved sublocation.
**Cause:**
The issue comes from the barcode new-line creation flow.
The scan starts in `BarcodeModel._processBarcode()`
When no matching line is found, `_processBarcode()` prepares the scanned values
with `_convertDataToFieldsParams()` then calls `createNewLine()`
`createNewLine()` is only a wrapper and directly forwards the
call to `_createNewLine()`
So the flow is:
`_processBarcode()` -> `_convertDataToFieldsParams()` then `createNewLine()` ->
`_createNewLine()`
Then the real issue comes in `_createNewLine()`
where the new line is created with:
https://github.com/odoo/enterprise/blob/c5e90ec84f4b18cae93fc4d1b4a1d830f66cb90b/stock_barcode/static/src/models/barcode_model.js#L798-L802
The data used by `createNewLine()` comes from `_convertDataToFieldsParams()` in
There, `location_dest_id` is only set if the user explicitly scans a
destination location, at and In this flow no destination location is scanned
manually,
https://github.com/odoo/enterprise/blob/c5e90ec84f4b18cae93fc4d1b4a1d830f66cb90b/stock_barcode/static/src/models/barcode_picking_model.js#L1170-L1173
so `fieldsParams` does not contain
`location_dest_id`.
Because of that, `_createNewLine()` falls back to `_getNewLineDefaultValues()`
in which sets:
https://github.com/odoo/enterprise/blob/c5e90ec84f4b18cae93fc4d1b4a1d830f66cb90b/stock_barcode/static/src/models/barcode_model.js#L877
`_defaultDestLocation()` itself simply returns the picking destination location
So the issue is that the barcode model has no putaway handling when creating a
new line.
It simply takes the default destination from the picking, and that is
why the move line gets `WH/Stock` instead of the putaway destination
`WH/Stock/Shelf 1`.
**Fix:**
The fix is to handle putaway when a new line is created from the Barcode app.
Since the base barcode model does not handle putaway for new lines,
So add that logic in `BarcodePickingModel._createNewLine()`.
The new flow is:
- if a destination location was explicitly provided in `fieldsParams`,
keep it as is
- if a selected line already exists for the same product and already has
the correct destination, reuse that selected line destination
- otherwise, make one RPC call to get the putaway-resolved destination
for the new line
This RPC returns the correct destination according to the putaway rule,
and that value is assigned to the new line instead of keeping
the normal picking destination.
With this fix, barcode-created lines no longer fallback to `WH/Stock`.
They now use the correct putaway destination `WH/Stock/Shelf 1`.
---
opw-5220141This update fixes an issue where failing quality checks in subcontracting production orders led to incorrect quantity updates, causing inconsistencies in recorded products. The change ensures that quantities are correctly reduced from productions linked to the inspected lot, preventing unintended impacts on recorded products. This improves the accuracy of inventory tracking within subcontracting processes.
Original PR description
*:mrp_subcontracting{,_quality}, quality_control **Issue** In subcontracting, a failing quality check could lead to inconsistent quantities. **Steps to reproduce** - Create two tracked products…
*:mrp_subcontracting{,_quality}, quality_control
**Issue**
In subcontracting, a failing quality check could lead to inconsistent quantities.
**Steps to reproduce**
- Create two tracked products (final and component)
- Create a BoM for the final product using the component, with subcontracting
- Create a pass/fail Quality check with:
- Operation type: Receipts
- Control per Quantity
- Create a PO for the final product:
- With a quantity of 3
- With the associated partner be the one mentioned in the subcontracting BOM
- Confirm it
- Open the associated receipt
- Record 2/3 products
- Perform the quality check and fail 1 product
-> The quantity is removed from the 1 unrecorded product instead of the recorded ones
-> It is no longer possible to record additional products, although 1 should still be available
**Cause**
While recording products, the subcontracting production is split into multiple productions:
https://github.com/odoo/odoo/blob/a03fb90069c5a51340c81626cc90dbea22ca45bb/addons/mrp_subcontracting/models/mrp_production.py#L76
https://github.com/odoo/odoo/blob/a03fb90069c5a51340c81626cc90dbea22ca45bb/addons/mrp_subcontracting/models/mrp_production.py#L94
When a quality check fails, the quantity is reduced on the stock move:
https://github.com/odoo/enterprise/blob/2d3722242461a77ed954cc09835539e8010494f8/quality_control/models/quality.py#L471
This reduction is propagated to the subcontracting productions, removing the quantity from the first production,
then the next one if needed.
The production order is determined here:
https://github.com/odoo/odoo/blob/a03fb90069c5a51340c81626cc90dbea22ca45bb/addons/mrp_subcontracting/models/stock_move.py#L320
As a result, the reduction could be applied to a production unrelated to the inspected lot.
**Solution**
In case of a quality failure, ensure subcontracting productions are ordered so that:
- productions linked to the inspected finished lot (when lot tracking is enabled), and
- among them, productions that have already been recorded
are reduced first when applying the quality failure.
opw-5427873A recent update to the approval report caused partner names exceeding 63 characters to overflow, making the report unreadable. 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 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
This update fixes a warning displayed in the tax report when vendor bills have expense lines with different vehicle assignments. The fix allows for accurate reporting even when some expense lines are associated with a vehicle and others are not, ensuring consistent tax calculations. 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
This update corrects a calculation error in the bank reconciliation widget's tax handling. Previously, RC taxes were incorrectly calculated as 'price included' leading to inaccurate tax amounts. This fix ensures RC taxes are calculated correctly, resulting in the expected tax amount of $25.00 for transactions.
Original PR description
Currently, when we add a tax in the manual operations tab of the bank reconciliation widget, tax computation will be forced as price included. The computation reverts to price excluded when altering the amount. Steps to reproduce: - Create a Statement line of 1000$ - In the Writeoff add 2.5% RC tax - Check created tax lines Issue: Adding a 2.5% RC tax gives 24.39 instead of 25.00 opw-5039386
This update resolves a bug that occurred when creating contracts with working schedules that had zero hours. The issue caused a calculation error (division by zero) during wage computation. This fix ensures accurate wage calculations for employees with zero-hour schedules, preventing the error and improving payroll reliability.
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
This update adds a 200% overtime wage type within the Swiss payroll module (l10n_ch_hr_payroll_elm_transmission). This change ensures accurate reporting of overtime compensation to tax authorities in Switzerland, complying with local regulations. It corrects a previous limitation and improves payroll accuracy for Swiss businesses using this module.
Original PR description
Forward-Port-Of: odoo/enterprise#110796
This update resolves an issue preventing the export of Profit & Loss reports with footnotes enabled for the l10n_lu_reports module. The fix corrects a dependency on an outdated model, ensuring proper XML generation and report functionality. This improves the reliability of financial reporting.
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#107765
2 changes
Resolved issues and error corrections
This update adds a new overtime wage type (200%) to the Swiss payroll module, aligning with local regulations. This change ensures accurate calculation and reporting of overtime compensation for employees in Switzerland, improving payroll compliance. The update impacts the calculation of Swiss payrolls.
This update resolves a test failure related to calculating AVS deductions in version 17. The issue stemmed from an incorrect date calculation within the test environment, specifically when simulating dates in 2027. By adjusting the test's time setting to 2026-02-28, the test now passes reliably.
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