Friday, March 13, 2026
10 changes · 18.0
Resolved issues and error corrections
This update resolves an issue where credit notes were causing an infinite loop in a background process. The fix restricts the process to only monitor invoices, preventing unnecessary polling and ensuring efficient claim status updates. This improves system performance and stability.
Original PR description
Claimed credit notes (DTE 61) were being polled indefinitely by the _l10n_cl_ask_claim_status cron. The SII endpoint listarEventosHistDoc does not support DTE 61 and always returns codResp 3 "Tipo de…
Claimed credit notes (DTE 61) were being polled indefinitely by the _l10n_cl_ask_claim_status cron. The SII endpoint listarEventosHistDoc does not support DTE 61 and always returns codResp 3 "Tipo de documento no corresponde". Since the response never contains event data, l10n_cl_claim is never set, the record permanently matches the cron domain, and polling repeats every 4 hours forever. Root cause: the cron domain included out_refund move types, but the SII endpoint used to fetch claim events does not support credit note document types. There is no point querying the SII for claim details on credit notes through this endpoint. Fix: restrict the cron domain to out_invoice only Before: claimed credit notes matched the cron domain, _get_dte_claim was called on every run, SII returned codResp 3, l10n_cl_claim stayed False, record never exited the domain. After: credit notes are excluded from the cron domain entirely and are never polled, stopping the infinite loop. opw-5933833
This update ensures that each self-order transaction receives a unique tracking number. Previously, all self-order orders displayed the same number, making it difficult to track individual orders. This fix resolves an accidental removal of a key line of code, restoring the correct tracking number generation.
Original PR description
Currently, all self order orders are showing the same tracking number. Steps to reproduce: ------------------- * Open restaurant config and enable self ordering * Open self in a first private navigator, place an order > Tracking number shows 500 * Close navigator and open a new one * Open self, place an order > Tracking number shows 500 Why the fix: ------------ The line re-introduced was removed here https://github.com/odoo/odoo/commit/f6e94c794c1ac685f1229835279ded5ea686cfad by accident, as the upper versions of the commit are still using it. opw-6022132
This update resolves a technical issue where the menu toggle's SVG icon was not displaying correctly in some browsers. The fix ensures the arrow tip is rounded, preventing it from appearing truncated and improving the overall visual appearance of the application. This ensures a consistent and professional user experience.
Original PR description
Before this commit, some browsers showed a warning or, even worse, dropped this CSS rule because the unit was missing. This line ensures that the tip of the arrow is rounded instead of truncated. 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 resolves an issue where a regex used during vendor bill processing would fail when encountering unexpected data types (specifically, False). The fix ensures the regex only operates on valid string values, improving the reliability of bill import and preventing errors. This change enhances the stability of the account management process.
Original PR description
The issue occurred because a test regex was applied to a non-string value. In some cases the value was False, which caused the operation to fail. Steps to reproduce: - Import a vendor bill - Remove the product and the label from one line, then post the bill - Import another bill (or the same bill)from the same supplier - An error occurs when the regex tries to match a non-string value This change ensures the regex is only applied to valid strings. It also improves the code by extracting the static part of the regex into a dedicated variable. opw-6019298 opw-6030364 opw-6033013 opw-6032608 opw-6032546 Forward-Port-Of: odoo/odoo#253576
This fix addresses an issue where portal users could access and potentially modify draft sales quotations after receiving a message. The change prevents sending draft quotations to customers, ensuring that orders remain in their intended draft state. This resolves a potential risk of unauthorized modifications to sales orders.
Original PR description
Issue: --- Draft quotation can be accessed by portal user if a message is sent to portal user. They can sign and pay the quotation. Steps to reproduce: --- 1- Create a SO with portal user as partner. Don't confirm it. 2- Using chatter, send a message to the partner. 3- Open the email. You can access the quotation using portal user which is not expected. Cause: --- After #124486, portal users can accept or pay the draft sale orders if they can access the quote. Fix: --- We can prevent sending quotation to customers when the order is in draft state. opw-5969465
This update fixes a labeling issue in the invoice payment widget for Indian companies using the l10n_in_withholding module. Previously, TDS entries incorrectly displayed 'Paid on' instead of 'TDS on,' causing confusion. This change ensures accurate labeling for tax withholdings, improving clarity and compliance.
Original PR description
### Issue before this commit: When generating a TDS entry for an Indian company, the payment widget on the invoice incorrectly displays the label "Paid on" instead of "TDS on," failing to distinguish…
### Issue before this commit: When generating a TDS entry for an Indian company, the payment widget on the invoice incorrectly displays the label "Paid on" instead of "TDS on," failing to distinguish tax withholdings from standard payments. ### Steps to reproduce the issue: 1. Install l10n_in and switch to IN company 2. Go to settings and activate TDS and TCS 3. Create an invoice setting a certain price and confirm it 4. Click on the 'TDS entry' button 5. Set a random TDS tax and the base amount equal the one of the invoice 6. Confirm it and see there is the label "Paid on" and not "TDS on" ### Cause of the issue: The invoice payments widget determines the label displayed for each reconciled entry based on predefined flags. However, entries created for TDS withholding were not explicitly identified in the widget data. As a result, these entries were treated as regular payments and the label "Paid on" was displayed instead of a more appropriate label indicating that the entry corresponds to a TDS withholding transaction. ### Reason to introduce the fix: The label "Paid on" is conceptually incorrect for TDS transactions because no actual payment or cash outflow has occurred since TDS is a tax withholding rather than a monetary settlement. Using "Paid on" creates confusion for the user, as it implies a transfer of funds that does not exist in this context. opw-5952700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue preventing the correct generation of Luxembourg's SAFT reports when dealing with multi-currency transactions. The fix ensures the necessary currency information is included in the report template, allowing accurate reporting for vendors and compliance.
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 Forward-Port-Of: odoo/enterprise#106902
This update resolves an issue where GS1 barcode filtering in the stock module would fail due to an incorrect date interpretation. The fix prevents validation errors from blocking product filtering, ensuring internal transfers are correctly processed based on barcode data. This improves the reliability of barcode-based product selection.
Original PR description
Steps to reproduce: - Activate the GS1 nomenclature - Create a product "P1" with the barcode: 15099590225865 - Create an internal transfer with one unit of P1 - Go to Barcode > Operations > Internal…
Steps to reproduce: - Activate the GS1 nomenclature - Create a product "P1" with the barcode: 15099590225865 - Create an internal transfer with one unit of P1 - Go to Barcode > Operations > Internal Transfers - Scan the barcode: 15099590225865 to filter transfers by this product barcode Problem: An validation error is raised: A ValidationError is raised: "A GS1 barcode nomenclature pattern was matched. However, the barcode failed to be converted to a valid date." Explanation: GS1 barcodes must follow a strict nomenclature based on well-defined rules. For example, a GS1 product barcode should start with the Application Identifier 01 followed by 14 digits. The GS1 parser processes the barcode rule by rule and applies the first matching rule. In this case, the barcode 15099590483921 is interpreted as a date because it starts with "15", which corresponds to a GS1 Application Identifier for a date. As a result, the parser attempts to convert the first six digits into a date and raises a ValidationError. Solution: Catch the ValidationError raised during GS1 date parsing in filter_on_barcode and explicitly reset parsed_results to False, allowing the normal filter on product resolution logic to continue. This prevents GS1 parsing errors from blocking valid barcodes and ensures that product is correctly filtered opw-5929064
This update fixes an issue where timesheet descriptions were not consistently updating when values were changed within the grid view. The fix ensures that new timesheet lines created after a value update retain the original description, maintaining accurate reporting. This improves data integrity and user experience.
Original PR description
To reproduce: ============= - on timesheet group by Project > Task > Description - on a line with a description, update a 0:00 cell to an other value - refresh or change view to list and back to grid - a new line with description '/' is created with the updated value Problem: ======== when creating the new timesheet it's by default given the name '/' which for the grid view is not in same group as the original line with the description. Solution: ========= when creating the new timesheet, we give it the same description as the original line. opw-5909249 Forward-Port-Of: odoo/enterprise#108894
This update resolves a problem where account move references were sometimes missing when the l10n_jo_edi_pos module was installed. The fix ensures that the 'ref' field in account moves created from POS orders is correctly populated, regardless of the country setting. This prevents errors and ensures proper accounting processing.
Original PR description
Before this commit, an override of _prepare_invoice_vals in l10n_jo_edi_pos was setting the ref field of the created account move to l10n_jo_edi_pos_return_reason, which was False when the country was not Jordan. This was causing the ref to be unset for every move created from a pos order when the module was installed but the field l10n_jo_edi_pos_return_reason was not set. This is now fixed by taking the value of the field if set, else take the original value. runbot-error: 241014 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr