Daily updates from Odoo
Monday, February 23, 2026
5 changes · master
Resolved issues and error corrections
This update ensures Odoo's Mexican payroll system accurately reflects the latest Social Security Law regulations. Specifically, it handles scenarios where employee earnings are at or below the minimum wage, correctly zeroing out related deductions and ensuring accurate XML generation for compliance. This update is crucial for accurate reporting and adherence to Mexican tax laws.
Original PR description
According to the Mexican Social Security Law, when an employee's total monthly earnings (including bonuses and commissions) are equal to or less than the monthly minimum wage (l10n_mx_daily_min_wage…
According to the Mexican Social Security Law, when an employee's total monthly earnings (including bonuses and commissions) are equal to or less than the monthly minimum wage (l10n_mx_daily_min_wage * 365 / 12), they are exempt from social security contributions and income tax, also they lost the subsidy benefit. - The next rules are zeroed out when the gross salary is equal or less than the minimum wage: - IMSS_EMPLOYEE: IMSS Total (Employee) - ISR: ISR (Income Tax) - SUBSIDY: Used Subsidy - IMSS_EMPLOYEE and ISR are omitted from the generated XML. - As the ISR is zero, the `totalDeducciones` attribute on the `nomina12:Nomina` node should be removed. - The SUBSIDY should be present in the `SubsidioCausado` attribute on the `nomina12:SubsidioAlEmpleo` node, but the `Importe` attribute on the `nomina12:OtroPago` node should be 0.0. This change requires updates to existing standard tests, as some previous test cases used amounts lower than the minimum wage. target: 19.0 task-5226971 Forward-Port-Of: odoo/enterprise#104668
This update fixes a problem preventing the correct automated sending of wage statements for Swiss payroll. The issue was resolved by correcting a process within the HR payroll module, ensuring accurate and timely delivery of these important documents. This ensures compliance and provides employees with the necessary financial information.
Original PR description
Forward-Port-Of: odoo/enterprise#107827
This update resolves a problem where salary inputs needed manual triggering, hindering the correct calculation of advance salary recovery. The changes improve the clarity and functionality of salary structure data files, ensuring accurate salary calculations and recovery processes. This fix addresses a technical detail impacting payroll accuracy.
Original PR description
Purpose: the salary inputs have to be manually triggered, which causes issues when it comes to populating the salary input for the advance salary recovery. Fix: moved the function `update_properties_definition_domain` to each salary structure data file to be more obvoius and removed `l10n_tr_hr_payroll_data` as the file wasn't in the manifest task-id: 5912475 Forward-Port-Of: odoo/enterprise#106576
This update fixes an issue where the system incorrectly rounded amounts when settling customer deposits (payments made via methods other than cash). Previously, rounding was always applied, regardless of the payment method. Now, the system respects cash rounding configurations and only rounds the deposit amount if the chosen payment method requires it, ensuring accurate accounting for all payment types.
Original PR description
Steps to reproduce: ------------------- 1. Enable cash rounding, only for cash payment method - Rounding method doesn't matter, I tested with 0.05 nearest rounding 2. In PoS, make an order with the…
Steps to reproduce: ------------------- 1. Enable cash rounding, only for cash payment method - Rounding method doesn't matter, I tested with 0.05 nearest rounding 2. In PoS, make an order with the customer account, such that the total amount is not divisible by 0.05, i.e. when rounded, it's not the same amount. For instance, $5.27. 3. Close the session and reopen it, then select that customer, and click settle due 4. Select the Bank payment method, so a NON-Cash payment method. Notice that the amount is being rounded, even though we have only enable rounding for cash methods. If we take my example of step 2, the amount became $5.25 instead of $5.27. That is understandable when we settle with Cash, however, for Bank (non-cash), we should not round. The fix ------- Now when choosing a payment method to settle due, we also round the amount if needed, in `getTotalDueOfPartner`. Before, we always set the exact amount, regardless of the payment method and the rounding settings. We now also apply rounding on the payment screen based on the selected payment method. Previously, the change was always rounded whenever rounding was enabled, ignoring whether rounding was restricted to cash methods. This behavior made sense for normal orders—where change is typically given in cash—but not when settling a due amount, since the customer can pay using any method. During due settlement, the change represents the amount the customer must pay, so rounding must follow the rules of the chosen payment method. opw-5222985 Forward-Port-Of: odoo/enterprise#105368 Forward-Port-Of: odoo/enterprise#100278
This update prevents discounts from being incorrectly reset when an upsell is added to a subscription order. Previously, an upsell would erase the original subscription discount. This change ensures that discounts are accurately applied across the entire order lifecycle, improving the accuracy of pricing and subscription revenue.
Original PR description
Before this commit, the discount of recurring lines in a sub would be reset in the following case: 1) create a sub, add a discount on recurring line 2) invoice the sub 3) create an upsell, add quanitty on the recurring product, change the start date of the upsell to trigger computation 4) confirm the upsell The discount of the parent order was reset. task-5886270 Forward-Port-Of: odoo/enterprise#105750