Daily updates from Odoo
Thursday, June 12, 2025
5 changes
2 changes
Enhancements to existing features
This update adds support for the paper-muncher layout option in accounting report PDF exports. It helps ensure exported reports can use the intended paper formatting, improving consistency for printed or shared financial documents.
Original PR description
See https://github.com/odoo/odoo/pull/211226
Bank reconciliation now better identifies matching invoice payments by checking payment memos against bank statement labels, invoice references, partner, and amount. This reduces manual matching work and helps payments involving one or multiple invoices reconcile more accurately.
Original PR description
With this PR, we enhance the reconciliation logic by adding a check to match the payment memo against the bank statement line label. If a part of the memo is found exactly in the label and only one such match exists, the system proceeds to reconcile it based on a second matching criterion such as amount and/or partner.
3 changes
Enhancements to existing features
Argentine sales and purchase journals can now offer the Secondary Grain Liquidation document type when it has been activated. This lets businesses correctly register grain-related sale or purchase invoices using the official LSG document instead of being blocked by a missing option.
Original PR description
The grain secondary settlement ("Liquidación Secundaria de Granos" - LSG) is an electronic document that supports grain purchase and sale and consignment transactions between intermediaries,…
The grain secondary settlement ("Liquidación Secundaria de Granos" - LSG) is an electronic document that supports grain purchase and sale and consignment transactions between intermediaries, cooperatives, consignees, exporters, brokers and future market operators. This document is emitted by the intermediary of the operation so, in Odoo, if the user is the seller or purchaser of the operation, it will need to register that document in a sale or purchase journal accordingly.
This PR aims to include this document in the list of the available ones to allow the user to select it when registering either a sale or a purchase.
**Behaviour before this PR:**
When the user creates an invoice in a sale or purchase journal, the document type "331 - SECONDARY GRAIN LIQUIDATION" is not available to select, although it is activated.
**Behaviour after this PR:**
When the user creates an invoice in a sale or purchase journal, the document type "331 -SECONDARY GRAIN LIQUIDATION" is appears in the list of documents (the document type should be activated before)
**Steps to reproduce:**
1. Install l10n_ar
2. Go to "Document Types" menu and activate "331 - SECONDARY GRAIN LIQUIDATION"
3. Create or use a sale or purchase journal that has "Is AFIP POS?" as False.
4. Create an invoice in that journal and check that the document type with code 331 is not available to select.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe GSTR OTP flow now guides users to enter a valid 6-digit OTP before validation can proceed. It also shows clearer error and delivery messages, helping prevent failed submissions and reducing confusion about where the OTP is sent.
Original PR description
**Before this PR:** - The `Validate` button was always visible, even if the OTP was empty or incorrect. - Users could attempt validation with an invalid or missing OTP. - The OTP delivery message was unclear. **After this PR:** - The `Validate` button proceed done when a valid 6-digit numeric OTP is entered. - A clear error notification is shown if users try to proceed without a valid OTP. - The OTP delivery message now clearly informs that the OTP is sent to the registered mobile number on the GST portal. These changes improve user guidance and prevent incorrect OTP submissions. Task ID: 4848729
This update improves the message shown when a Mexican payroll calculation fails because an employee's integrated daily wage is below the minimum wage threshold used by the CEAV employer contribution rule. Payroll users now get a clearer explanation of what needs attention instead of a confusing technical error, making payslip troubleshooting easier.
Original PR description
Steps to reproduce: - Install payroll, l10n_mx_hr_payroll (mexican localisation) - Install l10n_mx_hr_payroll_account - Switch to a Mexican Company - Create a payslip for a mexican employee with…
Steps to reproduce: - Install payroll, l10n_mx_hr_payroll (mexican localisation) - Install l10n_mx_hr_payroll_account - Switch to a Mexican Company - Create a payslip for a mexican employee with amount < 4000 - Compute the sheet for the payslip Error message appears, this error message is not a descriptive to the user or not telling what could have gone wrong. This happens because the mexican pay structure has some salary rules that has to be computed, one of these rules is `Retirement, assault in elderly and old age (CEAV) IMSS (Employer)` that has mode of code. This mode means calling safe_eval on the code raw text of it written in the xml file on the data folder. This rule aims to find the suitable taxation level to be applied on the salary. It reads the limits of each level and check if the `integrated_daily_wage` of the employee falls in this level and applies that taxation level. There is no upper limit on the salary, But there is a min level, hence if the integrated_daily_wage < mdw (minimum daily wage) the function returns None that used as index in the taxation table leading to an unreadable Exception from the safe_eval call. https://github.com/odoo/enterprise/blob/747482f34ca8210d89d81b3363ec5a8fc3a4ff6f/l10n_mx_hr_payroll/data/salary_rules/hr_salary_rule_regular_pay_data.xml#L1111-L1120 opw-4576482