This update fixes an issue where refunds with global discounts were incorrectly flagged as exceeding the original order total. The change ensures that refunds accurately account for reversed discounts, preventing inaccurate reporting and improving the reliability of refund processing. This impacts the accuracy of financial reporting related to refunds.

Before this commit, when refunding an order with global discounts, the refund total was compared against the original order total without considering the discounts. While the reversed discount line would be added to the refund, the system could incorrectly flag the refund as exceeding the original order total.

opw-5492686

This update fixes a bug in the Saudi HR payroll system where employees resigning after less than two years received a negative end-of-service benefit calculation. The code has been updated to correctly set this value to zero, aligning with Saudi accounting rules. The change also improves clarity by moving the relevant salary logic directly into the rule definition.

purpose: In the saudi eos rule, if the employee resigned after working in the company less than 2 years, their end of service is being computed as a negative value when it should be 0 instead.

- added the correct check for the case of employee resignation
- moved the logic of the salary rules for EOS benefit and provision from python methods to the rule itself to be more clear for the user

task-id: 5499646

This update ensures Odoo's Spanish tax reporting (l10n_es_report) complies with the latest requirements from BOE (the Spanish Official Gazette). Specifically, it incorporates changes related to Modelo 347, adding a placeholder for subsidy numbers and ensuring accurate export data for tax reporting purposes.

reference: https://www.boe.es/buscar/doc.php?id=BOE-A-2025-25390 considering the modelo 347

As we do not have anything for the subsidy number, we just put 6 0s.

opw-5926624

Forward-Port-Of: odoo/enterprise#107125

This update resolves a bug in the POS Restaurant Preparation Display module where incorrect order quantities were sometimes sent to the kitchen. The fix ensures the system waits for quantity updates before submitting orders, preventing errors that caused test failures and potential inaccuracies in kitchen orders. This improves order accuracy and reliability.

TASK: [#5897381](https://www.odoo.com/odoo/project/1737/tasks/5897381)

---

Inside tour tests environment for POS Restaurant Preparation Display module, when using the numpad to change the quantity of a product in the POS and sending the order to the kitchen immediately after, there is a chance that the quantity is not updated in time. This could lead to sending an order with an incorrect quantity to the kitchen display. As a result, the test `test_payment_does_not_cancel_display_orders` was failing.

We are waiting for the orderline to be updated with the correct quantity before submitting the order.

X-original-commit: 5ebd1ca99dddbbc62aff90202491562114c0c0dc

Forward-Port-Of: odoo/enterprise#106600

This update resolves an issue where feedback wasn't being properly recorded when approving activities within web studio. A recent refactoring caused a bug that prevented feedback messages from posting. Now, feedback is correctly attached to approvals via activity feedback, ensuring a smoother workflow.

Approving an approval via an activity with feedback did not work properly as the feedback was never posted.
This was due to the consecutive refactoring that broke the feature.

After this commit, the feedback is posted as a message

opw-5782803

This update resolves a problem where certain characters (like 'ñ' or 'stress' in addresses) were not correctly encoded in the XML files generated for DIAN invoices. This prevented proper transmission of invoices to the DIAN tax authority, ensuring accurate reporting and compliance. The fix ensures all invoice data is correctly formatted.

Some characters are not well encoded in dian xml

Steps:

- Activate the DIAN Demo Mode
- Create a partner that has a "stress" or a "ñ" in their address
- Create and confirm an invoice for partner
- Open send and print wizard and select 'email' and 'dian'
- Unzip the generated zip file and open the xml file
-> Characters are wrongly encoded in the embedded xml

opw-5883880

This update fixes errors in how Hong Kong payroll taxes are calculated, specifically preventing incorrect deductions for ERMPF and correcting the inclusion of rental allowances in IRD reports. These changes ensure accurate tax reporting and compliance with Hong Kong regulations.

Fixes two issues related to computations;
The taxable salary wrongly deduce the ERMPF which it should not.
in the IRD reports, the total income includes the rental allowances, which is wrong according to their specs.

task-5353781

Forward-Port-Of: odoo/enterprise#107136
Forward-Port-Of: odoo/enterprise#100842

This update fixes an issue where rental accessories added from the cart's suggested products wouldn't consistently apply the correct rental period. Now, when adding an accessory to a cart, it uses the same rental period as the existing cart, preventing errors and ensuring accessories are correctly added to the order. This improves the rental experience for customers.

Why this commit
---

When adding a rental accessory product from the cart page suggested products, the [add_to_cart](https://github.com/odoo/enterprise/blob/19.0/website_sale_renting/controllers/cart.py#L52-L58) was triggered without the rental start and end dates(None was taken by default). As a result, the system uses [default rental duration](https://github.com/odoo/enterprise/blob/19.0/website_sale_renting/models/sale_order.py#L95-L99) for comparison and considers the accessory as having a different rental period then on the sale order and raised an error
 preventing it from being added to the cart.

This issue did not occur when adding the same product from its product page, as the rental context was correctly provided there.

After this Commit
---
The rental start and end dates from the current sale order are  passed when adding accessory products from the cart page suggested products. This ensures that rental period consistency checks succeed and the accessory can be added without raising an invalid operation error.

Steps to Reproduce
---
1. Create two rental products A and B.

2. Configure product B as an accessory of product A.

3. Add product A to the cart with any rental period(except default).

4. From the cart page, attempt to add product B from suggested products.

5.Observe the error about mixing different rental periods.

Here is the video demonstrating on how the error is reproduced :


https://github.com/user-attachments/assets/3d5e6f96-cebd-4221-8592-1bdb6ae40ec7



Expected Result

The accessory product is added to the cart using the same rental period as the existing cart's rental period.

OPW: 5823691

This update corrects an issue where disposed assets continued to appear in depreciation reports. The fix ensures that disposal dates are correctly calculated, preventing inaccurate reporting after assets have been removed from the books. This improves the reliability of financial reporting.

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Audit Trail"

- Go to "Accounting / Accounting / Management / Assets"
- Create an asset:
  * Original Value: [any]
  * Acquisition Date: [in the past] (e.g. 01/01/2025)
  * Duration: [at least until today] (e.g. 36 Months)
  * Depreciation Account: [any]
  * Expense Account: [any]
- Confirm the asset

- Modify Depreciation:
  * Action: Dispose
  * Date: [in the past] (e.g. 30/10/2025)
  * Loss Account: [any]
- Dispose

- Go to "Accounting / Reporting / Management / Depreciation Schedule"
- Filter on a period after the disposal date

**Issue:**
The asset appears in the selected period even if it has already been disposed.

**Cause:**
There are posted depreciation moves that have a date after the disposal date.
These moves should be deleted but the Audit Trail feature prevents it. These moves are cancelled instead.
However, the disposal date computed on the asset is taking the max date from all the depreciation moves.
Even the cancelled ones ; leading to a disposal date different than the one entered.

opw-5225749

Forward-Port-Of: odoo/enterprise#107028