Daily updates from Odoo
Thursday, February 26, 2026
40 changes · master
Resolved issues and error corrections
This update fixes an issue where warehouse names with only numbers (e.g., '01') were displayed incorrectly in the barcode app. The fix removes a browser setting that caused numerical warehouse codes to be reversed, ensuring they are always shown in the correct order. This improves the clarity and accuracy of product information displayed to users.
Original PR description
### Steps to detect the bug: - Download stock apps - Enable "storage locations" settings under warehouse index - Change name of warehouse with a name composed only of numbers (ex. 01) - Create a…
### Steps to detect the bug:
- Download stock apps
- Enable "storage locations" settings under warehouse index
- Change name of warehouse with a name composed only of numbers (ex. 01)
- Create a product (with barcode number)
- Insert a number of products available with smart button "on hand"
- Create a new delivery for that product
- Go to barcode app and search for the delivery you just created
- Click on it and see that the name of the warehouse will be stock/01 instead of the correct 01/stock
### The problem:
The previous configuration used direction: rtl; on the warehouse name
element in the barcode app. So if the string contains only letters the
standard visual order is maintained, however, when the string consists
entirely of numbers the rtl property forces the browser to reorder them
from right to left.
### The reson to introduce the fix:
By removing this property, it is ensured that numerical warehouse codes are displayed in their natural sequence without being flipped.
opw-5730199
Forward-Port-Of: odoo/enterprise#107920This pull request addresses a technical issue related to the loading of task demonstrations within the Sale Timesheet module. The fix ensures that task-related data is correctly displayed, improving the functionality of this key sales reporting feature. This change enhances the accuracy of time tracking data for sales teams.
Original PR description
Forward-Port-Of: odoo/enterprise#108646
This update corrects a technical issue where the IoT long polling process wasn't correctly configuring HTTP requests. Previously, a failure occurred when attempting to retrieve event data. Now, all necessary parameters are passed, ensuring reliable data retrieval from IoT devices.
Original PR description
Before this commit, when the `_poll` method in the `iot_longpolling` called itself to listen for further events, it didn't pass in the `useLna` parameter. This caused the second call to `/event` to not use HTTP and therefore could fail. After this commit, the parameters are all passed through as expected. Forward-Port-Of: odoo/enterprise#108657
This change removes an unnecessary `div` wrapper from article body content. Previously, a technical detail in how the system parsed HTML caused this wrapper to be added, which increased the complexity of article formatting. This fix ensures cleaner and more efficient HTML structure for articles.
Original PR description
Prior to this commit, `_get_transformed_body_from` wrapped the source body in a `div` because `lxml.html.fragment_fromstring` is used with a `create_parent=True` argument. That argument is required because otherwise, the function throws an error if there are multiple root nodes in the parsed string, which is frequent in an article body. The final returned string still contained that additional `div` ancestor. This does not break an article per se, but repeated usage would increase the html structure depth by 1 every time, and that additional `div` was not part of the function desired transformations. task-5960616 Forward-Port-Of: odoo/enterprise#108310
This update resolves a technical issue that caused payroll processing to crash when employee contract dates were missing. By ensuring contract dates are always set, the system now reliably calculates payroll warnings without generating errors, improving overall payroll stability.
Original PR description
This commit fixes a traceback that occurred when an `hr.employee` record had no `contract_date_start` or `contract_date_end` defined, while payroll warnings depending on those fields were present. Since `warning_date` is computed based on the contract dates, the absence of the relevant field caused a crash. We now ensure that `contract_date_start` and `contract_date_end` are set before computing `warning_date` with either one. TaskID-5944876 Forward-Port-Of: odoo/enterprise#108106
This update resolves a bug preventing users from saving or modifying Mexican VAT invoices when a specific payment policy (PUE) is selected. The fix allows users to set the payment method until the invoice is sent to the tax authority, ensuring flexibility and proper invoice processing. This improves usability for our Mexican clients.
Original PR description
After this commit 1e702a5, a bug in the invoice form view appeared that made it difficult (to not say impossible) to reset an invoice or do any operation that involves to save the invoice. How to…
After this commit 1e702a5, a bug in the invoice form view appeared that made it difficult (to not say impossible) to reset an invoice or do any operation that involves to save the invoice. How to reproduce (there are multiple ways but this is the easiest): 1.- Using mx demo company INNOVACION y DESARROLLO SA de CV 2.- Create an invoice with INMOBILIARIA CVA as contact 3.- Post the invoice 4.- Try to send or do a modification and save 5.- Missing required fields notification will appear. This error happens since the payment way is required if the payment policy is PUE but is not editable when not in draft, causing this deadlock. There multiple ways to fix this, but the simplest way and maintaining the flexibilty on the user to decide what value to use, we keep the logic on the view but make the payment method editable until the invoice is sent to the SAT just like with the payment policy. target: saas-19.2 -> master task-5962060 Forward-Port-Of: odoo/enterprise#108378
This update fixes an issue where international UPS deliveries were generating commercial invoices with incorrect freight charges (set to $0). The fix ensures that freight charges are accurately reflected on the invoice by specifying them within the UPS shipping request. This ensures proper customs processing for international shipments.
Original PR description
Issue ----- For international deliveries, the commercial invoice used for customs does not include the freight charges (it is set to 0). Steps to reproduce ----- - Create an international UPS sale - Confirm the delivery - Open the "UPSCommercialInvoice.pdf" file > In the price breakdown, freight is set to 0.0 Cause ----- It has to be specified in the `ship` request as `ShipmentServiceOptions.InternationalForms.FreightCharges.MonetaryValue` (source https://docs.rocketshipit.com/rs/docs/ups-api-parameters.html#shipment) Expected result ----- <img width="1912" height="963" alt="image" src="https://github.com/user-attachments/assets/170e49f7-6575-4524-b186-3829f4c20430" /> ----- Ticket: opw-5135494 Forward-Port-Of: odoo/enterprise#108465 Forward-Port-Of: odoo/enterprise#105505
This update resolves a problem where demo data incorrectly created duplicate follower records for portal customers. The change automatically handles follower subscriptions during project creation, eliminating the need for manual duplicate entries in the demo data. This ensures consistent and accurate demo data installation.
Original PR description
Portal customers are automatically subscribed as followers when a portal-visible project is created with a customer. The demo data in documents_project_sale was still manually creating a follower for the same partner, which caused a duplicate follower creation during demo data installation. This commit removes the redundant follower record from demo data, since follower subscription is already handled automatically during project creation. task-5075093
This update corrects a reporting issue within the MRP modules by standardizing time data to minutes. A new widget has been implemented to ensure accurate time calculations and reporting, enhancing the reliability of MRP data. This change impacts how time-based metrics are displayed and processed.
Original PR description
Make sure that time fields in mrp modules are in minutes. Add a new widget in mrp_plm for updates on time data types. Replace formatFloatTime by formatDuration. Forward-Port-Of: odoo/enterprise#108078
This update resolves an issue preventing portal users and internal users from uploading documents to requests. The fix corrects a technical error related to how access tokens and user folder IDs were being processed, now allowing successful document uploads. This improves the user experience for submitting and managing documents within the Documents module.
Original PR description
Portal users and internal users cannot upload a document in a requested document Steps to reproduce: 1. Install Documents 2. Go to Documents and create a new request for user Joel Willis 3. Connect as portal user and go to Documents 4. Try to upload the requested document 5. An error occurs The same problem occurs for user Marc Demo Problem: Sending both an access_token and a user_folder_id to the controller raises an error 400 https://github.com/odoo/enterprise/blob/519862bf9b708d756478d4d81787f8a1999bc574/documents/controllers/documents.py#L608-L609 Solution: Do not send a user_folder_id when we have an access_token opw-5439104 Forward-Port-Of: odoo/enterprise#106583
This update fixes an issue where CABA taxes were incorrectly included in tax reports, even when invoices were unpaid. The fix ensures that CABA taxes within tax groups are properly excluded, preventing duplicate reporting and improving the accuracy of financial data. This resolves a previous bug impacting invoice reconciliation.
Original PR description
How to reproduce: - Create one CABA tax and one normal tax. - Create a tax group containing both taxes. - Create an invoice using this tax group. - In the tax report, the CABA tax appears even when the invoice is unpaid. - After reconciliation, the CABA tax amount is duplicated in the report. When the CABA tax is part of a tax group, it is selected in _read_generic_tax_report_amounts_no_tax_details. Since the tax group has tax_exigibility = 'on_invoice', the CABA tax inside the group is incorrectly included by the query. opw-5468074 Forward-Port-Of: odoo/enterprise#108171 Forward-Port-Of: odoo/enterprise#105888
This update resolves a critical error that prevented users from submitting UK tax reports when the company's VAT value was left blank. The fix ensures that VAT is always set on the company record, allowing successful connection to HMRC and report transmission. This ensures accurate tax reporting for UK businesses.
Original PR description
Steps to Reproduce: https://www.awesomescreenshot.com/video/49329263?key=2daddfb65e4ee8dcf1a047c09c6bd2b5 - Install l10n_uk_reports module - Keep the VAT value empty for the UK Company - On the Tax…
Steps to Reproduce: https://www.awesomescreenshot.com/video/49329263?key=2daddfb65e4ee8dcf1a047c09c6bd2b5
- Install l10n_uk_reports module
- Keep the VAT value empty for the UK Company
- On the Tax Report (GB), click Connect to HMRC
- Establish connection with HMRC
- After a successful connection, try to send the tax report to HMRC
- Traceback will appear
<details><summary>Exact Traceback</summary>
<p>
```
RPC_ERROR
Odoo Server Error
Occured on 100710704-master-all.runbot216.odoo.com on model account.report on 2026-02-11 12:50:03 GMT
Traceback (most recent call last):
File "/data/build/odoo/odoo/http/requestlib.py", line 632, in _serve_db
return retrying(serve_func, env=self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/http/retrying.py", line 52, in retrying
result = func()
^^^^^^
File "/data/build/odoo/odoo/http/requestlib.py", line 687, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/http/dispatcher.py", line 308, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/addons/base/models/ir_http.py", line 374, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/http/routing_map.py", line 207, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/addons/web/controllers/dataset.py", line 32, in call_kw
return call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/service/model.py", line 57, in call_kw
result = method(recs, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_report.py", line 2825, in dispatch_report_action
return report_to_call.dispatch_report_action(options, action, action_param=action_param, on_sections_source=False)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_report.py", line 2836, in dispatch_report_action
return report_method(model, *args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/l10n_uk_reports/models/account_financial_report.py", line 30, in send_hmrc
self.env['l10n_uk.vat.obligation'].import_vat_obligations(self.env.context['client_data'])
File "/data/build/enterprise/l10n_uk_reports/models/hmrc_vat_obligation.py", line 124, in import_vat_obligations
self._get_vat(),
^^^^^^^^^^^^^^^
File "/data/build/enterprise/l10n_uk_reports/models/hmrc_vat_obligation.py", line 111, in _get_vat
if vat.startswith(('GB', 'XI')):
^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'startswith'
The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (https://100710704-master-all.runbot216.odoo.com/web/assets/0a37914/web.assets_web.min.js:3225:165)
at XMLHttpRequest.<anonymous> (https://100710704-master-all.runbot216.odoo.com/web/assets/0a37914/web.assets_web.min.js:3231:13)
```
</p>
</details>
Reason:
- No VAT set on the current company.
Solution:
- Blocking level error for the user to set VAT on the current company.
Task-5929908
Forward-Port-Of: odoo/enterprise#107150This update resolves a bug where Odoo would crash when Avatax company credentials were missing. The fix prevents a crash by handling the absence of credentials gracefully within the Avatax integration process. This ensures stability and prevents disruptions to accounting operations.
Original PR description
When `_find_avatax_credentials_company` returns `None`, `_get_avatax_service_params` crashes accessing `.avalara_commit` on it. `_find_avatax_credentials_company` should probably return an empty `res.company` recordset when it cannot find a company, but for stability reasons we won't change the return value and instead fix it locally in `_get_avatax_service_params`. opw-5939708 Forward-Port-Of: odoo/enterprise#108192
This update fixes an issue where the FAIA report incorrectly classified partners as suppliers instead of customers, particularly when credit notes were involved. The change allows a partner to be recognized as both a customer and supplier, ensuring accurate reporting of receivables and payables, especially when balances are zero.
Original PR description
1. Create a contact (with minimal details). 2. Create a customer invoice for that contact **last month** with `quantity = 300`. 3. Create a credit note for that invoice **this month**. 4. Create…
1. Create a contact (with minimal details). 2. Create a customer invoice for that contact **last month** with `quantity = 300`. 3. Create a credit note for that invoice **this month**. 4. Create another customer invoice for the same contact **this month** with `quantity = 100`. In the FAIA report (XML), within the General Ledger section, the partner is incorrectly classified as a supplier instead of a customer. In the method _saft_fill_report_partner_ledger_values from account_saft, he partner type is determined based on whether the balance is negative. However, a negative balance can result from a credit note, where the partner is still a customer and not a supplier. Furthermore, a partner can be both a supplier and a customer. This commit allows a partner to be both a customer and a supplier. If both receivable and payable are 0 we set the partner type to customer to keep the behavior from e9640caf29e967fe7d8c6fe303b5a8d7a866437e opw-5360924 Forward-Port-Of: odoo/enterprise#108197 Forward-Port-Of: odoo/enterprise#100749
This update corrects a previous issue where shift start and end times weren't properly aligned with employee fixed schedules when a shift template was applied. Now, shifts automatically use the shift template's hours, regardless of the employee's fixed schedule, ensuring accurate scheduling. This improves the reliability of shift planning.
Original PR description
__ ## Short functional explanation of the error Let's say we create a role containing employees with fixed schedules. Then, we create a shift template that applies on this role. When we create a…
__ ## Short functional explanation of the error Let's say we create a role containing employees with fixed schedules. Then, we create a shift template that applies on this role. When we create a shift, the starting and ending hours will take into consideration the hours of the employee's fixed schedule, instead of aligning with the shift template start and end hours. As discussed with XBO, the start and end hours of the shift should align with the shift template, despite the fixed working schedules having different start and end hours. ## Reproduction Steps 1. Go to Planning. Click on Configuration tab > roles. 2. Create a role and add an employee as a resource This employee has to have a fixed working schedule. 3. Click on Configuration tab > Shift Templates. 4. Create a new Shift Template. Select starting and ending hours different from the employee's fixed schedule. Select the role you just created. 5. Click on Schedule tab > By resource and click on New. 6. Select the role you just created. ### Expected behavior The start and end hours should align with the shift template start and end hours. ### Unexpected behavior The start and end hours are aligned on the employee's fixed working schedule: if the employee has a schedule from 8 to 16h36 and the shift template goes from 10 to 18, the starting and ending hours will be 10 to 16h36. ## Origin of the issue We kept computing the working intervals of employees, even if a shift template was set: https://github.com/odoo/enterprise/blob/8b00363e5e461f11b9736354d94e520e21932e71/planning/models/planning.py#L656-L664 Which isn't necessary in the case where a shift template has been set, as the start and end time are determined by the shift template, and not the employee's schedule. __ opw-5898509 Forward-Port-Of: odoo/enterprise#108412 Forward-Port-Of: odoo/enterprise#107018
This update corrects a display issue in the Timesheet grid view. Previously, hovering over the total overtime cell showed 'Weekly Overtime' instead of the correct 'Total Overtime'. The change ensures accurate overtime reporting across daily, weekly, and monthly views, improving data clarity for users.
Original PR description
### Issue: When displaying the month in the grid view and hovering the bottom right cell, where the total overtime is displayed, it shows "Weekly overtime". ### Steps to reproduce: - Open Timesheet app - In "My Timesheet", display the grid in day or month - Hover the bottom right cell - It displays "Weekly Overtime" ### Solution: Rename it to "Total overtime" to handle all periods (day, week, month). opw-5502864 Forward-Port-Of: odoo/enterprise#108594 Forward-Port-Of: odoo/enterprise#107642
This update enhances UrbanPiper to allow discounts to be applied directly to individual products within orders, rather than the entire order total. This ensures order totals, payments, and taxes accurately reflect these line-level discounts, improving pricing accuracy and customer satisfaction. This change addresses a previous limitation in UrbanPiper's discount handling.
Original PR description
Before this commit: ================ - Discounts were only applied to the entire order. - Product-level (line) discounts were not handled in UrbanPiper. After this commit: ================ - Product-level discounts can be applied to individual products in UrbanPiper. - Order totals, payments, and taxes now correctly reflect line-level discounts. Task - 4977960 Forward-Port-Of: odoo/enterprise#108603 Forward-Port-Of: odoo/enterprise#97114
This update aligns the user interface of the Sign Now wizard to provide a more consistent experience, regardless of whether the user initiates a signature request through the 'Sign Now' option or the 'Send Request' option (including self-sign and direct send). This enhances usability and reduces confusion for users.
Original PR description
in this commit i alligned the UI of sign send request wizard to look similar for both cases when the user click sign now and when the user click send request (self sign and send request) Task: 5942397
This update resolves an issue in the commission report where incorrect record IDs were being passed to the JavaScript framework, leading to potential data conflicts. By using larger integer IDs (bigints), the system now reliably identifies and links related records, ensuring accurate commission calculations and report generation. This improves the overall reliability of the sales commission reporting process.
Original PR description
In commission report, we need unique ids for achievements and commissions. We avoid using row_number because it becomes really slow when the amount of records increases. That's why we need reliable unique ids, build from the account move line/sale order line/sale order log, user_id, commission rules. As it represents a lot of information stored inside a unique integer, bigint are necessary. It works great in python because int() can be used to handle bigint but JavaScript is not great with that. It will cast the value sent by the ORM silently and as a result, when the ORM is called back by the JS framework, it will pass a truncated id that either conflict with another record or may not exists (ids are generated using recipe). This commit ensure that the full id is always accessible and is used to browse records when the framework js contact methods. task-5973128
This update resolves an issue where the Work Entries button in the HR module would crash when an overtime record lacked a 'Stop' setting. The fix ensures the system handles missing 'Stop' data correctly, preventing the error and allowing users to access Work Entries data without interruption. This improves stability and usability.
Original PR description
Clicking the Work Entries smart button raises a traceback when an overtime record has no Stop (time_stop). Steps to reproduce the error: - Install ``hr_work_entry_attendance`` module with demo data -…
Clicking the Work Entries smart button raises a traceback when an overtime record has no Stop (time_stop). Steps to reproduce the error: - Install ``hr_work_entry_attendance`` module with demo data - Activate developer mode - Create an Employee A > Settings > Set Default Ruleset in Overtime Ruleset In Payroll Tab, Work Entry Source: ``Attendances`` and set Contract - Create an overtime attendance > Save > Open the Overtime Details > Unset the ``Stop(time_stop)`` > Save - Open Employee A > Click on Work Entries smart button Traceback: ```py TypeError: '<' not supported between instances of 'bool' and 'datetime.datetime' ``` https://github.com/odoo/enterprise/blob/56c3723a925f718ba39d11cde12933542ebcd7c1/hr_work_entry_attendance/models/hr_version.py#L49-L52 When ``stop(time_stop)`` is unset in the overtime, ``ot.time_stop`` is False, causing ``min()`` to compare a ``datetime`` with ``False``, which raises the above traceback. sentry-7169332615 Forward-Port-Of: odoo/enterprise#108392 Forward-Port-Of: odoo/enterprise#103764
This update resolves a problem where the booking management page wouldn't fully load after a page refresh in the Odoo POS system. The fix ensures the booking view renders correctly, improving the user experience when refreshing the page. This prevents disruptions to appointment scheduling.
Original PR description
Steps: ----- - Install pos_appointment and pos_urban_piper modules. - Open a session for an UrbanPiper-configured POS. - Open the Manage Booking page. - Refresh the page. Issue: ----- - The booking view is not rendered after a page refresh. Cause: ----- - An awaited request in the posStore setup caused the `ActionComponent` not to be rendered yet when the `doAction` was called. Fix: ----- - First render the `ActionComponent`, then fetch the action data, and finally call `doAction`, so the action is executed seamlessly without interruption. Task-5713125 Forward-Port-Of: odoo/enterprise#105629
This update corrects a formatting issue in the Eco Voucher export file generated by the payroll module, ensuring it aligns with the requirements of the Monizze system. This resolves a potential problem preventing accurate data transfer and reporting for Belgian employees.
Original PR description
This commit realigns the xlsx header with what's expected by Monizze for the eco voucher export. Forward-Port-Of: odoo/enterprise#108668
This update corrects a display issue in the appointment form where the time fields were being cut off. The changes align the time field format with a recent update, ensuring all time information is fully visible and accurate. This improves the user experience for scheduling appointments.
Original PR description
Purpose ======= Fix the appointment type form view float time fields length to not crop content. Specification ============= Following odoo/odoo#240555 the float time field format has been updated. Adapting all the appointment form view float time fields length to match the new format and not crop the content. Removing useless "hour(s)" suffix as the time representation, whether it's hours or minutes, is now represented inside the field format. Hiding the seconds as it's not relevant for appointments. Task-5717052 Forward-Port-Of: odoo/enterprise#108639
This update resolves an issue where duplicate receipts were appearing on point of sale tickets. The problem stemmed from a double sending of confirmation messages due to a specific browser interaction. This change ensures receipts are generated correctly, improving the customer experience and preventing potential errors.
Original PR description
This PR fixes two same worldline receipts appearing on the point of sale ticket Reproduced by blocking the action url in browser but not the event one. Websocket fallback action is sent and the confirmation is sent both to the longpolling and websocket, resulting in _setCardAndReceipt method being called twice. Forward-Port-Of: odoo/enterprise#108570
This update resolves a rounding issue that occasionally resulted in incorrect stock quantities being displayed when scanning barcodes in delivery orders. The fix ensures more accurate stock level calculations, improving order fulfillment reliability. This impacts the accuracy of stock tracking within the system.
Original PR description
To reproduce the issue: - Create a stock quantity of product1 for example of 275.84 kg in PACK1 - Create a delivery order of 3.6 kg - Go to the delivery order on stock barcode - Scan PACK1 - The new line is created as 272.2399999999 Forward-Port-Of: odoo/enterprise#108566 Forward-Port-Of: odoo/enterprise#89300
This update resolves a compatibility problem between Odoo's database (PostgreSQL) and its document signing module. Specifically, an error related to database restrictions was triggered in PostgreSQL version 18. The change was triggered by a shift in testing procedures, revealing a previously undetected issue.
Original PR description
pg16 apparently triggers `foreign_key_violation` (23503) on both `ON DELETE NO ACTION` and `ON DELETE RESTRICT`, pg18 triggers `restrict_violation` (23001) on the latter. Not sure about pg17 as I don't feel like installing one locally. Didn't catch this issue previously as I only routinely run `post_install` tests.
This update resolves an issue where manually created payroll rules would cause updates to the standard rules to fail. Now, users can successfully modify rule parameters even after a manual entry has been made, ensuring accurate payroll calculations. This improves the flexibility and reliability of the HR payroll module.
Original PR description
Purpose ======= If an value is created manually for a given date, the module update will fail once the standard one in data is created.
This update resolves an issue where the 'Swiss Wage Type Code' column was incorrectly displayed in the payroll salary rules view, even when a Swiss company wasn't selected. The fix makes this column optional, ensuring it's only added when needed, improving data accuracy and usability.
Original PR description
Bug reproduction: Install l10n_ch_hr_payroll module or swiss payroll, go to payroll -> salary rules and you will see swiss wage type code column even though the swiss company is not selected Bug cause: After installing l10n_ch_hr_payroll module, in the new view this field is inserted to the view and it is not related to which company is selected at the moment Bug solution: Making the field optional so that it is not there by default but optionally it can be added to the view. task - 5914530
This update resolves a technical issue where an outdated initialization process was still being used within the account chart template module. Removing this redundant step ensures the system functions correctly and avoids potential performance impacts. This change improves the stability and efficiency of financial reporting.
Original PR description
Commit #371a800 removes registry._init but there is a remaining occurrence in account_accountant for the chart templates.
This update fixes an issue where VAT amounts were incorrectly displayed as zero in XML reports generated from manual journal entries. The fix removed a filtering condition that was incorrectly excluding standard journal entry lines from VAT calculations, ensuring accurate VAT reporting for MA Company users.
Original PR description
## Issue: When creating a manual journal entry with a deductible tax, the entry was included in the XML export, but the VAT amounts were all set to 0 ## Cause: The SQL query used to compute VAT amounts included an extra condition on display_type to be 'tax' However, journal entry lines are standard product lines and should not be excluded by this condition As a result, the amounts (MHT, TVA, TTC) were incorrectly computed as 0 in the XML ## Steps to reproduce: - Install `l10n_ma_reports` and switch to the MA Company - Create a Journal Entry (Any account, Debit: 100, Taxes: 10% 150) - Open the Tax Report for the current month - Export the XML using the gear icon Before the fix, the value for mht, tva and ttc where all 0 opw-5226529 Forward-Port-Of: odoo/enterprise#108644
This update corrects a minor oversight in the system's invoice matching tolerance settings. The previous version had a hardcoded tolerance value that wasn't updated, leading to potential inaccuracies in bank statement reconciliation. This fix ensures more reliable matching of financial transactions.
Original PR description
During this commit:https://github.com/odoo/enterprise/commit/15d26e62f14bb0224712a1712b47ebe16c3b8702 we forgot to change one part of the hardcoded tolerance. task-5952881 Forward-Port-Of: odoo/enterprise#108377 Forward-Port-Of: odoo/enterprise#108112
This update resolves an issue where products with unique serial numbers in Odoo's Point of Sale (POS) system were not correctly tracked. The change ensures that order line configurations are properly handled when serial numbers are involved, improving product traceability and accuracy within the POS system. This fix enhances the reliability of sales transactions.
Original PR description
In this commit: = - Overridden `requiresOrderLineConfiguration` so that `configureNewOrderLine` is also called when lot or scale configuration is required. task-5505855 related pr: https://github.com/odoo/odoo/pull/245165 Forward-Port-Of: odoo/enterprise#108263
This update resolves a validation error occurring during tax calculation for Brazilian invoices using the avatax service. The issue stemmed from incorrect tax data being sent to avatax, leading to invoice rejection. This fix ensures accurate tax calculations and prevents invoice processing failures.
Original PR description
Steps to reproduce: - Set up a Company with BR localization - Create a product as follows: - [General Information] Product Type: Service - [Sales] LC116 Code: 14.01 - [Sales] Purpose of Use: Not…
Steps to reproduce: - Set up a Company with BR localization - Create a product as follows: - [General Information] Product Type: Service - [Sales] LC116 Code: 14.01 - [Sales] Purpose of Use: Not applicable - [Sales] Service Code Origin: 14.01.3/168061/1524 - [Sales] Service Codes: 14.01.3/168061/1524 - Create an Invoice with Document Type "Electronic Service Invoice - NFS-e" - Add the product on the line - Compute taxes - Compute taxes again Issue: Action will be blocked by a validation error resulting from the external taxes call ``` odoo.exceptions.ValidationError: Odoo could not fetch the taxes related to Draft Invoice. Errors: Rejection: Total Installments doesnt match Total Lines ∑ installments[m]grossValue - ∑ (lines[n].lineAmount-line[n].lineTaxedDiscount) <> 0 ``` It occurs because during the call the system is considering the existing taxes on the line and it will send to the avatax service wrong amounts opw-5412456 opw-5409735 Forward-Port-Of: odoo/enterprise#108403 Forward-Port-Of: odoo/enterprise#108088
This update corrects a calculation error in the Gantt view's 'Total' row, ensuring accurate hour counts regardless of the employee's timezone. Previously, shifts were miscalculated due to a failure to account for timezone differences when determining working hours. This ensures planning data reflects actual working times.
Original PR description
### Issue: Having a calendar with a timezone different from utc and looking at the planning gantt view, the hours displayed in the "Total" row are wrong. ### Steps to reproduce: - Have an employee…
### Issue: Having a calendar with a timezone different from utc and looking at the planning gantt view, the hours displayed in the "Total" row are wrong. ### Steps to reproduce: - Have an employee with a calendar in "Europe/Brussels" and working from 8 to 17 - In planning add a line for this employee - Display the gantt view on a day - Create a shift for this employee from 8 to 17 - In the "Total" row, the first hour is not counted ### Cause: To compute the values displayed in the Total row, we take the intersection of the shift and the working hours from the calendar. ([src](https://github.com/odoo/enterprise/blob/2b887d094c66be7aebd92fbf735b1852f5dde4b5/planning/static/src/views/planning_gantt/planning_gantt_renderer.js#L318)) But the working hours from the calendar are given in UTC for this computation (without conversion), this result in a discrepancy between the actual hours of the calendar (with timezone conversion) and the one given to compute the total row. ### Solution: `resource_work_intervals()` returns the work intervals with the calendar hours and the resource timezone. In our case, only the hours are interesting (the previous code replaced the timezone by UTC). We need to convert them from the calendar timezone to UTC. So the first thing to do is remove the timezone from `resource_work_interval` then we localize it in the calendar timezone and to finish we convert it to UTC. opw-5564749 Forward-Port-Of: odoo/enterprise#108669 Forward-Port-Of: odoo/enterprise#106891
This update fixes a technical issue where certain Intrastat codes were incorrectly marked as expired. The codes, referenced in official Belgian documentation, were actually still valid. This ensures accurate reporting for international trade data within Odoo Enterprise.
Original PR description
99450000, 99500000, 99600000 & 99700000 were erroneously expired. They are still active : https://www.nbb.be/doc/dd/onegate/data/intrastat_manual_basis_en.pdf page 13 Forward-Port-Of: odoo/enterprise#108451
This update fixes a problem where users wouldn't receive helpful information when printing PDF payroll reports with incorrect layouts. Now, when an invalid layout is used, a detailed error message is displayed, making it easier to identify and correct the issue. This ensures reports always generate correctly.
Original PR description
Currently, when a user tries to print a PDF report with an invalid document layout template, there’s no traceback to show what went wrong. **Steps to produce:** * Install payroll with demo data. *…
Currently, when a user tries to print a PDF report with an invalid document layout template, there’s no traceback to show what went wrong. **Steps to produce:** * Install payroll with demo data. * Settings > Configure Document Layout then Edit Layout * Add non-existent field `<div t-if='o.no'/>` * Payroll > All payslips > print any payslip **Observed Behavior:** * Currently it only shows the error in [1], with no context or traceback to explain what went wrong. **Root cause:** * This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6]. **Solution:** * Catching and raising UserError shows appropriate traceback. **Before:** <img width="1601" height="507" alt="image" src="https://github.com/user-attachments/assets/f7f208f0-cdd7-410e-87e7-32a9651df9d8" /> **After:** <img width="1847" height="928" alt="image" src="https://github.com/user-attachments/assets/c73522d6-2632-422b-b1d1-234e6c61ed2e" /> [1]: https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing [2]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 [3]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 [4]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 [5]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 [6]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575 Related:https://github.com/odoo/odoo/pull/237262 opw-5167898 Forward-Port-Of: odoo/enterprise#108563 Forward-Port-Of: odoo/enterprise#100142
This update fixes a bug in the Gantt view for work orders, improving its accuracy and usability. Specifically, the view now correctly displays work order scheduling and allows users to manage 'blocked' work orders, enhancing workflow visibility.
Original PR description
- Use the old 'workcenter' gantt view rather than the 'production' (and remove it) - Create a new Work Center calendar - Add variant name in workorder display name - Add the falsy label to employee_assigned_ids (for Gantt view mainly) - Restore the possibility of not planning the 'blocked by' workorders - Reload after Plan in Gantt view task: 5946267 Forward-Port-Of: odoo/enterprise#108091
This update resolves a problem where contract signature requests would fail with a 404 error and an incorrect date validation error when a linked offer wasn't present. The fix checks for the existence of an offer before attempting to update the contract, ensuring proper signature validation and preventing errors. This improves the user experience for contract signing.
Original PR description
Steps to reproduce: 1- On an employee page, create a new signature request for a document through the gear icon 2- Log in with the employee (ex. Marc Demo) and sign the contract 3- It will be signed but you will still get an <error 404 not found> page as it redirects to an offer that does not exist 4- Log in with the admin again to counter sign the document 5- You will get an error saying contract end date cannot be before contract start date Cause of the bug: We don't have an offer linked to the document we're signing. We can test this with the demo employee_contract.pdf or Employee Termination.pdf. The logic inside the sign() function will try to update the employee's version with fields from the offer which we don't have as it assumes this is a new offer. Fix done: Check if we have an offer linked to this sign request at first, if not return the default behavior that validates the signature. task-5423393 Forward-Port-Of: odoo/enterprise#102934
This update corrects a bug in the Belgian VAT reporting module that caused key fields ('Ask Restitution' and 'Client Nihil') to be missing from the generated PDF reports. The change restores a previous wrapper that correctly identifies the intended section for injecting these specific fields. This ensures accurate and complete VAT return documentation for Belgian businesses.
Original PR description
This commit https://github.com/odoo/enterprise/commit/e8d2084369d58717c2294e023cbdfd60f713c334 removed the `pdf_options_header` wrapper. 18.3-:…
This commit https://github.com/odoo/enterprise/commit/e8d2084369d58717c2294e023cbdfd60f713c334 removed the `pdf_options_header` wrapper.
18.3-:
https://github.com/odoo/enterprise/blob/ce67bf6fb4f694c25785580fe3ed290bcb8c92b5/account_reports/data/pdf_export_templates.xml#L151-L154
18.4+:
https://github.com/odoo/enterprise/blob/e3746aba3c334a628a15a4263ddfa08876d2a288/account_reports/data/pdf_export_templates.xml#L159-L160
This broke `l10n_be_reports` which uses `(//div[hasclass('row')])[last()]` to inject BE-specific fields:
https://github.com/odoo/enterprise/blob/e3746aba3c334a628a15a4263ddfa08876d2a288/l10n_be_reports/data/tax_report.xml#L9-L24
Without the wrapper, `[last()]` targets the conditional `aml_ir_filters` row instead, making BE fields invisible.
Steps to reproduce:
1. Create a Belgian company
2. Navigate to Accounting → Reporting → Tax Return
3. Create a VAT Return and submit it
4. Check the generated PDF in the attachment
=> The "Ask Restitution" and "Client Nihil" fields are missing from the PDF header.
Ticket [link](https://www.odoo.com/odoo/action-4043/5509725)
opw-5509725
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/enterprise#107519This update resolves an issue preventing early bill printing with the Italian fiscal printer, which was causing errors and preventing the receipt from printing correctly. The fix ensures the printer functions as intended, allowing for immediate receipt printing without technical problems.
Original PR description
Fix 1: ------- Using the early receipt printing option leads to a traceback when using the italian fiscal printer. Steps to reproduce: ------------------- * Setup the italian fiscal printer for a…
Fix 1:
-------
Using the early receipt printing option leads to a traceback when using the italian fiscal printer.
Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: Traceback
Why the fix:
------------
Initially the traceback is related to trying to read `decimal_places` out of undefined. The current order doesn't have yet a currency.
To solve this initial issue we can just take the currency of the config if there's none on the order. The pos does not handle multicurrency so the order will always have the same currency as the config anyway.
After solving this part another issue would still happen. If the order was no sent to the kitchen yet. Such orders are not yet synced to the backend and do not have an id of type number. If the order had been send to the display.
This scenario was sending the printer, the data to print and with a successful print we were trying to sync data to the server with
```
await this.data.write("pos.order", [order.id], updateData);
```
which was triggering an error in `orm_services` with `validatePrimitiveList`.
> Invalid ids list: pos.order_4
If we try to reprint AGAIN the bill for some reason, we get another traceback. It's because the nb_print is now 1 and therefore we now try to print with
```
printResult = await this.fiscalPrinter.printContentByNumbers({
order: order,
});
```
which will try to split undefined here
```
this.receiptNumber = this.props.order.it_fiscal_receipt_number;
const dateParts = this.props.order.it_fiscal_receipt_date.split("/");
```
Those two last issues are solved by not syncing the data to the server when we simply print the bill early.
-------
-------
Fix 2:
-------
Currently the early printing option does not work as desired. The fiscal printer does not print the receipt.
Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: the printer stops in the middle of printing the receipt
Why the fix:
------------
The early receipt was trying to be printed as a fiscal document. However it cannot be considered as such.
We backport this fix that enables basic receipt printing and alter it to also work with early printing.
Fix being backported: https://github.com/odoo/enterprise/commit/b8fd13b802729ccee080ab14f2958d59f57d0f97
There are a few differences between the early receipt and the basic print, mainly the fact that prices need to be shown on the early receipt.
There are a few differences with the original commit. In the documentation of the printer, `printNormal` uses data and the original commit mixes between `data` and `message` so it is harmonized here.
opw-5387572
Results:
-----------
Basic receipt:
<img width="672" height="835" alt="image" src="https://github.com/user-attachments/assets/3de96523-22db-4a27-adbd-3464802604aa" />
Early receipt:
<img width="658" height="842" alt="image" src="https://github.com/user-attachments/assets/f6b7ab24-e27b-4deb-8d5f-1b0c41bb28f0" />
Forward-Port-Of: odoo/enterprise#108234
Forward-Port-Of: odoo/enterprise#105511