Daily updates from Odoo
Thursday, February 26, 2026
290 changes
21 changes
Resolved issues and error corrections
This update fixes an issue where preparation tickets weren't printed correctly when using the self-ordering kiosk mode. The fix prevents a system update from overwriting key data, ensuring preparation tickets are generated reliably during kiosk transactions. This improves the overall kiosk ordering experience.
Original PR description
Steps: --- - Configure a preparation printer and enable it for kiosk mode. - Open a kiosk session. - Place an order and complete it. Issue: --- - Preparation tickets were not printed in kiosk mode. Cause: --- - In kiosk flow, preparation changes are sent on conformation page. - After sync, `LOPC` was overwritten, preventing preparation data from being processed. Fix: --- - Do not update `LOPC` when self-ordering mode is kiosk. - Refactor and re-enable preparation ticket checks in unit tests. task-5973158 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves intermittent test failures related to image loading on the website. By proactively fetching and caching images, the test suite now completes much faster – reducing the time from 26.7 seconds to 15.4 seconds. This improves the stability and reliability of our website tests.
Original PR description
Background option tests were failing in nightly builds sometimes because of the network hang. This commit aims to fix the errors by prefetching the images and caching them. Here's the `background_option` test suite and the total time it took to finish with a throttled network (fast 4G) before and after the commit, respectively. | Before commit | With commit | |--------|--------| |<img width="610" height="224" alt="image" src="https://github.com/user-attachments/assets/a98fb1fe-27a1-4f73-901f-7d7ade8ecd86" />|<img width="610" height="224" alt="image" src="https://github.com/user-attachments/assets/c9ed0948-8112-4f2b-b843-c887c9302b76" />| | 26.7 (s) | 15.4 (s) | runbot-237641 Forward-Port-Of: odoo/odoo#250578 Forward-Port-Of: odoo/odoo#249074
This update corrects a bug that prevented the inclusion of specific fields (Ask Restitution and Client Nihil) in the Belgian VAT return PDF reports. The change re-enabled a key mechanism for customizing reports, ensuring accurate and complete VAT return documentation. This resolves an issue reported by users generating these reports.
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 corrects a technical issue where the 'is_company' field wasn't accurately determined in Odoo's localization modules for Brazil and Ecuador. Specifically, it now correctly identifies companies based on their identification type (CNPJ and RUC) and, for other countries, flags a partner as a company if a VAT number is provided. This ensures accurate reporting and compliance.
Original PR description
`is_company` was not correctly computed in some localization modules. This commit adds a compute method for: - l10n_br*: Company if identification type is CNPJ - l10n_ec*: Company if identification type is RUC For foreign partners (country ≠ BR/EC), a partner is considered a company if a VAT is provided. Follow-up of: https://github.com/odoo/odoo/pull/211043 Task-5947797 Forward-Port-Of: odoo/odoo#249037
This update corrects a bug in Odoo's localization modules (l10n_br and l10n_ec) that incorrectly identified companies. Now, the system accurately determines if a partner is a company based on their identification type (CNPJ or RUC) in Brazil and Ecuador. For other countries, a partner is considered a company if a VAT is provided.
Original PR description
`is_company` was not correctly computed in some localization modules. This commit adds a compute method for: - l10n_br*: Company if identification type is CNPJ - l10n_ec*: Company if identification type is RUC For foreign partners (country ≠ BR/EC), a partner is considered a company if a VAT is provided. Follow-up of: https://github.com/odoo/enterprise/pull/86089 Task-5947797 Forward-Port-Of: odoo/enterprise#107674
This update corrects a bug in the website's image carousel that prevented correct navigation in right-to-left languages like Arabic. By adding a specific HTML attribute, the carousel now correctly displays the next and previous images when using the arrow keys, ensuring a consistent user experience regardless of the website's language setting.
Original PR description
Some libraries expect to find the language direction on the HTML element (e.g. Bootstrap). As we didn't set it, there were some issues. For instance on the website: - set the website language to some RTL language (e.g. Arabic) - drop an image gallery snippet and save - navigate with the keyboard to the carousel and start using the arrows to switch images => Pressing left should show the _next_ image, and pressing right should show the _previous_ image (contrary to LTR languages). This is illustrated by the image indicators at the bottom of the carousel (the 1st image is on the right, the last image on the left). But without `dir="rtl"` on the HTML element, the arrows keep their LTR behavior: pressing left goes to the previous image, and right to the next image. task-5109547 Forward-Port-Of: odoo/odoo#250668 Forward-Port-Of: odoo/odoo#240611
This update fixes an issue where the payroll update process would fail when a common working schedule was deleted. The fix ensures that payroll data continues to update correctly, even after a schedule is removed, preventing data inconsistencies. This impacts all supported countries.
Original PR description
*:ae,au,bd,be,ch,eg,id,jo,ke,lt,lu,ma,my,nl,pk,pl,ro,sk,tr,us When the ``Standard 40 hours/week`` working schedule is deleted and the ``Payroll: Update data`` cron runs, a traceback is raised. For…
*:ae,au,bd,be,ch,eg,id,jo,ke,lt,lu,ma,my,nl,pk,pl,ro,sk,tr,us
When the ``Standard 40 hours/week`` working schedule is deleted
and the ``Payroll: Update data`` cron runs, a traceback is raised.
For ``l10n_us_hr_payroll`` module
Steps to reproduce the error:
- Install ``l10n_us_hr_payroll`` module with demo data
- Go to Employees > Configuration > Settings > Change Company Working Hours
- Go to Working Schedules > Delete ``Standard 40 hours/week`` working schedule
- Run the ``Payroll: Update data`` cron
Traceback:
```py
ValueError: External ID not found in the system: resource.resource_calendar_std
ParseError: while parsing /home/odoo/src/enterprise/l10n_us_hr_payroll/data/hr_payroll_structure_type_data.xml:3, somewhere inside <record id="structure_type_employee_us" model="hr.payroll.structure.type">
<field name="name">United States: Employee</field>
<field name="default_resource_calendar_id" ref="resource.resource_calendar_std"/>
<field name="country_id" ref="base.us"/>
</record>
```
The ``Payroll: Update data`` cron updates payroll data that references
the ``Standard 40 hours/week`` working schedule.
If the user has deleted this working schedule, the external ID no longer exists,
leading to the above traceback.
sentry-7166574553
Forward-Port-Of: odoo/enterprise#108730
Forward-Port-Of: odoo/enterprise#106950This update fixes an issue where kits with multiple components were incorrectly showing a zero cost when using FIFO or average costing methods. Now, the system accurately calculates the total cost of a kit, ensuring accurate inventory and sales reporting. This improves the reliability of our point-of-sale and manufacturing processes.
Original PR description
Before this commit, if a kit had multiple components, the cost of the line was counted as zero if the product cost method was FIFO or average. opw-5911338 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247833
A small typo in the code processing messages from Mercado Pago was causing errors and preventing successful payments. This update corrects the typo, ensuring Mercado Pago payments are now processed correctly. This resolves a technical issue impacting payment functionality.
Original PR description
On receiving a message from Mercado Pago on the webhook, there was a typo causing a traceback and preventing the payment from being confirmed. This commit corrects the typo. opw-5953884 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250818
This update resolves a visual issue in the Discuss app where a horizontal scrollbar would appear on smaller screens. The fix adjusts how the app's layout adapts to different window sizes, ensuring a consistent and usable experience for all users. This improves the app's responsiveness and usability.
Original PR description
Before this commit, when Odoo browser had a relatively small width but still desktop width, the Discuss app had sometimes an horizontal scrollbar. Steps to reproduce: - Open General with Demo data on…
Before this commit, when Odoo browser had a relatively small width but still desktop width, the Discuss app had sometimes an horizontal scrollbar. Steps to reproduce: - Open General with Demo data on 1080p monitor - have window take slightly below half of screen width => The Discuss app has horizontal scrollbar, from sidebar non-compact, message list, and the member panel all open at once. This horizontal scrollbar comes from the General demo data that has a sub-thread preview from the 1st message. A sub-thread preview has a max-width of 400px, which shouldn't be an issue on itself. However due to parented container not having `min-width: 0`, it didn't want to shrink lower than this max-width. This commit fixes the issue with `o-min-width-0` on the parented container to make sure this can shrink lower than the sub-thread preview's max width of 400px. Task-5956698 Before / After <img width="882" height="635" alt="Screenshot 2026-02-20 at 16 36 14" src="https://github.com/user-attachments/assets/516b66a1-f8d2-4ee9-b62f-6d94dfe98d11" /> <img width="884" height="637" alt="Screenshot 2026-02-20 at 16 37 07" src="https://github.com/user-attachments/assets/987f418c-f7e2-477b-ae9c-6c68d6a21ec5" /> Forward-Port-Of: odoo/odoo#249846
This update resolves an issue where contract signing requests would fail with error messages due to a missing link between the contract and an employee offer. The fix checks if an offer exists before attempting to update the contract, ensuring proper signature validation and preventing redirect errors. This improves the user experience for employees and administrators.
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 discrepancy in payslip calculations for employees using the private car daily allowance. The daily amount is now rounded to two decimal places, ensuring the displayed value aligns with the total amount calculated by multiplying quantity and rate on payslips. This improves the accuracy and transparency of payroll reporting.
Original PR description
Round the computed daily private-car salary rule amount to 2 decimals so the displayed per-day value matches Quantity × Amount on payslips. References task-5917569 Forward-Port-Of: odoo/enterprise#108498 Forward-Port-Of: odoo/enterprise#106753
This update resolves an issue where gift card payments on Ecuadorian POS orders were incorrectly flagged as requiring an SRI payment method. The fix automatically applies the SRI payment (code '01') when a POS order has no associated payments, ensuring accurate invoicing and compliance. This prevents errors and improves the user experience for customers using gift cards.
Original PR description
When a POS order has no payment associated (e.g. when the order is fully paid with a gift card), the SRI payment method was not set on the invoice Steps to reproduce: ------------------- * Create a PoS in Ecuador with the l10n_ec_edi_pos module installed * Create a gift card program and some gift cards * Create a PoS order and pay it fully with a gift card and invoice it > Observation: You get an error saying that the SRI payment method is required Why the fix: ------------ When setting the SRI payment method on the invoice, we check if there are more than 1 payment associated with the order, and if not we fallback on the SRI payment with code "01" opw-5432004 Forward-Port-Of: odoo/enterprise#107966
A recent change was causing the 'Publish & Send' button to disappear in the scheduling interface. This fix removes a temporary workaround and directly addresses the root cause by removing the unnecessary condition affecting button visibility. This ensures the 'Publish & Send' button remains visible when scheduling.
Original PR description
## Issue Since commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2, `planning_test_tour_no_email` is failing when trying to click on the (missing) `Publish & Send` button. ## Cause The…
## Issue
Since commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2, `planning_test_tour_no_email` is failing when trying to click on the (missing) `Publish & Send` button.
## Cause
The commits adds the `my_planning_action` attribute to the context when opening the `Schedule by Resource`. This allowed to display the `I Take It!` button when opening an open shift, but it also removed the `Publish & Send` button, as its condition to be invisible consistently contains `context.get('my_planning_action')` [[1](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L11), [2](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L78-L79), [3](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L273-L274)].
## Fix
The objective is to fix the bug from previous commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2 differently. Instead of adding the `my_planning_action` to the context, we remove the conditions on the `I Take It!` button.
runbot-241028
Forward-Port-Of: odoo/enterprise#108333This update fixes an issue where delivery slips incorrectly calculated package weight by omitting the weight of products inside. The change ensures that the total shipping weight accurately reflects the weight of the outermost package and its contents, improving shipping accuracy and cost calculations. This impacts all users who rely on delivery weight information.
Original PR description
On delivery slip, the total weight of a package doesn't include the weight of the product in the outermost package. Steps to reproduce: ------------------- * Create a Package "Pa" with a package type…
On delivery slip, the total weight of a package doesn't include the weight of the product in the outermost package. Steps to reproduce: ------------------- * Create a Package "Pa" with a package type that has a weight * Create a product "Po" tracked by quantity * Add two units of the product Po to the package Pa * Create Delivery with two units of Po. * Confirm the Delivery and print the delivery slip -> The total weight is the weight of the package type without including the products inside. Observation: ------------- When computing the shipping_weight for the delivery, it will fallback on the package_weight to calculate it weight, https://github.com/odoo/odoo/blob/ca14f1aa21a75398919c1453be19011522bb3b5c/addons/stock/models/stock_picking.py#L893-L906 It retrieve the weight calculated by _get_weight https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock/models/stock_package.py#L435 Except for the outermost package, where it incorrectly considers only the package type weight and does not include the products weight opw-5499770 Forward-Port-Of: odoo/odoo#250358 Forward-Port-Of: odoo/odoo#247227
This update fixes an issue where the website builder's sidebar wasn't properly blocked during reloadable actions, particularly under slow network conditions. Now, the sidebar remains blocked while templates are updated, ensuring a smoother and more reliable user experience for website customization. This enhancement improves the overall usability of the website builder.
Original PR description
When we perform a reloadable action in the builder, the builder's UI is not blocked, unlike in previous versions before the html_builder [refactoring] Steps to reproduce the issue: - Open website, and click on the header - In the dev tools, set the network throttling to 3G or slow 4G - Change the header's template => Notice that the sidebar is not blocked, while it should be. [refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-5952793 Forward-Port-Of: odoo/odoo#250753 Forward-Port-Of: odoo/odoo#249526
This update resolves a technical issue preventing the account reports annotation tour from functioning correctly. The change adjusts the confirmation button used in the tour to align with recent styling updates, ensuring the tour now triggers as intended. This improves the user experience for accessing and utilizing account reports.
Original PR description
This PR updates the account reports annotation tour to use the correct confirmation button after the dialog styling change, fixing the failing test trigger. community: https://github.com/odoo/odoo/pull/247708 task-5873845
This update resolves an issue where the stock valuation report was displaying inaccurate unit costs due to floating-point precision problems. The fix ensures more reliable calculations, particularly when dealing with small inventory quantities, preventing inflated or negative values. This improves the accuracy of inventory reporting.
Original PR description
Problem: In the `stock.avco.report`, there is a chance for floating point inaccuracies to cause avco unit cost to inflate. This occurs specifically when the remaining quantity is calculated to be a…
Problem: In the `stock.avco.report`, there is a chance for floating point inaccuracies to cause avco unit cost to inflate. This occurs specifically when the remaining quantity is calculated to be a positive number extremely close to 0. There are also issues with negative avco value that are tangential to this error. Solution: We will mirror the iterative logic from `_run_avco`, being sure to account for whether we have moved from negative quantity to positive or vice versa. Also, before calculating avco value as `total_value / total_quantity`, we will ensure `total_quantity` is not a floating point number very close to 0 to avoid unit cost inflation. Steps to replicate (Runbot 19): Have storage locations enabled to make this easier to test 1. Product with tracked inventory, avco perpetual valuation, non-zero cost 2. Set the on hand quantity to -0.3 Units 3. Set the on hand quantity to -0.2 Units 4. Set the on hand quantity to 0 Units (A well-known python quirk, that .1 + .2 = 0.30000000000000004) Go to the stock report and inspect the unit cost history for the product, note 1. The nonsense Unit Cost on the top row 2. The negative Unit Cost on the 2nd row Note to reviewer: I discussed this issue briefly with dafr, who pointed out that there are further adjustments to come with the `_run_avco` method, and several other issues with this report that are not addressed by this PR. However, the problems with this report are affecting a customer so we'd like to push these fixes forward for now. opw-5430300 Forward-Port-Of: odoo/odoo#245141
This update introduces a new ‘Net Cost’ salary rule in the UAE payroll system. Previously, rules deducting from employee pay incorrectly reduced employer costs. This change ensures accurate tracking of employer contributions by separating employee deductions from employer costs, improving financial reporting.
Original PR description
## Before: - Setting appears_on_employee_cost_dashboard to True on a salary rule uses the rule’s sign to compute employee cost. - For rules like Social Insurance Employee Contribution and DEWS Employee Contribution, the sign must be negative to deduct the amount from the employee, which incorrectly reduces the employer cost as well. ## After: - Introduced a new salary rule “Net Cost” to correctly reflect employer cost. - This allows employee contribution rules to keep a negative sign for deductions while still increasing the employer contribution amount. Task-5912761
This update streamlines the process of adding and locating bank accounts within Odoo Enterprise. The changes consolidate how bank accounts are handled across multiple modules, leading to a more consistent and reliable experience for users. This enhancement improves data accuracy and simplifies bank integration for financial transactions.
Original PR description
*: account_invoice_extract,hr_constract_salary,payment_sepa_direct_debit Forward-Port-Of: odoo/enterprise#108238
This update fixes a problem that was preventing accurate payslip calculations for employees with specific salary rules. The issue stemmed from how the system handled temporary input fields, leading to an error. This change ensures payslips are computed correctly regardless of how input fields are initially added or hidden.
Original PR description
**Steps to reproduce** - Have a salary rule - Condition based on: Salary Input - Input on: Employee - On the employee form, click on "Add inputs" in the Payroll tab - Add an input - Enter a value - Click on "Inputs" to fold the section and hide the input - Try to compute a new payslip for this employee, error: `ValueError: invalid literal for int() with base 10: 'separator_1'` **Cause** By default, the separator doesn't have a `value` key, but after the first interaction to hide its elements, it is added to keep track of the folded state (see `_toggleSeparators` in `web`). **Solution** Ensure separators are ignored. opw-5928247 Forward-Port-Of: odoo/enterprise#108731 Forward-Port-Of: odoo/enterprise#107326
13 changes
Resolved issues and error corrections
This update fixes an issue where contacts without names or emails in Odoo's chatter interface would display as 'Unnamed'. Now, when a contact lacks a name and email, the system will automatically show their display name instead, providing a more user-friendly experience. This ensures consistent and clear recipient identification across all Odoo apps.
Original PR description
Steps to reproduce =============== 1. Create a contact of type invoice address without name and email. 2. Go to any app with chatter. 3. Add this user to the recipient ----> Only the blue tick will be visible (recipient name will be empty) After this commit, we will use the display_name as a fallback to show in the chatter. Forward-Port-Of: odoo/odoo#240657 Forward-Port-Of: odoo/odoo#213545
This update resolves an issue where the agent subtitle in the chat window was consistently empty. The fix adds a mechanism to store and display the agent's subtitle, ensuring consistent and informative chat communication. This improves the user experience by providing context within the chat interface.
Original PR description
The chat subtitle is always empty, whether the agent description is set or not. Even though PR - https://github.com/odoo/enterprise/pull/93612 (merged earlier in saas-19.1 version) mentions that the subtitle should be visible. It is not visible because we are always getting `undefined` over here - https://github.com/odoo/enterprise/blob/38e66c4607cb1dad93f17591383c39d8c37c6e0b/ai/static/src/discuss/thread_patch.js#L10 This commit fixes the issues by extending the stored fields with subtitle and adding a default message if subtitle is missing. Something similar is implemented in this commit (merged in master) - 9bdec04a7e6f127f6a5dfbf975f7ae0d7e89bc1a Task-5916227
This update resolves an issue where the Discuss app would display a horizontal scrollbar on smaller screens. The fix adjusts how the app's layout adapts to different window sizes, ensuring a consistent and usable experience across devices. This improves the overall user experience for the Discuss app.
Original PR description
Before this commit, when Odoo browser had a relatively small width but still desktop width, the Discuss app had sometimes an horizontal scrollbar. Steps to reproduce: - Open General with Demo data on…
Before this commit, when Odoo browser had a relatively small width but still desktop width, the Discuss app had sometimes an horizontal scrollbar. Steps to reproduce: - Open General with Demo data on 1080p monitor - have window take slightly below half of screen width => The Discuss app has horizontal scrollbar, from sidebar non-compact, message list, and the member panel all open at once. This horizontal scrollbar comes from the General demo data that has a sub-thread preview from the 1st message. A sub-thread preview has a max-width of 400px, which shouldn't be an issue on itself. However due to parented container not having `min-width: 0`, it didn't want to shrink lower than this max-width. This commit fixes the issue with `o-min-width-0` on the parented container to make sure this can shrink lower than the sub-thread preview's max width of 400px. Task-5956698 Before / After <img width="882" height="635" alt="Screenshot 2026-02-20 at 16 36 14" src="https://github.com/user-attachments/assets/516b66a1-f8d2-4ee9-b62f-6d94dfe98d11" /> <img width="884" height="637" alt="Screenshot 2026-02-20 at 16 37 07" src="https://github.com/user-attachments/assets/987f418c-f7e2-477b-ae9c-6c68d6a21ec5" /> Forward-Port-Of: odoo/odoo#249846
This update resolves an issue where the salary calculator incorrectly used a default full-time calendar, leading to inaccurate calculations when simulating employees with different work hours. The fix ensures the calculator now correctly applies the selected work schedule (e.g., 40h/week or 20h/week) for accurate salary simulations. This improves the reliability of payroll calculations.
Original PR description
Steps to reproduce: 1- Go to Payroll > Employees > Salary calculator 2- Put a yearly cost of 10000 3- Select the "40h/week calendar" 4- Check the yearly cost 5- Change to "20h/week calendar" Cause of the bug: _get_version inside ContractSalaryOffer would take the default calendar from the version if it exists (in our case it will always be the full time for the simulation employee) Fix done: Keep the condition as it is for normal offers, and for simulation offers change the default to the selected resource calendar task-5431216 Forward-Port-Of: odoo/enterprise#103159
This update resolves a visual glitch in the Email Marketing app where test emails were incorrectly showing as 'removed' in related contact records' Chatter. The fix ensures that test messages are automatically removed when sent, preventing this misleading display and maintaining a clean user experience. This improves the reliability of test emails.
Original PR description
**Steps to reproduce:** - Go to Email Marketing app - Create a mailing campaign - Set its recipients to Contact - Click on the test button to send a test mail to any mail - Go to the first contact…
**Steps to reproduce:**
- Go to Email Marketing app
- Create a mailing campaign
- Set its recipients to Contact
- Click on the test button to send a test mail to any mail
- Go to the first contact record
- Chatter will show `This message has been removed` message
**Issue:**
Previously, message created for testing were ignored by the Chatter as they were empty. As we now keep empty messages visible but with removed content display, they shows up on related records.
```py
record = self.env[mailing.mailing_model_real].search([], limit=1)
```
**Fix:**
Ensure the related messages are unlinked at the same time as the test mail in `send_mail_test` by setting `is_notification` to `False` to trigger the `unlink` logic.
```py
def unlink(self):
# cascade-delete the parent message for all mails that are not created for a notification
mail_msg_cascade_ids = [mail.mail_message_id.id for mail in self if not mail.is_notification]
res = super(MailMail, self).unlink()
if mail_msg_cascade_ids:
self.env['mail.message'].browse(mail_msg_cascade_ids).unlink()
return res
```
related: https://github.com/odoo/odoo/commit/21f92550f83cbd38df2c223c65c61bd16dc8e2b0
opw-5502787
Forward-Port-Of: odoo/odoo#247805This update resolves an issue where payment status information wasn't being displayed correctly. The fix replaces a problematic data field with a more reliable identifier, ensuring accurate payment status updates are consistently retrieved. This improves the reliability of payment tracking within the system.
Original PR description
Currently `this.props.record.data.id` returns `undefined` which results in an empty results dict and thus None value on the status. To fix this we switch from using the `data.id` to `resId` No Task ID
This update resolves an issue where the PIS status for batch payments wasn't updating correctly after refreshing. The fix ensures the correct database ID is used when fetching the status, guaranteeing accurate updates for SEPA credit transfers and similar payments. This improves the reliability of payment status reporting.
Original PR description
When clicking the refresh button next to the PIS status field on a batch payment (e.g., paid with SEPA credit transfer), the status is cleared and no new value is set. This occurs because `onClickFetchStatus` makes an ORM call to fetch the status using `this.props.record.data.id`, which is `undefined`. This commit fixes the issue by correctly using `this.props.record.resId` to pass the database ID to the RPC call. no task-id
This update resolves an issue where the stock valuation report was displaying inaccurate unit costs due to floating-point precision problems. The fix ensures more reliable calculations by addressing potential rounding errors, preventing inflated or negative values. This improves the accuracy of inventory reporting.
Original PR description
Problem: In the `stock.avco.report`, there is a chance for floating point inaccuracies to cause avco unit cost to inflate. This occurs specifically when the remaining quantity is calculated to be a…
Problem: In the `stock.avco.report`, there is a chance for floating point inaccuracies to cause avco unit cost to inflate. This occurs specifically when the remaining quantity is calculated to be a positive number extremely close to 0. There are also issues with negative avco value that are tangential to this error. Solution: We will mirror the iterative logic from `_run_avco`, being sure to account for whether we have moved from negative quantity to positive or vice versa. Also, before calculating avco value as `total_value / total_quantity`, we will ensure `total_quantity` is not a floating point number very close to 0 to avoid unit cost inflation. Steps to replicate (Runbot 19): Have storage locations enabled to make this easier to test 1. Product with tracked inventory, avco perpetual valuation, non-zero cost 2. Set the on hand quantity to -0.3 Units 3. Set the on hand quantity to -0.2 Units 4. Set the on hand quantity to 0 Units (A well-known python quirk, that .1 + .2 = 0.30000000000000004) Go to the stock report and inspect the unit cost history for the product, note 1. The nonsense Unit Cost on the top row 2. The negative Unit Cost on the 2nd row Note to reviewer: I discussed this issue briefly with dafr, who pointed out that there are further adjustments to come with the `_run_avco` method, and several other issues with this report that are not addressed by this PR. However, the problems with this report are affecting a customer so we'd like to push these fixes forward for now. opw-5430300 Forward-Port-Of: odoo/odoo#245141
This update introduces a new 'Net Cost' salary rule in the UAE payroll module to accurately reflect employer costs. Previously, certain rules incorrectly reduced both employee and employer costs. This change ensures that employer contributions are calculated correctly, providing a more precise view of business expenses.
Original PR description
## Before: - Setting appears_on_employee_cost_dashboard to True on a salary rule uses the rule’s sign to compute employee cost. - For rules like Social Insurance Employee Contribution and DEWS Employee Contribution, the sign must be negative to deduct the amount from the employee, which incorrectly reduces the employer cost as well. ## After: - Introduced a new salary rule “Net Cost” to correctly reflect employer cost. - This allows employee contribution rules to keep a negative sign for deductions while still increasing the employer contribution amount. Task-5912761
This update fixes a technical issue that was disrupting automated payment flows within Odoo. The previous version was encountering errors due to uncertain data, which is now simply removed. This ensures payments can process smoothly and reliably.
Original PR description
The last iteration[^1] was preventing automated flows from running smoothly because it was raising an error. Instead, we now just remove the unsure data. [^1]: 1794fce234735ed174599891435d4e2accc1632 Forward-Port-Of: odoo/odoo#250941
This update fixes the XML templates used for Dutch tax reporting (SBR and ICP) to align with the latest 2026 version of the Dutch taxonomy. This ensures accurate reporting for our Dutch customers, complying with local tax regulations. The change is a technical update to maintain compliance.
Original PR description
Fix the xml SBR and SBR ICP file template for the 2026 version of dutch taxonomy Documentation: https://www.sbr-nl.nl/werken-met-sbr/taxonomie/documentatie-nederlandse-taxonomie task-5974129
This update resolves an issue related to how sick leave is tracked in Belgium. Previously, complex calculations caused problems with matching sick leave entries. The change moves the specific Belgium logic to a localized module, addressing a prior issue and ensuring accurate sick leave reporting.
Original PR description
In Belgium, when more than a month of consecutive sick time of is taken, every day over the month is of a different type of work entry (sick time of without pay). This means that work entries relative to the same leave have different work entry types which was causing problems when checking the matching of the types. To fix this, a previous PR (https://github.com/odoo/odoo/pull/237829) made it so that if the internal_leaves computation returned empty, every leave was considered. Because of this some problems in the HK localization arose so we go back to the original code and we move the BE specific changes to the BE localization module. To do this, we move the logic in a function which we will override inside that module (see related Enterprise PR). Task: 5472538 Enterprise PR: https://github.com/odoo/enterprise/pull/105776
This update corrects a bug in the Belgian payroll system related to calculating sick leave. When employees take extended periods of sick leave, the system incorrectly identified different work entry types, leading to inaccurate payroll processing. This fix ensures accurate tracking of sick leave durations and avoids potential payment discrepancies.
Original PR description
In Belgium, when more than a month of consecutive sick time of is taken, every day over the month is of a different type of work entry (sick time of without pay). This means that work entries relative to the same leave have different work entry types which was causing problems when checking the matching of the types. To fix this, a previous PR (https://github.com/odoo/odoo/pull/237829) made it so that if the internal_leaves computation returned empty, every leave was considered. Because of this some problems in the HK localization arose so we go back to the original code (see related Community PR) and we move the BE specific changes to the BE localization module. Here we override the check function to allow for the specific case described above, where LEAVE110 is the code for sick time off and LEAVE214 is the code for sick time of without pay. Task: 5472538 Community PR: https://github.com/odoo/odoo/pull/246116
6 changes
Resolved issues and error corrections
This update ensures that check printing in the Philippines accurately reflects the net payment amount after withholding taxes. Previously, the check amount didn't correctly account for these deductions. A new test case has been added to verify this updated behavior.
Original PR description
In Philippines' check localization module, the amount on check should be based on the net amount after deducing withholding amount for payments if the payment is with taxes that are set as withholding on payment. This commit fixes the check print's values to reflect the net amount. Minimal test case is also added to safeguard the new behavior. [Task-5928813](https://www.odoo.com/odoo/all-tasks/5928813) Forward-Port-Of: odoo/enterprise#108611
This update fixes an issue where SII invoices weren't correctly formatted, preventing successful submission. The change updates XML tags related to withholdings in the DTE template to align with SII's specifications. This ensures invoices are properly processed and accepted by the SII system.
Original PR description
Link to SII API Documentation: https://www.sii.cl/factura_electronica/formato_dte.pdf Problem: The DTE template was using incorrect XML elements for withholdings when confirming an invoice with SII. This fix replaces: ImptRetOtrMnda -> ImpRetOtrMnda ValorImpOtrMnda -> VlrImpOtrMnda so the generated DTE matches SII specifications. OPW-5437484 Forward-Port-Of: odoo/enterprise#105152
This update corrects a bug where the 'Publish & Send' button was hidden in the 'Schedule by Resource' view. The previous fix incorrectly added a context variable, leading to this issue. This change removes the problematic condition, restoring the button's visibility and functionality.
Original PR description
## Issue Since commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2, `planning_test_tour_no_email` is failing when trying to click on the (missing) `Publish & Send` button. ## Cause The…
## Issue
Since commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2, `planning_test_tour_no_email` is failing when trying to click on the (missing) `Publish & Send` button.
## Cause
The commits adds the `my_planning_action` attribute to the context when opening the `Schedule by Resource`. This allowed to display the `I Take It!` button when opening an open shift, but it also removed the `Publish & Send` button, as its condition to be invisible consistently contains `context.get('my_planning_action')` [[1](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L11), [2](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L78-L79), [3](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L273-L274)].
## Fix
The objective is to fix the bug from previous commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2 differently. Instead of adding the `my_planning_action` to the context, we remove the conditions on the `I Take It!` button.
runbot-241028
Forward-Port-Of: odoo/enterprise#108333This update resolves an issue where the 'Request Signature' option wasn't consistently appearing in the cog menu on certain forms (like Timesheets and Projects). The fix ensures the menu item only displays when a chatter is present, improving the user experience and preventing confusion.
Original PR description
****Behavior:**** **Current:** When selecting the cog menu on certain forms, the request signature item doesn't always show even though it should. The expected behavior of this menu item is to appear only on form views with a chatter, but the way the chatter's presence was verified is inconsistent. **Solution:** On form views with a chatter, we can check its presence directly from the viewArch using the selector from the compiler registry. **Steps to reproduce:** From Timesheets: - Go to Timesheets - Open a task - The cog menu will not contain "Request Signature" From Project: - Go to Project - Select a project and open a task - The cog menu will contain "Request Signature" opw-4817423 Forward-Port-Of: odoo/enterprise#107299 Forward-Port-Of: odoo/enterprise#97401
This update fixes an issue where the VAT Book download was only generating for the primary company. Now, when multiple branches with the same CUIT are selected, the VAT Book will include data for all related branches, ensuring accurate reporting for multi-branch businesses in Argentina. This improves the reliability of tax reporting.
Original PR description
#### Issues: VAT Book should download for all selected companies with same CUIT as the current one. #### Step to reproduce: - In a company in Argentina ("Parent Company") - Create a branch "Child…
#### Issues:
VAT Book should download for all selected companies with same CUIT as the current one.
#### Step to reproduce:
- In a company in Argentina ("Parent Company")
- Create a branch "Child Company A" with no CUID
- Create a branch "Child Company B" with a different CUID than parent
- Go to "Child Company A"
- Either:
- i. Select both "Parent Company" and "Child Company A" but not "Child Company B"
- ii. Select all 3 "Parent Company", "Child Company A" and "Child Company B"
- In Accounting > Report > Tax Return :
- Download the VAT Book (wheel > "VAT book(ZIP)")
#### Current behavior:
i. Get Invalid Operation
ii. Download the VAT Book for "Parent Company" only
#### Expected behavior:
- Download the VAT Book for both "Parent Company" and "Child Company A"
A previous call to get_options provide the client with the info about which selected companies have the same CUIT as the current company. Therefore companies in the options are the correct ones.
opw-5385585
Forward-Port-Of: odoo/enterprise#101898A recent bug in web studio prevented users from correctly saving approval domain rules, specifically when using the 'not set' operator. This issue stemmed from how the system was converting domain data between Python and JavaScript. The fix ensures that domain data is properly formatted for use in the web studio interface, resolving this limitation.
Original PR description
Steps to reproduce ================== - Install web_studio,sale_management - Open a form view in sale - Open studio - Click on the "Send by email" button - Add an approval rule - Add a domain by clicking on the filter icon - Use the not set operator - Confirm - Click on the filter icon again - Confirm => ValueError: malformed node or string on line 1: <ast.Name object at 0x79ff4c7b7f50> Cause of the issue ================== JSON.stringify was used to pass the domain as a string to the DomainSelectorDialog. This doesn't work for boolean as they don't have the same representation in JavaScript as opposed to Python. Solution ======== Use the Domain().toString function opw-5923585 Forward-Port-Of: odoo/enterprise#108350 Forward-Port-Of: odoo/enterprise#107432
5 changes
Resolved issues and error corrections
This update fixes a minor issue where errors related to asset loading after a tour ended were being incorrectly flagged. The change ensures that these 'failed to fetch' errors are now handled more effectively, preventing unnecessary notifications and improving the overall user experience. This is a routine maintenance update.
Original PR description
Similarly to commit https://github.com/odoo/odoo/commit/493bab4f460dd4069d5cb6805933b8088067ff17 hiding "failed to fetch" errors, this commit adds AssetsLoadingError as those represents "just" another category of failed assets request (i.e. lazy loaded) after tour termination. runbot-233826 Forward-Port-Of: odoo/odoo#248003
This update fixes an issue where VAT calculations were incorrectly set to zero when generating XML reports from manual journal entries. The fix removed a faulty condition in the SQL query, ensuring accurate VAT amounts (MHT, TVA, TTC) are now correctly included in the exported XML files. This ensures accurate reporting for tax compliance.
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 resolves an issue preventing child companies from utilizing the parent company's SDI proxy user. The fix ensures child companies can correctly send invoices by allowing them to leverage the existing parent proxy, addressing a previous software update oversight. This improves functionality for clients using the account_edi_proxy_client feature.
Original PR description
This fix implements the same change made in PR #209120 to allow a child company to use the parent proxy user. It seems the record rules modification was missed during the FW, causing issues for clients using this feature in 18.2+ Steps to reproduce: - Create company A and a child company B sharing the same fiscal and VAT information - Register company A in the SDI (creating a proxy user) - Go to company B and try to send an invoice. You will get an error because Odoo will try to create a new proxy user as the parent proxy is currently inaccessible due to record rule constraints. Ticket [link](https://www.odoo.com/odoo/project.task/5927104) opw-5927104 Forward-Port-Of: odoo/odoo#249821
This update fixes a rounding discrepancy in early payment discounts, particularly when 'Always (upon invoice)' cash discount tax reduction is used. Previously, discounts were calculated line-by-line, leading to minor discrepancies. This change ensures discounts are rounded globally for accurate calculations, improving financial reporting.
Original PR description
**PROBLEM** There is a rounding issue with early payment discount when cash discount tax reduction is set to always (upon invoice). The move.line created for the discount is computed by applying the discount to each line, rounding each line individually. But the early payment discount is computed by rounding globally. **STEP TO REPRODUCE** 1. Create a payment term, with early discount of 1%, and cash discount tax reduction set to 'Always (upon invoice)'. 2. Create an invoice with 4 identical lines, unit price 4.76€ and tax 15%. 3. set the payment term on the invoice and save. 4. Go to journal item, early payment discount is 0.20€. 5. toggle discount_amount column on the the journal item tab. 6. notice on the last line, that balance - discount_amount = 0.19€ instead of 0.20€ opw-5865308 Forward-Port-Of: odoo/odoo#247996
This update fixes an error where certain Intrastat codes (99450000, 99500000, 99600000, and 99700000) were incorrectly marked as expired. The change ensures these codes remain active, aligning with official Belgian regulations as outlined in the Intrastat manual. This corrects a potential reporting issue.
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
6 changes
Resolved issues and error corrections
This update resolves an issue where certain Intrastat codes (99450000, 99500000, 99600000, and 99700000) were incorrectly marked as expired. The fix ensures these codes remain active, aligning with official Belgian regulations as outlined in the Intrastat manual. This correction is crucial for accurate reporting of international trade data.
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 an issue where VAT amounts were incorrectly displayed as zero in XML exports for manual journal entries. The fix removed a filtering condition in the SQL query that was excluding standard journal entry lines, leading to inaccurate VAT calculations. This ensures accurate VAT reporting for manual entries in the MA Company.
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 fixes an issue where manually invoiced subscriptions and upsells didn't correctly reflect their 'Fully Invoiced' status. The change ensures that invoices are accurately marked as 'Fully Invoiced' after manual invoicing, resolving a discrepancy in the system's tracking of subscription payments.
Original PR description
## Issue When manually invoicing a subscription or an upsell, its *Invoice Status* would not be updated to *Fully Invoiced* (`invoiced`), and would stay as *To invoice* (`to invoice`) instead. ##…
## Issue
When manually invoicing a subscription or an upsell, its *Invoice Status* would not be updated to *Fully Invoiced* (`invoiced`), and would stay as *To invoice* (`to invoice`) instead.
## Steps to reproduce
1. Install *Subscriptions* (`sale_subscription`)
2. Create a Product P
- *Subscriptions* checked
- *Invoicing Policy*: *Delivered quantities*
3. Create a Subscription S
- Any Customer
- Any plan
- Product P (any quantity)
4. Confirm the subscription S, set the amount delivered to the quantity ordered, then create and confirm the invoice
5. On the subscription S, click *Upsell*, add the product P to the upsell, and repeat step 4 on the upsell
6. **The upsell's _Invoice Status_ is still _To Invoice_, even though we invoiced it in the previous step**
## Causes
In the `SaleOrderLine._compute_invoice_status`, the following condition skips line from orders that are not considered to be "subscriptions":
https://github.com/odoo/enterprise/blob/c33e668bbba37c34d18af8c5371ab80eedf1b965/sale_subscription/models/sale_order_line.py#L51-L62
This is the case of upsells, as explained here:
https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201
---
Updating the above condition to take upsells in account is not enough. The condition to set the `invoice_status` to `invoiced` does not work as expected either.
https://github.com/odoo/enterprise/blob/5f4bb0ca22d068247540a4dcae88905c7b312f3c/sale_subscription/models/sale_order_line.py#L77-L78
In fact, when invoicing the subscription/upsell manually, there are multiple cases where the `last_invoiced_date` will be after `today`, and the subscription will be invoiced, so its status should be `invoiced`.
| Upsell | Invoiced based on delivered quantities | last_invoiced_date |
|--------|----------------------------------------|-------------------------|
| True | True | today + 1 month |
| False | True | today |
| True | False | today + 1 month - 1 day |
| False | False | today + 1 month - 1 day |
An alternative logic is to consider the subscription to be invoiced as long as the `next_invoice_date` is not reached.
---
opw-5500585
Forward-Port-Of: odoo/enterprise#107967This update fixes an issue where SII invoices weren't correctly formatted, preventing successful submission. The change updates XML tags related to withholding taxes to align with SII's specific requirements, ensuring invoices are accepted by the SII system. This ensures compliance with Chilean tax regulations.
Original PR description
Link to SII API Documentation: https://www.sii.cl/factura_electronica/formato_dte.pdf Problem: The DTE template was using incorrect XML elements for withholdings when confirming an invoice with SII. This fix replaces: ImptRetOtrMnda -> ImpRetOtrMnda ValorImpOtrMnda -> VlrImpOtrMnda so the generated DTE matches SII specifications. OPW-5437484 Forward-Port-Of: odoo/enterprise#105152
This update resolves an issue where a 100% discount on German Point of Sale (POS) certified transactions would cause an error. The change ensures the system handles this scenario correctly, preventing disruptions to the sales process. This improves the reliability of the German POS certification feature.
Original PR description
Backport of https://github.com/odoo/enterprise/pull/98869 opw-5240429 Forward-Port-Of: odoo/enterprise#108561
A recent test in the payroll system was failing when the 'Attendance' module wasn't installed. This update moved the test to a separate module to ensure it always runs correctly, preventing disruptions and maintaining consistent payroll processing. This fix improves the reliability of our payroll calculations.
Original PR description
Purpose: `test_05_fully_flexible_contracts_payslip` was failing without attendance installed as it creates contracts with `'work_entry_source': 'attendance'` Fix: moved the test to `hr_payroll_attendance` to ensure that it always runs with attendance installed pr introducing the test: https://github.com/odoo/enterprise/pull/93935 task-id: 5902805 Forward-Port-Of: odoo/enterprise#106320
15 changes
Resolved issues and error corrections
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#1055114 changes
Resolved issues and error corrections
This update fixes a technical issue where certain Intrastat codes (99450000, 99500000, 99600000 & 99700000) were incorrectly marked as expired. The update ensures these codes remain active, aligning with official Belgian regulations outlined in the Intrastat manual. This ensures accurate reporting for international trade data.
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 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 fixes a build error in the Odoo Enterprise payroll module related to warning data. The previous test incorrectly counted employees, failing when multiple employees triggered the same warning. The fix now accurately checks for the number of times an employee's ID appears in the warning data, ensuring correct build stability.
Original PR description
> To be FW'ed till `saas~19.1` only. issue: - the test written in commit 0653104 checks the employees' count in warning from `warning_data` dictionary - which will not work in case of multiple employees fulfilling that warning as the warning searches models' data, instead of just test data. fix: - instead of relying on `warning_data['count']` for invalid employee, checked how many times does the invalid employee's ID appear in the `warning_data`. runbot-240910 task-5958862
This update prevents incorrect data from being written to applicant records when OCR processes CVs. Specifically, it stops the OCR email address from overwriting existing business or user contacts, which could have led to inaccurate applicant information. This ensures data integrity within the recruitment process.
Original PR description
When OCR processes a CV, it writes extracted name/email/phone onto the applicant, which then propagates to the linked res.partner via the email_from inverse. This causes data corruption in two cases: - The CV was forwarded: the OCR email belongs to the candidate but email_from is the forwarder's address. Writing OCR data would overwrite the forwarder's partner with the candidate's details. - The existing partner is a company contact (parent_id set) or is linked to a user account (user_ids set). Writing OCR data would overwrite user/business partner with the candidate's details. Both guards are applied and added tests that check the flows. task-5949635
14 changes
Resolved issues and error corrections
This update corrects a visual issue in the planning app and related modules where employees with flexible calendars incorrectly displayed unavailable days. The fix ensures that flexible resources are shown as available unless public holidays or leaves are present, improving accuracy and usability. This resolves a discrepancy in how Odoo interprets work schedules.
Original PR description
### Issue: When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible…
### Issue:
When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible calendar should not have any grayed out days other than public holidays.
### Steps to reproduce:
- Create a new work schedule:
- Flexible Hours
- 24 hours per week
- 8 average hours per day
- Create an employee with this work schedule
- Open Planning app
- Only the three first days of the week are not grayed out
### Cause:
With 24 hours per week, the worked time can be done in three days. Odoo considers that the first three days of the given time frame are worked, but the others aren't. This result is returned by `_work_intervals_batch()`. In `_unavailable_intervals_batch()` we then build the unavailabilities by taking the inverse of the work intervals. The only exception was for fully flexible resources (i.e. without a calendar).
### Solution:
The case we need to consider is for flexible resources: they are available anytime, all week long except on public holidays and leaves.
To do this we fix the method `_unavailable_intervals_batch()` which is then called by each module. If the resource is flexible, then we only return the interval of the public holidays overlapping with the time frame.
Works in `appointment`, `hr_holiday_gantt`and `project_enterprise`.
In `planning`, we need to skip the case where nothing is returned in `leaves_mapping` otherwise it will consider the `company_leaves` during weeks with no public holiday or leaves.
In `hr_attendances_gantt`, `_unavailable_intervals_batch()` is not called. So we change the way the unavailabilities were computed to call `_unavailable_intervals_batch()` instead.
opw-4879481This update fixes an issue where flexible calendar employees were incorrectly displaying unavailable days in planning and related modules. The change ensures that only public holidays are reflected as unavailable, providing a more accurate representation of employee availability. This improves the usability of the planning app for employees with flexible work schedules.
Original PR description
### Issue: When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible…
### Issue:
When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible calendar should not have any grayed out days other than public holidays.
### Steps to reproduce:
- Create a new work schedule:
- Flexible Hours
- 24 hours per week
- 8 average hours per day
- Create an employee with this work schedule
- Open Planning app
- Only the three first days of the week are not grayed out
### Cause:
With 24 hours per week, the worked time can be done in three days. Odoo considers that the first three days of the given time frame are worked, but the others aren't. This result is returned by `_work_intervals_batch()`. In `_unavailable_intervals_batch()` we then build the unavailabilities by taking the inverse of the work intervals. The only exception was for fully flexible resources (i.e. without a calendar).
### Solution:
The case we need to consider is for flexible resources: they are available anytime, all week long except on public holidays and leaves.
To do this we fix the method `_unavailable_intervals_batch()` which is then called by each module. If the resource is flexible, then we only return the interval of the public holidays overlapping with the time frame.
Works in `appointment`, `hr_holiday_gantt`and `project_enterprise`.
In `planning`, we need to skip the case where nothing is returned in `leaves_mapping` otherwise it will consider the `company_leaves` during weeks with no public holiday or leaves.
In `hr_attendances_gantt`, `_unavailable_intervals_batch()` is not called. So we change the way the unavailabilities were computed to call `_unavailable_intervals_batch()` instead.This update resolves a potential issue in the live chat service by switching from a complex Promise-based system to a simpler, more reliable Deferred approach. This change enhances the overall stability and performance of live chat interactions for users. It’s a routine maintenance update focused on best practices.
Original PR description
In [1], the live chat service uses `Promise.resolvers` to avoid duplicated chat creation. However, there is no polyfill in this version. It's better to stick to the `Deferred` class. [1]: https://github.com/odoo/odoo/pull/250374 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the reliability of self-order transactions within Odoo Point of Sale. By aligning the data validation rules with standard POS orders, the system now catches more errors and ensures data accuracy for self-order processes. This improves the overall customer experience and reduces potential issues during transactions.
Original PR description
*: pos_online_payment_self_order, pos_restaurant, pos_self_order This commit improves the data validation of pos self order by using the same validation as the one used for regular pos order.
This update fixes a validation issue in the self-order point of sale module by aligning its data checks with the standard point of sale system. This ensures greater data accuracy and reliability for self-order transactions, reducing potential errors and improving the overall customer experience.
Original PR description
This commit improves the data validation of pos self order by using the same validation as the one used for regular pos order.
This update fixes a bug where employees with future attendance records couldn't check out. The fix ensures that only past attendance records are considered when determining the employee's status, preventing incorrect 'checked-out' states. This improves the kiosk experience and prevents workflow disruptions.
Original PR description
### Issue: When having an attendance in the future, the employee cannot checkout anymore. ### Steps to reproduce: - In Attendances, create an attendance in the future for an employee - Go in the kiosk mode - Manually select the employee to check in - Do the same to check out - An error pops up ### Cause: The field `last_attendance_id` of the employee contains his future attendance. The field `attendance_state` use `last_attendance_id` in its computation, so it's always "checked_out", even if an attendance is curently open for the employee. So when trying to check out an exception is raised in [`_check_validity()`](https://github.com/odoo/odoo/blob/fee6b32a8a57577bd8229c80dff6f93964f9f556/addons/hr_attendance/models/hr_attendance.py#L224-L234). ### Solution: Add a condition in the domain of `_compute_last_attendance_id()` to only consider the last **past** attendance. opw-5491867
This update fixes a confusing error message users received when generating leads without sufficient credits. Instead of a generic message, the system now correctly indicates when credits are unavailable, providing a clearer experience for users. This ensures a smoother process for lead generation activities.
Original PR description
Before this commit, when the user uses CRM to generate new leads and does not have credits, the error message they would get is "Your request did not return any result (no credits were used). Try removing some filters." This commit fixes this in _perform_request by instead of expecting InsufficientCreditError raised it now expects the credit_error flag to be set. task-5925047 Forward-Port-Of: odoo/odoo#250433
This update corrects a technical issue in the Spanish reporting module (l10n_es_reports) where an unnecessary date scope was added. This removal ensures accurate report generation and aligns with standard reporting practices. The fix was implemented as a bug fix to maintain data integrity.
Original PR description
In the Forward Port of this PR: https://github.com/odoo/enterprise/pull/108575 A date_scope was wrongly added opw-5363664
This update resolves an issue where users wouldn't receive a helpful error message when attempting to process after departure payments. Now, the system displays a clear validation error if a previous payslip isn't linked, ensuring accurate payroll processing and preventing potential data discrepancies.
Original PR description
For after departure payment to work, a previous payslip is required in the system. So, instead of having a traceback, display an informative message to the user. task-5933607
This update corrects an issue with how VAT tax schemes are calculated for Romanian customers. Previously, an empty company registry caused calculation failures. The fix re-introduces specific logic for Romanian CIUSRO invoices, ensuring accurate VAT scheme determination based on the default VAT setting.
Original PR description
Problem --------- If the customer has not VAT set up on it record, we use the DEFAULT_VAT value. However, the scheme to be used is computed using the partner company_registry (which might be empty), which fails. Secondly, the piece of logic that compute the VAT/NON_EU_VAT for the Tax Scheme node was removed during the refactor. However, this is needed in Romania. Solution --------- Compute the scheme using the DEFAULT_VAT and add back the VAT/NON_EU_VAT logic for the Romanian CIUSRO only. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where Avatax taxes weren't being correctly calculated during Stripe Express Checkout, particularly when using Google Pay. The fix ensures that all applicable taxes, including those from Avatax, are accurately reflected in the order total, improving payment accuracy and financial reporting. This impacts sales transactions utilizing the Stripe payment gateway.
Original PR description
## Versions 17.0+ ## Issue Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes. ## Steps to reproduce…
## Versions
17.0+
## Issue
Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes.
## Steps to reproduce
*Ensure the Stripe account has activated Google Pay* *This requires a complete Google profile on Google Chrome (with a valid payment method)*
- Setup Stripe payment method in test mode with Express Checkout;
- In the Settings, in the Accounting section:
- Setup Avatax;
- Set main Sales/Purchase taxes to 0.
- Create a new product with 0% selling taxes and any Avatax category;
- Activate fiscal position and enable automatic detection;
- Open a Chrome session with the Google profile:
- Go to the shop;
- Add the product you created to the cart;
- Enter the cart;
- Click the "Buy with GPay" button:
- The amount is equal to the sales price excluding taxes.
- Go to the Sales app and open the newly created order:
- The total amount differs from the amount paid (cf. transaction).
opw-5020793
Forward-Port-Of: odoo/enterprise#101579This update resolves an issue where users were encountering errors when processing after-departure payments. Now, the system clearly displays a validation error if a previous payslip isn't linked, guiding users to correctly complete the payment process. This improves user experience and data accuracy.
Original PR description
For after departure payment to work, a previous payslip is required in the system. So, instead of having a traceback, display an informative message to the user. task-5933607 Forward-Port-Of: odoo/enterprise#107801
This update fixes a technical issue that was disrupting automated payment flows within Odoo. The previous version was encountering errors due to uncertain data, which has now been resolved by simply removing the problematic information. This ensures smoother and more reliable processing of incoming payments.
Original PR description
The last iteration[^1] was preventing automated flows from running smoothly because it was raising an error. Instead, we now just remove the unsure data. [^1]: 1794fce234735ed174599891435d4e2accc1632 Forward-Port-Of: odoo/odoo#250941
This update fixes an issue where the calculation of 'sandwich leave' (leave periods surrounding holidays) was incorrect. Specifically, when leave was approved and then modified, the surrounding leave days weren't properly recomputed, leading to an inaccurate leave count. This change ensures that leave durations are calculated correctly, aligning with the intended business rules.
Original PR description
## Steps to reproduce:- 1. Apply Friday to Monday leave and Tuesday is Public holiday and again apply single leave on Wednesday. - According to the sandwich leave rule, the leave should be counted as 6 days (Friday to Wednesday, including weekend and holiday). 2. Now refuse the Friday to Monday leave and re-approve again. 3. Now the leave count is updated to 5 days as it should be 6 days! ## Root cause:- On approve and reset actions the neighbor leaves where not recomputed. ## Fix:- - Override `_l10n_in_update_neighbors_duration_after_change` on approve and reset actions. - Updated `_l10n_in_update_neighbors_duration_after_change` so that current and neighbors both leaves are recomputed. task-[5446346](https://www.odoo.com/odoo/action-4043/5446346) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
6 changes
Resolved issues and error corrections
This update fixes a discrepancy in how the system maps CPV codes to billing documents for Romania (RO). Previously, the incorrect code 'CPV' was used, which is now corrected to 'STI' according to PEPPOL standards. This ensures accurate billing and compliance with Romanian tax regulations.
Original PR description
The value of `ItemClassificationCode/listID` that corresponds to `CPV` classification is `STI` not `CPV`. See https://docs.peppol.eu/poacc/billing/3.0/codelist/UNCL7143/ task-5416833
This update resolves a 500 error that occurred when users attempted to edit their information in the portal with a company lacking a country setting. The fix ensures the system correctly handles missing country data, preventing the error and allowing users to save their information. This improves the overall portal experience for all users.
Original PR description
How to reproduce:
- Create a company with no country
- Set a contact's company to that company
- Grant portal access to that contact
- Login as that contact
- Go to the edit information tab
- Leave some of the required fields (Phone, Street & City) empty
- Click on save
The problem:
The page displays an error 500
Why:
When you try to submit the form with some required field missing, the page will try to evaluate this expression : 'int(country_id)''. But since this commit (https://github.com/odoo/odoo/commit/d6d6bee087fe2d3dc17974054353430c2662aecf), the post variable country_id is set to "False" if the partner has no country. 'int("False")' will then raise an error.
opw-5867975
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where the system would display an error message instead of a traceback when a previous payslip wasn't available for after-departure payments. Now, users will receive a clear, informative message guiding them to add a required reference payslip, ensuring accurate payroll processing.
Original PR description
For after departure payment to work, a previous payslip is required in the system. So, instead of having a traceback, display an informative message to the user. task-5933607
This update fixes a technical issue that was disrupting automated payment flows within Odoo. The previous version was encountering an error, which has now been resolved by simply removing problematic data. This ensures payments can process smoothly and reliably.
Original PR description
The last iteration[^1] was preventing automated flows from running smoothly because it was raising an error. Instead, we now just remove the unsure data. [^1]: 1794fce234735ed174599891435d4e2accc1632
This update corrects a technical issue that could cause inconsistencies between payroll lines and the overall payslip data. The change ensures that all payroll calculations and reporting remain accurate, preventing potential discrepancies and errors in employee payments. This improves the reliability of our payroll processing.
This update ensures Odoo's Dutch tax reporting (SBR and ICP) files are aligned with the latest 2026 version of the Dutch taxonomy. This is crucial for accurate tax reporting compliance in the Netherlands, avoiding potential errors and penalties.
Original PR description
Fix the xml SBR and SBR ICP file template for the 2026 version of dutch taxonomy Documentation: https://www.sbr-nl.nl/werken-met-sbr/taxonomie/documentatie-nederlandse-taxonomie task-5974129