Daily updates from Odoo
Friday, November 21, 2025
38 changes · 18.0
Enhancements to existing features
This update corrects how VAT values are calculated in the Indonesian E-Faktur Coretax export so the XML now uses the right tax grouping instead of relying on invoice type in some cases. It also adds a safeguard to prevent invalid tax combinations, helping reduce reporting errors and improving consistency in tax documents.
Original PR description
Update Coretax XML file to compute the values for nodes in the correct way. Currently the computation is based on the invoice type for some of the nodes + STLG is based on wrong tax group. This leads to wrong computation of values + inflexibility. - Update the VAT calculation inside the E-faktur XML based on tax group - Add new tax group and modify existing tax - Add restriction when downloading E-faktur Coretax XML Task [#4948267](https://www.odoo.com/odoo/project.task/4948267) Forward-Port-Of: odoo/odoo#233347
The payroll payment report for Swiss companies now defaults to the Swiss ISO 20022 format instead of the generic SEPA option. This makes payroll exports easier to use correctly out of the box and reduces the need for manual selection.
Original PR description
Previously the sepa and iso20022_ch were together in the hr_payroll_account_iso20022 module, but we needed to separate between them so that for the ch localization we have the export format, iso20022_ch, to be the default value when we're on the swiss company. task-5189295
This change improves how GSTR-2B issues are handled by recognizing an additional error code and treating it as a warning instead of leaving it unhandled. It also stops scheduled checks from retrying records already marked with errors, which reduces unnecessary processing and helps keep return period status handling cleaner and more reliable.
Original PR description
Before this commit: - `RET2B1017` error code was not handled. - Cron methods `_cron_get_gstr2b_data` and `_cron_gstr2b_match_data` processed all records with status: - `"waiting_reception"` - `"being_processed"` - Records with blocking level `"error"` were still being processed by cron. After this commit: - Added handling for `RET2B1017` and mapped it to `"warning"` level. - Updated cron domain filters to exclude records where `gstr2b_blocking_level = "error"`. - Cron jobs now skip invalid/error-state return periods, preventing unnecessary processing. Forward-Port-Of: odoo/enterprise#99378
This update makes the test runner more forgiving when no tests are found, avoiding an error and recording the situation as a log instead. It also improves how test results are reported at the end of a run in headless mode, making debugging easier and test output clearer.
Original PR description
[FIX] web: Hoot - remove error if no tests This commit replaces the error thrown if there is no test found by a log. --- [IMP] web: Hoot - log root suites at end of run This commit makes the unit test runner log all root suites results after each test run, only in headless mode.
This update automatically creates the buyer record on ECPay before sending B2B invoices when needed. It helps prevent invoice issuance failures caused by missing buyer identifiers, and also validates VAT locally earlier to reduce avoidable errors.
Original PR description
This commit aims to address an edge case where the buyer identifier might not exist on ECPay before issuing a B2B invoice. A call to "Add" a customer is made. RtnCode 1 indicates successful creation, 6160052 - indicates buyer already exists, others are failure. Additionally, add "base_vat" as dependency to enable client-sided validation for VAT before sending to ECPay. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change avoids running extra stock processing when a package is already empty. It reduces unnecessary work during unpacking, which can make the user experience faster and more responsive.
Original PR description
For an empty package the `quant_tasks` function will be executed without restriction of scope and can potentially slow the user request intensly. And if there is no quants in the package the tasks are not necessary. After the unpacking of the quants they are not in the package anymore. Causing the call to quant_tasks to be done on an empty recordset. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update lets users set the Saudi e-invoice issue date manually before confirming an invoice, so documents can be backdated when needed. It helps keep Odoo’s invoice periods aligned with ZATCA’s VAT calculations, reducing the risk of invoices ending up in the wrong tax return period.
Original PR description
Previously, l10n_sa_confirmation_datetime was automatically set when invoices were confirmed, causing issues when users needed to backdate invoices. This created mismatches between Odoo's invoice date recognition and ZATCA's VAT liability calculation, forcing invoices into wrong tax return periods. Changes: - Expose l10n_sa_confirmation_datetime as "Issue Date" in form view - Allow manual setting of l10n_sa_confirmation_datetime before invoice confirmation - Preserve original Issue Date for rejected Phase 2 invoices (400 errors) - Hide Invoice Date field but sync it with Issue Date - Update PDF to display Issue Date instead of Invoice Date - Remove footer date from PDF - Extend future date validation to include Issue Date task-5009969 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229517
The system now waits longer between homepage data refreshes when a browser tab stays open for a long time. This reduces unnecessary traffic to the IoT Box while still keeping the homepage information up to date.
Original PR description
In order to avoid spamming the IoT Box with requests to update the homepage when a tab is kept open, we now progressively delay the `/data` fetch during the first 30min to end up fetching only once every 30min. Forward-Port-Of: odoo/odoo#236664
Resolved issues and error corrections
This change prevents website page saves from crashing when an embedded code block is missing required attributes. Instead of failing with an internal error, the system now validates the content and raises a clearer message, making editing more reliable for website users.
Original PR description
Currently, an error occurs when saving a website page that contains an embedded element missing the `'data-oe-type'`, `'data-oe-field'`, or `both` attributes. **Steps to produce:** - Install the…
Currently, an error occurs when saving a website page that contains an embedded
element missing the `'data-oe-type'`, `'data-oe-field'`, or `both` attributes.
**Steps to produce:**
- Install the `website` module.
- Open the `Website` app and click `Edit`.
- Drag an `Embed Code` block and add one of the following examples:
`<span data-oe-field='name' data-oe-model='res.partner' />`
or
`<span data-oe-type='int' data-oe-model='res.partner' />`
- Try to `Save` it.
**Error:**
`TypeError: can only concatenate str (not 'NoneType') to str `
`KeyError: None`
**Root Cause:**
At [1], the code tries to concatenate `'ir.qweb.field.' + el.get('data-oe-type')`,
but when `data-oe-type` is missing, `el.get('data-oe-type')` returns `None`,
causing an `error`.
At [2], when the `data-oe-field` attribute is missing, the code
tries to access `Model._fields[field]`, resulting in an `error`.
**Fix:**
This commit adds validation for missing attributes in the embedded
element, ensuring a clear error message is raised instead of a crash.
[1]:
https://github.com/odoo/odoo/blob/4fca401148ed798b9c1d04674b44c3287ded5679/addons/web_editor/models/ir_ui_view.py#L67
[2]:
https://github.com/odoo/odoo/blob/4fca401148ed798b9c1d04674b44c3287ded5679/addons/web_editor/models/ir_ui_view.py#L71
sentry–6675421840Invoicing-only users in the India localization could hit an access error when creating or posting invoices. This update gives the invoicing group the read access it needs, so invoice processing works smoothly when the related accounting features are installed.
Original PR description
In India localization, invoicing-only users were getting an AccessError on `account.fiscal.year` when creating or posting invoices. This happened when both l10n_in_withholding and account_accountant modules were installed. Added missing read access for the invoicing group to resolve the issue. Reference computation: During computation of TDS/TCS, warning `compute_fiscalyear_dates` method is called https://github.com/odoo/odoo/blob/7afe40e50d88448dd966d20f5ae7ac84d986e405/addons/l10n_in_withholding/models/account_move.py#L124 In the `compute_fiscalyear_dates` method, it searches for 'account.fiscal.year' records https://github.com/odoo/enterprise/blob/f79601c62ca629dc01a5c1ad5520b0bb44a169d0/account_accountant/models/res_company.py#L162 As invoicing-only users don't have access to 'account.fiscal.year' records It will raise AccessError Task-5346551
This fix makes website anchor links behave as users expect when “Open in New Window” is enabled. Instead of staying in the same tab and scrolling on the page, the link now opens in a new tab while still jumping to the selected section.
Original PR description
Steps to Reproduce: 1. Create an anchor link for any dropped snippet. 2. Insert the link through the link popover. 3. Enable the "Open in New Window" option. 4. Click on Save. 5. Click on the link. Issue: Even though the "Open in New Window" option is enabled, the page scrolls in the same tab instead of opening in a new window and scrolling to the targeted view. Reason: When an anchor link has target="_blank", `ev.preventDefault()` was still being called, which prevented the browser from performing its default behavior of opening the link in a new tab. Fix: Removed `ev.preventDefault()` for such links, as the expected behavior is to open them in a new tab whenever target="_blank" is set. Additionally, the offcanvas mobile-specific logic has been removed, as it is no longer necessary now that `ev.preventDefault()` is no longer used. task-5104027 Forward-Port-Of: odoo/odoo#228787
This change prevents Odoo from showing an unexpected traceback when Egypt’s ETA rejects an e-invoice download request and the response cannot be read as JSON. Instead, the error is now handled properly, resulting in a smoother and clearer user experience when a request fails.
Original PR description
Before this commit: Steps 1) When clients try to download e-invoice for ETA 2) If ETA rejects the request, Odoo fails to parse to JSON 3) a JSONDecodeError exception is raised 4) Odoo doesn't catch it and a traceback is raised => A JSONDecodeError is raised but actually it's not json.decoder.JSONDecodeError, it's actually requests.exceptions.JSONDecodeError as mentioned here https://requests.readthedocs.io/en/latest/api/#requests.JSONDecodeError After this commit: If the request is rejected and Odoo failed to parse the response to JSON the exception is catched properly. opw-5241411 opw-5272195 Forward-Port-Of: odoo/odoo#236672
This update fixes a layout issue that could hide or break the exchange rate section on printed invoices when multiple GCC localization apps are installed together. It helps ensure invoices render correctly for affected companies, especially when using a foreign currency.
Original PR description
Steps to reproduce: - install l10n_ae - switch to AE company - create an invoice with a currency != AED and print -> exchange rate shows - install l10n_sa_edi - print the invoice with the AE company The main issue is that l10n_gcc_invoice is a template for 5 different countries, and all of them inherit it without primary=True, which results in many conflicts if several of these countries are installed on the database. Here, we only try to solve the most apparent issue, which is the broken template for the exchange rates. Note that in 19, a major PR has been fixing this inheriting issue: https://github.com/odoo/odoo/commit/1cddcab8b8626b34c437a51d320b0a3e4698dae7 opw-5215971 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Certification lines now refresh their status color correctly when a certificate passes its end date. This ensures the Certifications report reflects the current situation without requiring any manual change.
Original PR description
**Steps to reproduce:** 1. Install `hr_skills_survey` 2. Go to Employees > Reporting > Certifications. 3. Create a certification line with a future end date → record shows in black. 4. Change the system date to after the end date. **Issue:** - The line color is not updated when time passes. **Cause:** https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/hr_skills_survey/models/hr_resume_line.py#L17 https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/hr_skills_survey/views/hr_employee_certification_views.xml#L7 - The color was based on the stored computed field `expiration_status`, which only depends on `date_end`. Since `date_end` does not change with time, the field value is not recomputed daily. **Solution:** - Introduce a non-stored computed field `expiration_status_ui`, depending on `date_end` and use it in the view to update expiration_status. opw-5065185
This fix prevents the system from mixing different products when calculating average cost during stock valuation. As a result, validating returns and related deliveries works reliably, avoiding an error that could block normal warehouse operations.
Original PR description
When duplicating a delivery linked to a sale order and changing the product on the duplicated picking, validating the return could lead to an error when validating the original picking of the initial…
When duplicating a delivery linked to a sale order and changing the product on the duplicated picking, validating the return could lead to an error when validating the original picking of the initial product. The issue occurred because the average price computation was mixing stock moves of different products when consuming valuation layers, leading to a UoM singleton error. Steps to reproduce: - Create storable products P1 and P2: - Category: AVCO - P1 UoM: Unit - P2 UoM: Dozen - Create a sale order with 1 unit of P1 - Confirm the SO - Open the generated picking - Duplicate it → a new picking is created and still linked to the same SO - Change the product on the duplicated picking to P2 - Confirm and validate it - Create a return on this picking and validate it - Go back to the original picking of P1 and try to validate it Problem: A UserError is raised due to mixed products in the average price computation, resulting in a “Expected singleton: uom.uom(...)” This fix ensures that average price is computed only using stock moves belonging to the same product. opw-5027089
This change fixes an access issue that prevented invoicing-only users from opening or creating invoices when a TDS/TCS warning was present. As a result, teams with limited invoicing access can continue their work without unexpected permission errors.
Original PR description
Invoicing users were unable to create or open invoices because the `l10n_in.section.alert` model (used for TDS/TCS warning on the chart of account) was restricted only to Accounting groups (Administrator and Read-only). **Steps to Reproduce** 1. Install l10n_in,account_accountant 2. Create two users: - Admin user - Invoicing user (only invoicing rights) 3. As Admin: - Enable TDS/TCS module - Open any Chart of Account - Select a TDS/TCS Section - Save 4. As Invoicing user: - Try to create an Invoice/Bill with that Chart of Account → Access Error occurs Fix Result Invoicing-only users can now create and access invoices without access errors. Task-5346551
This fix makes the vendor on-time delivery rate display the same value in the smart button and the graph. It now calculates against the original purchase order quantity, so partial receipts and duplicated receipts no longer distort the result.
Original PR description
**Steps to reproduce:** 1- Install the purchase_stock module. 2- Create a new PO with a new vendor. 3- Add new one product in the purchase order line with quantity > 1. 4- Confirm the PO and go to…
**Steps to reproduce:** 1- Install the purchase_stock module. 2- Create a new PO with a new vendor. 3- Add new one product in the purchase order line with quantity > 1. 4- Confirm the PO and go to the generated receipt. 5- Validate the receipt with less than the ordered quantity, by choosing no backorder. 6- Duplicate the receipt for the remaining quantity and validate it. 7- In vendor form view, the On-time Rate value shown in the smart button differs from the value in the graph. **Issue:** https://github.com/odoo/odoo/blob/e7da32fe67cfe78bc6da8bf5d36a7c584763e3bb/addons/purchase_stock/report/vendor_delay_report.py#L26-L42 - The On-time Rate shown in the smart button does not match the graph. **Example:** - PO Line ordered qty: 10 - First receipt validated: 6 (no backorder) - Duplicated receipt validated: 4 - In vendor form view inside On-time Rate Smart button - Total quantity coming: 14 (incorrect) - Expected total qty for calculation: 10 (from PO line) - On-time delivery rate calculated: **71.43%** - Expected On-time delivery rate: **100%** **Cause:** - The report uses `product_qty` from the stock move. - When a receipt is duplicated and the demand quantity is manually set, `product_qty` is recomputed from this demand value. This leads to a mismatch between the PO line quantity and the aggregated stock move quantities. **NOTE:** In `test_02_vendor_delay_report_partially_cancelled_purchase_order`, added the line:: `purchase_order.order_line.flush_recordset()` - Because we were taking the `partner_id` from the `Purchase Order line` is a stored related field. - The computed value first lives in Odoo’s cache. - It is not written to the database until a flush occurs. - If we immediately call something like _read_group() (which queries the database directly), it won’t see the cached value — only what is persisted in the DB. **Solution:** - Use the purchase order line quantity instead of the stock move’s `product_qty` to ensure consistent and accurate On-time Rate calculation. opw-4991367 Forward-Port-Of: odoo/odoo#225529
The Documents settings page now shows clearer labels and helper text for each access right option. This makes it easier for administrators to understand what each permission does and choose the right setting with confidence.
Original PR description
This commit fix the label of documents access rights which now shows a helper for each documents res.groups. Task-5186096
Exchange rates from the Swiss Federal Tax Administration are now saved with the correct publication date instead of the later validity date. This ensures the dates shown in Odoo match the actual rate information received from the source.
Original PR description
Steps to reproduce: - Select exchange service: [CH] Federal Tax Administration (FTA). - Add USD (or other currencies). - Fetch the new rates (click on the reload icon). Issue: Rates are returned for yesterday but stored with today’s date. Cause: The request fetches yesterday’s rates and we store the date using `gueltigkeit` (valid-until). FTA rates are typically valid until the next morning (around 7 AM) or until the next business day on weekends. Example (fetch on Fri 14.11.2025): <gueltigkeit>15.11.2025,16.11.2025,17.11.2025</gueltigkeit> For example, if we fetch on the 14th (Friday), we get this value: <gueltigkeit>15.11.2025,16.11.2025,17.11.2025</gueltigkeit> Solution: Query the FTA endpoint using today’s date and store the rate date from `datum` (publication date) instead of `gueltigkeit`. opw-5189127
The Italian “Libro Giornale” report was affecting all journal reports in some cases, which could remove journal names from exported PDFs. This update limits the custom formatting to the correct Italian report only, so other companies’ journal reports display properly again.
Original PR description
The custom template for the report "Libro Giornale" was neither inheriting with primary neither using conditions on the country code. Therefore, the xpaths applied were for all the journal reports, whatever the company. For example, when exporting the regular journal report, the names of the journals no longer appeared once the module l10n_it_reports was installed on a database. opw-5217520
This change restores the expected payment setup for standard ISO 20022 bank transfers. Payments now automatically use the NURG service level as before, which helps ensure the correct processing of non-SEPA transactions.
Original PR description
Since commit [[1]], the Service Level is set to NURG only when using the specific `iso20022_se` payment method. However, the previous expected behavior was to set the Service Level to NURG automatically whenever a payment was in a non-EUR currency or targeted a non-EU IBAN, regardless of the specific ISO20022 variant. This commit restores the logic to set the Service Level to NURG for all standard ISO20022 payments. This fix doesn't check anymore if a payment is in non-EUR currency or target a non-EU IBAN. Using iso_20022 activate it by default. opw-5095483 [1]: https://github.com/odoo/enterprise/commit/67593e5ff9b3a5187a1535bc8fc89590b4c9401e
This change makes Odoo more reliable when linking incoming supplier bills to their related purchase orders. It now ignores tiny price differences that are within the normal product price rounding, so valid matches are no longer missed because of insignificant decimal variations.
Original PR description
Fixes Task 5213234 Issue: In AccountMove method _find_matching_po_and_inv_lines (called when looking for a subset match of EDI invoice lines with PO lines), the price_unit of a purchase.order.line is…
Fixes Task 5213234 Issue: In AccountMove method _find_matching_po_and_inv_lines (called when looking for a subset match of EDI invoice lines with PO lines), the price_unit of a purchase.order.line is compared to the price_unit of an invoice line. However, currently the comparisons do not take into account the precision to be applied to product prices. In some cases, the invoice line price_unit differs from the price_unit in a PO line, but by less than the "Product Price" precision. With the current comparisons this leads to not matching the lines. This has prevented matching some invoices received via Peppol for at least one big customer (see Task-5213234) Steps to reproduce: - Create an XML document for an EDI UBL invoice with 2 lines; the first line has a price_unit 113.57 euros (for example) - Create a PO with a reference matching the invoice, and one PO line with a price_unit matching the price_unit of the first invoice line (113.57 euros) - Upload the XML invoice and create a bill from it; during the creation of the account.move.line, the price_unit gets a value which is slightly different from 113.57 (113.57000000000001) (due to python rounding ?) - Result: no link is established between the PO and the invoice. This fix makes sure that the "Product Price" precision is used when comparing the invoice line price_unit with a PO line price_unit. opw-5213234 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232527
This update prevents the interface from displaying the word “undefined” when a hidden section is skipped during page rendering. In full-size forms, it ensures empty spaces stay clean instead of showing stray text where buttons or controls would normally appear.
Original PR description
Currently if the root node of a template is invisible at compile time the "new root" will contain the word "undefined" in plain text. Instead if we skip rendering the root for whatever reason, the new root should simply be an empty t node. This lead to issues in full-size forms specifically as the controller compiles the buttons separately. Meaning if the buttons div was evaluated to be invisible for whatever reason you would get "undefined" where stats buttons normally go. task-5322823 Forward-Port-Of: odoo/odoo#236461
This update corrects the French Balance Sheet so it stays balanced when using the 2024 chart of accounts. It restores missing income and expense amounts in the retained earnings calculation, which helps ensure accurate financial reports for companies using the French localization.
Original PR description
[FIX] l10n_fr_reports: unbalanced Balance Sheet when coming from the 2024 CoA https://github.com/odoo/odoo/commit/8f3a86925e0301c15ca93b64d6237b69a534d71a introduced a new version of the French CoA, legally mandatory starting in 2025. Doing so, it also adapted the P&L and BS reports accordingly. However, it did not take into account the fact that some deprecated account codes would disappear from the P&L, causing the BS to be unbalanced when computing the retained earnings (by calling the P&L with a forced date_scope to run it on the full history). We fix that by reinjecting the balance of the missing Income and Expense accounts in the computation of the BS's Retained Earnings line. opw-5212801
This update corrects missing settings on several Philippine tax tags so they are treated properly in tax calculations. As a result, tax reports will no longer show incorrect figures for affected cases.
Original PR description
This commit sets tax_negate to true to (-QAPA, -QAPB, -SAWTA, -SAWTB). They were missing and impacted a tax report falsely. opw-5157090
This fix prevents parent folders from automatically expanding when a user opens a folder inside them. It makes folder navigation in Documents more predictable and keeps the folder tree easier to scan.
Original PR description
Steps to reproduce =================== - Go to the `All` section. - Open the folder hosted in the `My Drive`. - `My Drive` gets unfolded. To Be ===== - The` My Drive` folder should not be unfolded when opening folders inside it, like `Company`. Technical =========== - Earlier, we were sticking to the condition that allows other root folders to unfold when we open a folder inside it, except the `Company` folder. After this commit ================== - This commit addresses the issue, and now whenever we click on a certain folder it will not unfold until its root is unfolded. Task-5046161
Users can now create reordering rules for a product in one company even if that product has a kit bill of materials defined in another company. This fixes an incorrect validation error and prevents kit settings from one company from blocking operations in another.
Original PR description
Steps to reproduce: - Create a storable product "P1" - Add a kit BoM restricted to Company A - Switch to Company B - Try to create an orderpoint for "P1" in Company B Issue: A validation error is raised: "A product with a kit-type bill of materials cannot have a reordering rule." Cause: The check did not consider the company of the BoM, so kit BoMs defined in other companies incorrectly blocked orderpoint creation. Solution: Add the company condition in the BoM search domain to ensure that only BoMs belonging to the same company (or global ones) are considered. opw-5158491 Forward-Port-Of: odoo/odoo#232685
This update stops users from changing the product on combo item lines by mistake or misuse. Description edits are still possible, but users now need to hide the product-related columns first, which helps keep combo orders accurate.
Original PR description
This was initially allowed so that the user could edit the description on combo item lines (since both the product and description fields are displayed in a single column). However, users seem to abuse this (see https://github.com/odoo/odoo/pull/234090). For information, the description can still be edited, but to do so, the user must first hide the `Product` and `Product variant` columns (which can be shown again after making the necessary changes).
This fix allows users with invoicing-only permissions to create and open invoices even when a TDS/TCS warning is set on the chart of accounts. It removes an access error that was blocking normal invoicing work for those users.
Original PR description
Invoicing users were unable to create or open invoices because the `l10n_in.section.alert` model (used for TDS/TCS warning on the chart of account) was restricted only to Accounting groups (Administrator and Read-only). **Steps to Reproduce** 1. Install l10n_in,account_accountant 2. Create two users: - Admin user - Invoicing user (only invoicing rights) 3. As Admin: - Enable TDS/TCS module - Open any Chart of Account - Select a TDS/TCS Section - Save 4. As Invoicing user: - Try to create an Invoice/Bill with that Chart of Account → Access Error occurs Fix Result Invoicing-only users can now create and access invoices without access errors. Task-5346551
This update prevents import failures when users upload CSV files encoded in UTF-16. Instead of crashing with a low-level decoding error, Odoo now shows a clearer warning, making it easier to understand and resolve the problem.
Original PR description
Currently, an error occurs when importing CSV files encoded in utf-16. **Steps to reproduce:** - Install the `account_bank_statement_import_csv` module. - Open invoicing and upload file [1] in Bank transactions. - Change the encoding to `utf-16` and click `test`. **Error:** `UnicodeDecodeError: 'utf-16-le' codec can't decode byte 0x0a in position 376: truncated data` **Root Cause:** At [2], the CSV data is decoded strictly with the specified encoding. When decoding detects incomplete or unexpected byte sequences, Python raises an `error`. **Fix:** This commit ensures raising a `warning`, improving the `error message clarity`. [1]: https://drive.google.com/file/d/14thHRN210aeY8fcUBAb01PniVrd7QHer/view?usp=sharing [2]: https://github.com/odoo/odoo/blob/67503c0ce7ede8373800caa0a12203d271b7f1ae/addons/base_import/models/base_import.py#L544 sentry-6864546266
For Canadian companies that close their fiscal year on a date other than December 31, the tax report now lets them choose a different start date. This helps ensure annual filings are calculated on the correct period and avoids issues with closing dates.
Original PR description
If a user from CA has a fiscal year on something other than the 31/12 and needs to return annually, he can't do his closing on the right bounds. We now allow CA to show the field to be able to shift it, as government allow it. Later, we will change the heuristic to be smarter to show it as soon as it may cause issue. opw-5193999
This fix restores the missing date scope settings on some Balance Sheet lines used in cross-report links. As a result, the report will show figures for the intended period more consistently, reducing the risk of confusing or incomplete financial comparisons.
Original PR description
Forward-Port-Of: odoo/enterprise#99889
The German DATEV export now correctly reflects bills where the tax amount was manually adjusted. This prevents mismatches between what users see in accounting reports and what gets exported for tax and audit purposes.
Original PR description
- Install Accounting and `l10n_de_reports` - Switch to a German company - Create a bill: * Price: `100.00` * Taxes: `19%` - Edit the tax total with the pencil button - Go to "Accounting / Reporting / Audit Reports / General Ledger" => The tax amount is the one that has been edited manually - Download `Datev DATA (zip)` - Open `EXTF_accounting_entries.csv` file The total amount in the file is the one before the edition of the tax amount. The Datev data depends on `price_total` field of the invoice lines, but this field is not updated when the tax amount is edited manually. We now check the total by adding `price_total` of each invoice line and the total amount defined in `tax_totals` field. If there is a difference, compute the delta for each tax group and split it between all the lines where a tax of that group is used. Ticket [link](https://www.odoo.com/odoo/project.task/4951488) opw-4951488 Forward-Port-Of: odoo/enterprise#98684
The system now uses the current official state code for Odisha in India. This avoids incorrect location data when creating contacts and related documents like sales orders.
Original PR description
**Steps to reproduce:** 1. Install the `Contacts` module. 2. Go to Contacts > Create a new contact. 3. Select country India, and state Odisha. 4. Create a sales order using the newly created contact. **Issue:** As per [Government of India](https://www.iso.org/obp/ui/#iso:code:3166:IN), the state code was officially changed from "OR" to "OD" in 2023. However, Odoo still uses the outdated code. <img width="407" height="163" alt="image" src="https://github.com/user-attachments/assets/1631a831-f455-4a51-886f-7e4ed691add0" /> **Solution:** Update the name of the state from "OR" to "OD" in state records. **opw-4935633** Forward-Port-Of: odoo/odoo#234697
The planning analysis report now correctly checks whether a shift falls within working hours before counting it in a given month. This prevents hours from being wrongly assigned to the next month when a shift ends outside normal working time.
Original PR description
### Steps to reproduce: - Create an employee with fixed working schedule from 8 to 5 - Create a Planning shift for this employee that starts in a month and ends in the first day of the next month outside of working hours (e.g. Sept30th 8AM -> Oct1st 2AM) - Navigate to Timesheets / Planning analysis reports - Notice October has been taken into consideration in the report's planned hours ### Cause: The query we are using for the timesheets/planning report doesn't take working hours into consideration it only cares about the date. So if the shift ends in October 1st we are taking it into account whether it is inside working hours or not. ### Fix: Add a condition to the where clause to check the working hours and if the record lays in this period or not. opw-5089052 Forward-Port-Of: odoo/enterprise#96846
This fix restores the ability to edit timesheet entries that are linked to an invoice after that invoice has been reversed. It helps teams correct recorded hours even when the original billing document has been canceled and replaced by a credit note.
Original PR description
**Issue:** Timesheet entries linked to reversed invoices are uneditable. **Steps to reproduce:** - Create a service product invoiced by timesheets, and create a project & task. - In Sales, create a new quotation with the product. - Confirm the quotation, click on the task, and create a timesheet entry. - Create an invoice from the quotation. - Confirm the invoice, add a credit note, and reverse the invoice. - Go to the reversed invoice and access the timesheet through recorded hours. the timesheet entry is uneditable, even though the invoice is reversed. opw-4633121 Forward-Port-Of: odoo/odoo#234108 Forward-Port-Of: odoo/odoo#201921
This change fixes how Mail’s automated tests simulate browser environments. It ensures the test tool is used with the intended device/platform values, which helps keep test behavior accurate and reliable.
Original PR description
The `mockUserAgent()` is meant to be used with a "platform" ("mac",
"windows", "android"...) as parameter and not a whole user agent string.
In specific cases, a custom string can be used instead, but only to be
added to the user agent string.
This commit adapts its usage(s) accordingly.Documentation and clarification updates
This change updates the corporate contributor agreement documentation for Moduon. It matters for legal and compliance tracking, but does not affect product behavior for users.
Original PR description
@moduon MT-12696 Forward-Port-Of: odoo/odoo#236642