Daily updates from Odoo
Friday, April 17, 2026
32 changes · 18.0
New functionality added to Odoo
This update adds the ability to generate SAT trial balance reports in a supplementary format, aligning with Mexican tax authority requirements. The changes ensure correct formatting, including specific file naming conventions and data attributes, to meet SAT specifications and facilitate accurate tax reporting. This supports compliance with Mexican tax regulations.
Original PR description
Adds support for generating SAT (Mexican tax authority) trial balance reports in supplementary (complementary) format, as required by SAT specifications. Changes: - Add default value for submit_type…
Adds support for generating SAT (Mexican tax authority) trial balance reports in supplementary (complementary) format, as required by SAT specifications. Changes: - Add default value for submit_type in SAT XML generation to fix tests that call the method directly without going through the wizard - Add new tests for normal (TipoEnvio=N) and supplementary (TipoEnvio=C) formats - Verify that FechaModBal attribute is correctly included only for supplementary reports - Verify that filenames correctly use BN (normal) or BC (complementary) suffixes The SAT technical specification requires: - TipoEnvio="C" (complementary) for supplementary balance sheets - FechaModBal attribute (date of last accounting modification) when tipo is C - File naming convention: RFC+Year+Month+BN (normal) or BC (complementary) SAT technical specification: https://wwwmat.sat.gob.mx/cs/Satellite?blobcol=urldata&blobkey=id&blobtable=MungoBlobs&blobwhere=1461173762094&ssbinary=true Ticket: https://www.odoo.com/es_ES/my/tasks/6025590 @moduon MT-14181
Resolved issues and error corrections
This update resolves a bug that prevented bill matching from working correctly when a vendor bill line lacked a product definition. The fix ensures that quantity calculations are handled appropriately, avoiding errors and improving the reliability of the bill matching process. This change ensures accurate record keeping and prevents disruptions to the purchasing workflow.
Original PR description
Steps to reproduce: - Import or create a vendor bill with a line that has a unit of measure but no product. - Open the bill and go for the bill matching. Issue: Bill lines without a product have product_uom_id set to False. During bill matching, _compute_product_uom_qty calls _compute_quantity without checking this value, which raises a UserError due to missing or invalid UoM configuration. Solution: Add a check to ensure _compute_quantity is only called when product_uom_id is set. Otherwise, fall back to the original line quantity to avoid conversion errors. opw - 6109513
This update optimizes the workcenter planning process by streamlining how it identifies available time slots. By using a more efficient method to detect conflicting intervals, the system now finds available slots significantly faster, especially for short scheduling durations. This reduces processing time and improves overall planning efficiency.
Original PR description
### Description of the issue/feature this PR addresses: The workcenter planning logic in _get_first_available_slot can become inefficient when searching for very short available slots. The method…
### Description of the issue/feature this PR addresses: The workcenter planning logic in _get_first_available_slot can become inefficient when searching for very short available slots. The method repeatedly builds small candidate time windows and checks them against existing workorder and leave intervals, potentially iterating many times before finding a free slot. This leads to unnecessary computational overhead in scenarios where a large number of busy intervals exist and the remaining duration to schedule is small. ### Current behavior before PR: The planner checks for conflicts by computing the intersection between the candidate window and the busy intervals. When a conflict is detected, the candidate window is shifted forward (or backward) to the end (or start) of the intersection, and the process is repeated until a free slot is found. This approach requires repeatedly performing full interval merge operations, which becomes disproportionately expensive when the candidate windows are very small and the loop iterates many times. ### Desired behavior after PR is merged: The planner uses a new Intervals.conflicting() helper to retrieve the entire busy interval that overlaps with the candidate window. Instead of advancing only to the end of the intersection slice, the planner can jump directly to the end (or start) of the full busy interval. This avoids repeated full-merge work, reduces the number of iterations needed to find a valid slot, and prevents pathological performance slowdowns in short-duration planning scenarios. ### Benchmarks Profiling _get_first_available_slot with different workorder durations. Database has multiple months that are fully booked. Speedup is more dramatic with shorter durations but there is at minimum minor improvements across the board. | Work Order Duration | Before | After | | --- |---|---| | 1sec | ~2.5min | <1sec | | 1min | ~2sec | <1sec | ### References opw-5437256 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where ISO20022 payments using JPY were failing due to a hardcoded decimal format. The fix dynamically adjusts the amount format to match JPY's zero-decimal currency, ensuring compatibility with banking systems. This prevents payment failures and improves the reliability of JPY transactions.
Original PR description
Steps to reproduce: ------------------- 1. Activate JPY and create a JPY bank journal with ISO20022 as an outgoing payment method 2. Create a vendor (with a country) and add a trusted bank account 3.…
Steps to reproduce: ------------------- 1. Activate JPY and create a JPY bank journal with ISO20022 as an outgoing payment method 2. Create a vendor (with a country) and add a trusted bank account 3. Create and confirm a vendor bill in JPY (e.g. ¥1000), and pay it using the ISO20022 method on the JPY journal 4. Create a batch payment containing that payment, with Batch Type Outbound, on the JPY journal, with ISO20022 as payment method 5. Validate the batch — the XML file is generated and attached 6. Download it -> The `<InstdAmt Ccy="JPY">` node outputs `1000.00`, while JPY has no decimals. The file is rejected by banks. The fix: -------- Backport of 8da91d94ed1e8fad0e827f96172e3785e9f0e28d: > Generating the xml file for iso20022 always generates the amount with two decimals which is hard coded and can cause error for currencies without decimals for example JPY. > The fix is to have the currency decimal number dynamically set through the currency decimal places field. opw-6103849
This update fixes an issue with invoice rounding related to down payments in the account_edi_ubl module. The system now correctly uses specific currency values to ensure the total invoice amount matches expected calculations, particularly when dealing with initial payments. This improves invoice accuracy and prevents discrepancies.
Original PR description
'total_excluded_currency' is for the base amount. 'base_amount_currency' should be used only when getting the base per tax. When dealing with a down payment, a distortion in the taxes amounts might be introduced to ensure the total of the invoice is exactly the expected one. opw-6120645 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a rounding issue in the generation of Peppol invoices, ensuring accurate calculations for line amounts. Previously, the system rounded unit prices, leading to validation errors. This fix ensures invoices comply with Peppol standards and avoids potential shipping delays or payment issues.
Original PR description
**PROBLEM** Previously, we rounded the unit price up to 6 digits in the generated xml for peppol. However, odoo compute the lineExtensionAmount with the raw unit price. The generated xml is invalid because `priceAmount*InvoicedQuantity != LineExtensionAmount`. **STEP TO REPRODUCE** 1. Create an invoice with unit price of 0.01110515964, and quantity of 278362.5. 2. Generate an XML with peppol, and try validating the invoice. You should have the following error: `[PEPPOL-EN16931-R120]-Invoice line net amount MUST equal (Invoiced quantity * (Item net price/item price base quantity) + Sum of invoice line charge amount - sum of invoice line allowance amount` opw-6009771
This update fixes an issue where the Mercado Pago webhook couldn't process invoices with references containing slashes (like INV/2026/00001). Previously, the system would return an error. This change ensures that all invoice references, including those with slashes, are correctly processed by the webhook, improving integration with Mercado Pago.
Original PR description
Currently, the mercado_pago_webhook http route only takes into consideration 1 url segment. This means that invoices with references like INV/2026/00001 don't match any defined route and the server returns a 404. /payment/mercado_pago/webhook/S00001 => OK /payment/mercado_pago/webhook/INV/2026/00001 => KO This commit allows references with slashes to be matched by the route by capturing the entire remaining url path including the slashes. /payment/mercado_pago/webhook/S00001 => OK /payment/mercado_pago/webhook/INV/2026/00001 => OK opw-6035161 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259378
This update fixes a security issue where unauthorized users could access asset information linked to invoices. Now, only users in specific accounting groups (read-only or invoice-related) can view assets, preventing potential data access problems. This ensures data integrity and protects sensitive financial information.
Original PR description
Only groups `account.group_account_readonly`, `account.group_account_invoice` or higher have access to model `account.asset`, therefore if an user goes to see an invoice with assets and they are not on either group, they will receive an error and won't be able to access said invoice. How to reproduce: - Create a vendor bill - Create an account.asset and link it to said account.move - Go to the form view with an user that it's on group "Purchase: User" for example --> They get a traceback --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#113523 Forward-Port-Of: odoo/enterprise#112890
This update resolves an issue where invoice creation would fail when the 'aggregate' setting was enabled without a defined 'aggregate period'. The change ensures that a valid 'aggregate period' is always required when 'aggregate' is set, improving invoice processing stability.
Original PR description
Previously, if `is_aggregate_limit` was set to True while `aggregate_period` was left empty, it would raise a traceback during invoice creation. Although `aggregate_period` has a default value, it can still be manually cleared. With this commit, `aggregate_period` is enforced as mandatory whenever `is_aggregate_limit` is enabled, preventing such errors.
This update corrects and streamlines French translations for the Enterprise module, specifically for asset and reporting functionalities. Incorrect or outdated translation overrides have been removed, ensuring consistent and accurate language across French-speaking regions (Belgium and Canada). A minor menu item adjustment was also made for the Netherlands.
Original PR description
There were some translation overrides for `fr_BE` and `fr_CA` that were incorrect or unnecessary. We are deleting these files so they use the correct translations in `fr` instead. In the `nl_BE` translation, we are fixing a menu item so it is shorter, but still correct. task-5921458 Forward-Port-Of: odoo/enterprise#106998
This update resolves a test failure related to a calculated field in the Belgian payroll module (l10n_be_hr_payroll). The fix removes tracking from a specific field, preventing it from being prematurely computed during test runs. This ensures accurate calculations and reliable test results.
Original PR description
…ield The computed, non-stored field `l10n_be_holiday_pay_recovered_n1` had tracking enabled. When writing to any field on the employee, the `write` method calls `_track_prepare` for tracked fields if `mail_notrack` is not set in the context. `_track_prepare` reads the current value of tracked fields to store initial values. Because `l10n_be_holiday_pay_recovered_n1` is non-stored with no dependencies, this triggered a computation at the very beginning of the test, before payslips existed. Later, when payslips were created, the field was never recomputed, causing incorrect values and test failures. Previously, the `tracking_disable` context prevented early computation. The fix removes the tracking attribute entirely, so the field is only computed when accessed, avoiding premature reads and fixing the tests. task: 6095445 Forward-Port-Of: odoo/enterprise#113015
This update fixes a calculation error in the timesheet grid's monthly view for flexible schedules. Previously, it incorrectly displayed a deficit, even with fully completed workdays. The fix ensures accurate required hour calculations by adjusting the formula to account for standard working days.
Original PR description
When using a flexible working schedule, the month view for timesheets shows a deficit even when all working days are fully completed. ### **Steps to reproduce:** 1) Install Timesheet Grid. 2) Assign…
When using a flexible working schedule, the month view for timesheets shows a deficit even when all working days are fully completed. ### **Steps to reproduce:** 1) Install Timesheet Grid. 2) Assign a flexible working schedule (40 hrs/week, 8 hrs/day) to an admin. 3) Enter timesheets with 8 hours per weekday for a full month (except Feb). 4) Open the timesheets grid month view. Note: current formula correctly calculates for feb month **((40/7)** * **28) = 160** ### **Observed behavior:** The weekly view shows correct totals, but the monthly view displays a deficit (176 h with -1:08 h), despite all working days being fully completed. <img width="1920" height="366" alt="image" src="https://github.com/user-attachments/assets/df98c3e0-ee89-455d-86c6-7941ba0cb7a8" /> ### **Expected behavior:** The monthly view should correctly calculate the required hours i.e 176 h <img width="1909" height="357" alt="image" src="https://github.com/user-attachments/assets/c082953a-62ad-4096-8774-76d9ff7b3b25" /> ### **Root Cause:** The method [_count_daily_working_hours](https://github.com/odoo/enterprise/blob/3cf76350794078f807fc07cd0b42d0bb0315ccab/timesheet_grid/models/hr_employee.py#L82) calculated `full_time_required_hours` for a period by dividing the weekly required hours by 7 (including weekends) and multiplying by the total calendar days in the period at [1]. This gave incorrect required hours for months that have extra weekend days. [1]- https://github.com/odoo/enterprise/blob/3cf76350794078f807fc07cd0b42d0bb0315ccab/timesheet_grid/models/hr_employee.py#L115 ### **Fix:** Update the computation to divide the weekly `full_time_required_hours` by `5` (standard working days) and multiply by the actual number of weekdays in the requested period. **Example calculation for the month March 2026:** | | Formula | Values | Calculation | Result | |--------|--------|--------|--------|--------| | Before Fix | round(full_time_required_hours / 7 * (delta.days + 1), 2) | full_time_required_hours = 40, delta.days + 1 = 31 | round(40 / 7 * 31, 2) | **177.14 h** | | After Fix | round((full_time_required_hours / 5) * working_days_in_period, 2) | full_time_required_hours = 40, working_days_in_period = 22 | round((40 / 5) * 22, 2) | **176.00 h** | **opw-5966769**
This update fixes a display issue in grouped list views where the pager incorrectly showed the `count_limit` instead of the total record count. The change ensures the pager accurately reflects the number of records in a group, improving user experience and data accuracy. This was achieved by leveraging existing calculations within the system.
Original PR description
When a pager is needed in a grouped list view and if the total number of record is greater than the `count_limit` (by default equal to 10000); opening the group or pressing the "Next" button will display the `count_limit` in the Pager.
This behavior can be optimized since the `web_read_group` call already computed the total count.
This commit allow the grouped list pager to display the total record count if it was already computed.
Steps to reproduce:
in a list view with 10 records, all in the same group for simplicity:
```xml
<list limit="2" count_limit="8">
<field name="foo"/>
</list>
```
- group the view by "foo" => The pager displays: `"1-2 / 10"`
- click on the 'next' button of the pager => The pager displays: `"3-4 / 8"`
8, the `count_limit` is shown instead of 10, the number of records in the group.
task-6053705This update corrects a technical problem where the cookies bar's state was incorrectly saved, leading to performance issues and potential errors with website responses. The fix prevents the cookies bar from persistently setting an invalid value, ensuring a smoother user experience and preventing issues with website delivery.
Original PR description
Steps to reproduce: - Set the cookies bar - Do not accept nor reject it - On the website homepage, click on the search button => Check the cookies: website_cookies_bar=true is set. `Popup`…
Steps to reproduce: - Set the cookies bar - Do not accept nor reject it - On the website homepage, click on the search button => Check the cookies: website_cookies_bar=true is set. `Popup` initializes `cookieValue` to `true` and writes it in `onHideModal()`. If the cookies bar is closed before any explicit consent choice, it can therefore recreate the legacy invalid value `website_cookies_bar=true`. This happens because the search button uses `data-bs-toggle="modal"`, which is controlled by Bootstrap: if it is opened while another bootstrap modal is already open on the page, the latter is hidden. This in turn calls the popup interaction's `onHideModal()`, which sets `website_cookies_bar=true` as `cookieValue` hasn't been changed. That value is later treated as invalid and cleared repeatedly during website rendering, which can accumulate duplicate `Set-Cookie` headers in the same response and lead to `upstream sent too big header` behind nginx. Avoid persisting that legacy value by returning early from `CookiesBar.onHideModal()` while `cookieValue` is still the inherited default `true`. opw-6037573 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Backport of: https://github.com/odoo/odoo/pull/258938 Forward-Port-Of: odoo/odoo#259585
This update fixes an issue where bank statement creation didn't consistently use the specified journal type. Now, when a journal type is set during bank statement creation, the system correctly assigns the appropriate journal, ensuring accurate financial record-keeping. This improves the reliability of bank statement processing.
Original PR description
When a account.bank.statement is created via a action where the journal_type is set in the context this value isn't used to compute the right journal for the account.bank.statement.line/account.move --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where invoices could fail to process correctly with the Peppol system. The fix involved a temporary workaround to prevent a specific error during invoice generation, ensuring invoices can now be properly tracked and status updates retrieved. This improves the reliability of Peppol invoice processing.
Original PR description
1. Send an invoice that will return an error when send to IAP 2. Send the invoice 3. Click "Fetch Peppol Invoice status" on the dashboard 4. There is a traceback (see the bottom of this message) To…
1. Send an invoice that will return an error when send to IAP
2. Send the invoice
3. Click "Fetch Peppol Invoice status" on the dashboard
4. There is a traceback (see the bottom of this message)
To create an invoice that will return an error I locally removed the EndpointID from the UBL generation (and the constraint to check that during the genreation).
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/odoo/http.py", line 2167, in _transactioning
return service_model.retrying(func, env=self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/service/model.py", line 157, in retrying
result = func()
^^^^^^
File "/home/odoo/src/odoo/odoo/http.py", line 2134, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/http.py", line 2382, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/http.py", line 754, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/addons/web/controllers/dataset.py", line 42, in call_button
action = call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/api.py", line 535, in call_kw
result = getattr(recs, name)(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/addons/account_peppol/models/account_journal.py", line 34, in peppol_get_message_status
edi_users._peppol_get_message_status()
File "/home/odoo/src/odoo/addons/account_peppol/models/account_edi_proxy_user.py", line 287, in _peppol_get_message_status
processed_message_uuids = edi_user._peppol_process_messages_status(messages_to_process, uuid_to_record)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/addons/account_peppol_response/models/account_edi_proxy_user.py", line 180, in _peppol_process_messages_status
peppol_response = uuid_to_record[uuid]
^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: 'document_type'
```
task-NoneThis update allows administrators to control whether subscription users are automatically reset. Previously, this process was fixed, making it difficult to manage. By providing greater control, this change improves flexibility and operational efficiency for subscription-based sales.
Original PR description
After this commit, the auto resetting of subscription user is overridable. Doing business logic in CRUD methods makes them impossible to bypass, by encapsulating the logic in another method, it would be easily overridable.
This update resolves an issue where backorder returns weren't properly associated with the original delivery. The fix ensures that when a backorder is returned, it's correctly linked to the associated delivery, improving the accuracy of inventory tracking. This prevents discrepancies and simplifies the return process.
Original PR description
### Steps to reproduce: - Create, confirm and validate a delivery for 2 units of a product A - Click Return > Return All - Validate the return for 1 unit and backorder #### > The backorder does not belong to the return list of the delivery ### Cause of the issue: Backorder pickings are created by copying the picking to backorder: https://github.com/odoo/odoo/blob/9ad995ff6b59a6a2fdfbbd6cf385fe27568dd3ea/addons/stock/models/stock_picking.py#L1580-L1593 https://github.com/odoo/odoo/blob/9ad995ff6b59a6a2fdfbbd6cf385fe27568dd3ea/addons/stock/models/stock_picking.py#L1571-L1578 However, the `return_id` is a `copy=False` field that is not manully set during this copy process: https://github.com/odoo/odoo/blob/9ad995ff6b59a6a2fdfbbd6cf385fe27568dd3ea/addons/stock/models/stock_picking.py#L558 opw-6111544 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the Italian tax reporting module was incorrectly removing parts of VAT numbers when generating XML invoices. The fix ensures that VAT numbers, like those used in Spain, are accurately exported to the tax agency, preventing reporting errors. This improves data accuracy and compliance.
Original PR description
**Steps to reproduce:** * Install `l10n_it_edi` module. * Create a partner with country **Spain** and VAT `A95758389`. * Create an invoice and send it to the Tax Agency, and download XML. **Observed behavior:** * The exported XML contains `5758389` in <IdCodice> instead of `A95758389` — the first two characters of the VAT are silently dropped. **Cause:** * In `_l10n_it_edi_get_values`, the EU branch that strips the country-code prefix used a bare `else` after the `isdecimal()` check, unconditionally removing the first two characters of any VAT that does not start with two digits. Spanish NIFs like `A95758389` start with `A9` (letter + digit), which is not a country-code prefix but was treated as one, corrupting the value. **Fix:** * Remove country prefix from normalized VAT by `removeprefix(normalized_country)` Instead of removing the first two characters. It will ensure that only the country prefix will be removed. opw-6089198 Forward-Port-Of: odoo/odoo#258626
This update resolves an issue where users without the necessary permissions could still access the Documents app. The fix restricts access to the Documents app icon and dashboard to only administrator users, ensuring data security and proper user access control. This prevents unauthorized access to sensitive documents.
Original PR description
Steps to reproduce: =================== - Login as admin and create another user. - Download 'Documents' app. - Revoke user of 'Documents' app access . - Login as the other user. - The 'Documents' app is showing even-though the user shouldn't have access to it. Cause of Issue: ====== - 'Documents' icon and dashboard have 'base.group_user' access. https://github.com/odoo/enterprise/blob/3e8c4e90b07bd7ddc034c9c6df114a66753e2ef3/documents/views/documents_menu_views.xml#L4-L12 opw-5914433
This update resolves an issue where the custom declaration field wasn't automatically filled for international World Express Pro shipments through the BPost module. Now, the necessary information is correctly populated, ensuring accurate customs documentation and smoother international deliveries. This improves compliance and reduces potential delays.
Original PR description
Before this commit, the bpost module was not filling the custom declaration in case of international shipping (World Express Pro) After this commit, the section is filled opw-4932970
This update enhances the accuracy of tax calculations for Odoo's Argentina localization (l10n_ar). By modernizing the tax calculation methods, the system now aligns with best practices and prepares for potential future adjustments to Argentine tax regulations. This ensures more reliable financial reporting for users in Argentina.
Original PR description
This commit refactors the tax amount calculations on the `_get_vat` and `_l10n_ar_get_amounts` method so that it uses the tax computation engine helpers properly, to prepare for any future fixes done on how Argentina tax calculations differs from all other localizations. This replaces all move line queries with the proper `base_line` calculation, with the proper aggregating methods. related-enterprise-PR: https://github.com/odoo/enterprise/pull/92639 task-4891206
This update fixes inaccuracies in how tax amounts are calculated within the l10n_ar_edi module. By utilizing the Odoo's tax computation engine, the changes ensure more precise and reliable tax calculations across various sales and invoice scenarios. This improves financial reporting accuracy.
Original PR description
- Rewrite all tax amounts calculations on `_get_tributes` and `_get_line_details` to properly use the tax computation engine helpers (`base_line`, and aggregating methods) - Ensure that all final amounts from the calculation are formatted with `float_repr` with appropriate precision. related-community-PR: https://github.com/odoo/odoo/pull/223393 task-4891206
This update resolves a problem with a test case in the Helpdesk Stock module. The test was referencing a field that didn't exist in the Helpdesk Stock module, causing test failures. This change ensures the tests accurately reflect the functionality of the Helpdesk Stock module.
Original PR description
Remove sale_line_id field from the test as it belongs to helpdesk_sale_timesheet and is not available in this module. runbot link - https://runbot.odoo.com/odoo/runbot.build.error/242470
This update ensures that subcontracted items always display a cost in the BOM report, even when an exact supplier match isn't found. Previously, the cost would be hidden if no supplier met the quantity requirements. This change guarantees a complete and accurate BOM cost structure, improving reporting and decision-making.
Original PR description
Description of the issue/feature this PR addresses: When visualizing the structure of a BOM with subcontracted components, the subcontracting cost is omitted if no supplierinfo record exists with a…
Description of the issue/feature this PR addresses: When visualizing the structure of a BOM with subcontracted components, the subcontracting cost is omitted if no supplierinfo record exists with a `min_qty` less than or equal to the requested quantity. This leads to an inconsistent experience compared to regular components, which still show a price by selecting the closest lower `min_qty`. For subcontracted components, if the requested quantity does not match any valid `supplierinfo`, the cost line silently disappears from the report. Current behavior before PR: The subcontracting cost is not shown in the BOM cost structure if no `supplierinfo` matches the requested quantity (i.e., `min_qty > quantity`). Desired behavior after PR is merged: If no matching supplier is found for the requested quantity, the fallback logic uses any available supplierinfo (as already done in `_format_route_info`), ensuring a price is shown for subcontracted lines. This guarantees the BOM cost structure always includes the subcontracting cost, making the report complete and coherent. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a misconfiguration in the Philippine localization (l10n_ph) module. The '12% I' tax group was incorrectly categorized as 'Capital 12%'. This change ensures accurate VAT reporting and compliance with Philippine tax regulations. It's a necessary correction for proper financial reporting.
Original PR description
In this commit: - We change the group of tax '12% I', from 'Capital 12%' to 'VAT 12%' task-6092566
This update fixes an issue where tax reporting for '12% I' was incorrectly displayed under 'Purchase of Capital Goods' in Philippine sales reports. The change now accurately shows this tax amount under 'Purchase of Other than Capital Goods', ensuring correct financial reporting for Philippine businesses using Odoo Enterprise.
Original PR description
Before this commit: - The amount of tax '12% I' is shown under 'Purchase of Capital Goods'. After this commit: - The amount of tax '12% I' is shown under 'Purchase of Other than Capital Goods'. task-6092566
This update resolves a bug where users lacking sufficient permissions encountered errors when modifying sales order lines within subscription timesheets. The fix involves a simplified data fetch to prevent privilege-related access issues, ensuring smoother operation for users with limited access.
Original PR description
The change in e75bc6a1fac056d72fe9e73513635f9e0ba7db22 may cause some access errors when the user don't have the proper privileges. STR: 1. Having a user (demo) with minimal permissions: sales own documents, timesheets and project user 2. Having a sales order for customer that demo user can read with services in it. 3. Having that customer a task with a sale that the demo user can't read. 4. When the user tries to change the line to one that he can actually read, an error raises. The display_name function tries to fetch data from the lines related order. Let's just sudo that fetch to avoid these kind of issues. A demo video: https://www.loom.com/share/ddd02d72bcea4652b79549aba47d5334 opw-5969767 cc @moduon MT-14483
This update fixes a problem where canceling a transaction on a point-of-sale terminal (without initiating the cancellation process within the POS system) would cause errors. The change ensures the system correctly handles cancellation requests, regardless of where they originate, improving transaction reliability. This prevents data inconsistencies and potential disruptions to sales.
Original PR description
Currently if you cancel a transaction on the terminal (not in pos) this lead to a traceback TypeError: this.cancel_resolve is not a function at Proxy._waitingPayment (https://varoconsult-be-itve.odoo.com/web/assets/4473ba8/point_of_sale.assets_prod.min.js:16764:298) at Proxy._onValueChange (https://varoconsult-be-itve.odoo.com/web/assets/4473ba8/point_of_sale.assets_prod.min.js:16758:184) at Proxy._onSuccess (https://varoconsult-be-itve.odoo.com/web/assets/4473ba8/point_of_sale.assets_prod.min.js:16674:190) at Proxy._onSuccess (https://varoconsult-be-itve.odoo.com/web/assets/4473ba8/point_of_sale.assets_prod.min.js:16778:1228) at https://varoconsult-be-itve.odoo.com/web/assets/4473ba8/point_of_sale.assets_prod.min.js:16672:417 This PR fixes the issue to ensure the scenario when the pos didnt ask for cancellation is managed
This update resolves an issue where invalid Taiwan VAT numbers (e.g., containing letters) would cause the invoicing system to crash. The fix adds validation to ensure VAT numbers contain only digits, preventing the error and providing a clear warning message to the user. This ensures data integrity and a smoother user experience when entering customer information.
Original PR description
**Steps to reproduce:** - Install the `base_vat` module. - Navigate to Invoicing > Customers. - Create a new contact and set the country to `Taiwan`. - Enter `1234567A` as the `Tax ID` and try to `save`. **Error:** `ValueError: invalid literal for int() with base 10: 'A'` **Root cause:** At [1], `check_vat_tw` is missing validation to ensure that the VAT number (without the country code) contains only digits, which causes an error when calling the `int()` method on the VAT number. **Fix:** This commit prevents errors and ensures users receive a `clear warning message`. [1]: https://github.com/odoo/odoo/blob/23398d24e108875b2838715d4b366df265d53234/addons/base_vat/models/res_partner.py#L929-L958 **No task Id** Forward-Port-Of: odoo/odoo#259847
This update fixes a potential issue during module uninstalls. Previously, outdated references within the Odoo system could cause errors in subsequent operations. Now, the system clears all relevant caches to ensure accurate tracking of field objects, leading to more reliable module uninstalls.
Original PR description
When uninstalling a module, the ORM may replace field objects in the registry via a prefetch patch to avoid fetching deleted fields. The previous code only called lazy_property.reset_all(), which resets lazy-property caches, but left _field_trigger_trees and _is_modifying_relations intact. Those structures still held references to the old field objects, and could be consulted by subsequent ORM operations, leading to incorrect trigger resolution or relation tracking. Clear both caches whenever a shared field has been patched so all registry state stays consistent with the new field objects. runbot-242251 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 Forward-Port-Of: odoo/odoo#259820
Features or functions removed from Odoo
This update removes a confusing tooltip from the 'tax_scope' field in the accounting module. The tooltip incorrectly suggested this field restricted taxes by product type, which wasn't true. This change clarifies the field's function and improves user understanding.
Original PR description
The current tooltip suggests that the `tax_scope` field restricts the use of taxes based on the product type. However, this is misleading, as the field does not enforce any restriction at the product level. To avoid confusion, remove the tooltip entirely. Backport of: https://github.com/odoo/odoo/pull/256573 opw-6118051 Forward-Port-Of: odoo/odoo#259550