Wednesday, March 11, 2026
5 changes · 17.0
Resolved issues and error corrections
This update fixes an issue where large production quantities in Odoo's MRP module were causing errors. The fix ensures that the system correctly handles large production orders, preventing disruptions to manufacturing workflows. This improves the reliability of production planning and execution.
Original PR description
**Steps to repduce:** - Create `mrp.production` record with large number `Quantity` - Confirm and set same large `Quantity` value - Click on Produce all Button https://app.screencastify.com/v2/manage/videos/cy0tbiIT37R0KmST7FNv 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
This update fixes an issue where overpayments made via bank payment in Point of Sale didn't create the necessary accounting records. Now, when a customer pays more than the order total with a bank payment, a corresponding accounting line is created, ensuring accurate financial reporting. This prevents the system from incorrectly showing an outstanding balance.
Original PR description
If an order in overpaid using bank, no move line is created for the change. Steps to reproduce: ------------------- * Make an order, add a customer * During payment, select invoice, pay more than the order amount with bank pm * Validate * Close register * Check customer > Observation: It says we owe the customer money, although change was given. Why the fix: ------------ Since this fix: https://github.com/odoo/odoo/commit/2c4764f111eec154375d94eb7052a12c470a513d the change gets deducted from cash payment method. However the use case where there would not be any cash payment used was not taken into account. The previous fix was removing the change from the payment methods to subtract its amount from any cash payment but in the case where there's none nothing is done with it. Indeed it sometimes happen to pay a bit more in card to get some cash out. Currently, in this case, the change is just omitted. opw-5149700
This change corrects a naming error in the ZUGFeRD eInvoice XML file, resolving validation issues with several key e-invoice validators. Previously, the validator incorrectly flagged the file, but now the ZUGFeRD file passes validation across multiple platforms, ensuring proper e-invoice processing and compliance.
Original PR description
Fix the name of the embedded xml for zugferd eInvoice format. Before this PR: For the validator https://www.portinvoice.com/en/, the error > No, the file is called zugferd.xml. The following naming conventions are > permitted: “factur-x.xml”, “xrechnung.xml”, “zugferd-invoice.xml”, > “ZUGFeRD-invoice.xml”, “order-x.xml”, “cida.xml” And also: > The XML has a valid profile? No This corresponds to the document_context, as the french factur-x and the german ZUGFeRD are a common standard, we can put the same context. After this PR: The ZUGFeRD file passes on different validators. Validators: * https://erechnungs-validator.de/ * https://easyfirma.net/e-rechnung/validieren * https://www.portinvoice.com/en/ * https://demo.verapdf.org/ task-6010416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where generating financial reports (FAIA) for Luxembourg companies using multi-currency transactions resulted in errors. The fix ensures the necessary currency information is included in the report template, preventing rendering problems and ensuring accurate financial reporting.
Original PR description
Steps to reproduce 1/ setup a LU company. The default company currency will be EUR. 2/ create a vendor bill in another currecy (e.g. USD) 3/ take note of the bill date and accounting date (ideally set them in the past, like 1 month) 4/ generate the FAIA report for the period containing the created bill => error while rendering the qweb template The core of the error is when rendering the l10n_lu saft template. Sales invoices and purchase invoices reuse the standard `account_saft.tax_information` report, which expects to find `currency_code` in the object's fields. This commit explicitly re-adds it when creating the document's tax summary. opw-5216057
This update resolves an issue where appraisals marked as 'invisible to the manager' were incorrectly visible after switching companies within a multi-company setup. The fix ensures that appraisals remain hidden from managers when the employee and manager are in different companies, improving data security and user experience. This prevents managers from accessing appraisals they shouldn't see.
Original PR description
**Issue:** An employee's appraisal marked as "invisible to the manager" becomes visible to the manager when switching companies (the other company should be checked) **Steps to reproduce:** 1. Ensure the environment is configured for a multi-company setup (with both companies active). refer to the screenshot bellow  3. Create an appraisal as a user (e.g., demo): - Go to Appraisals -> New - Select an employee and a manager (e.g., Mitchell Admin) - Uncheck "Visible & Editable by Manager" - Confirm 4. Log out and log in as the chosen manager. 5. Go to the Appraisal Module. 6. Navigate to the previously created appraisal. 7. select the other company The feedback becomes visible when selecting the other company opw-4273581