Daily updates from Odoo
Wednesday, February 18, 2026
150 changes
1 change
Resolved issues and error corrections
This update addresses a recent finding that the Mexican SAT now accepts accented characters in tax documents. Previously, the system automatically removed accents to align with SAT practices. This change temporarily allows the ‘É’ character, and further investigation is underway to determine the full extent of accepted accents.
Original PR description
An improvement in September (PR #95207) began removing accents from names in documents sent to the SAT, in order to comply with their own practices. In recent months, it has become clear that the SAT…
An improvement in September (PR #95207) began removing accents from names in documents sent to the SAT, in order to comply with their own practices. In recent months, it has become clear that the SAT does accept accents sometimes. First with umlauts on the `ü` in October (PR #96043), then all umlauts in February (PR #106557). As this PR has found another accepted accented character `É`, it may be necessary to undo the original improvment entirely. The [Anexo 20 Guía de llenado de los comprobantes fiscales digitales por Internet](http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Anexo_20_Guia_de_llenado_CFDI.pdf), pg 17, indicates that accented characters are maintained in legal names. At least, `Í` is allowed. At this point in time I only added the exception for `É`. Steps to reproduce are [on the ticket](https://www.odoo.com/mail/message/999357619), as it requires a real person's tax information. [opw-5915515](https://www.odoo.com/odoo/project.task/5915515) ---- *Edit: Miguel (mial) confirmed that names are not always sanitized, but that we expect them to be.* Forward-Port-Of: odoo/enterprise#107677
1 change
Resolved issues and error corrections
This update addresses a recent discovery that the SAT (Mexican tax authority) sometimes accepts accented characters in invoices. Previously, the system automatically removed accents to comply with SAT rules. This change temporarily allows the ‘É’ character, and further investigation is underway to determine the optimal approach for full SAT compliance.
Original PR description
An improvement in September (PR #95207) began removing accents from names in documents sent to the SAT, in order to comply with their own practices. In recent months, it has become clear that the SAT…
An improvement in September (PR #95207) began removing accents from names in documents sent to the SAT, in order to comply with their own practices. In recent months, it has become clear that the SAT does accept accents sometimes. First with umlauts on the `ü` in October (PR #96043), then all umlauts in February (PR #106557). As this PR has found another accepted accented character `É`, it may be necessary to undo the original improvment entirely. The [Anexo 20 Guía de llenado de los comprobantes fiscales digitales por Internet](http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Anexo_20_Guia_de_llenado_CFDI.pdf), pg 17, indicates that accented characters are maintained in legal names. At least, `Í` is allowed. At this point in time I only added the exception for `É`. Steps to reproduce are [on the ticket](https://www.odoo.com/mail/message/999357619), as it requires a real person's tax information. [opw-5915515](https://www.odoo.com/odoo/project.task/5915515) Forward-Port-Of: odoo/enterprise#107677
3 changes
Resolved issues and error corrections
This update resolves a technical error that was preventing notifications from the signature field. The notification service was missing a declaration, causing a system error. This fix ensures that signature field notifications function correctly, improving the user experience for features relying on them.
Original PR description
The notification service is later used in this [method](https://github.com/odoo/odoo/blob/04f3473da52ec74f3955cadd58eb016537497d44/addons/web/static/src/views/fields/signature/signature_field.js#L120), but it was never declared so it was causing an error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248602
This update resolves an issue where the 'contract type' field was incorrectly displayed in the employee offer view when the Belgium payroll localization was not installed. The fix adds a new field to the model to control the visibility of this field, ensuring correct behavior across different localization setups. A subsequent fix will be required after version 19.0 to prevent the field from being added again.
Original PR description
Bug reproduction: Ensure that belgium payroll localization is not installed, go to offer of employee, contract type field is not there. Bug cause: Contract type field does not exist in the model, it was adding to the view by l10n_be_hr_payroll. Bug solution: I added new field contract_type_id to the hr_contract_salary_offer model (to show it on UI). Solved from 17.0 Note: I need to fix after version 19.0, because by starting from 19.0, the Belgium one will try to add the same field to the view again task - 5500488 Forward-Port-Of: odoo/enterprise#107687 Forward-Port-Of: odoo/enterprise#104578
This update corrects a critical issue where Belgian UBL invoices were missing a required scheme ID, preventing proper invoice generation. The fix ensures compliance with industry standards (ISO 6523 ICD) for company registry information, improving the accuracy and validity of invoices for Belgian customers. This resolves a previous error and enhances the system's ability to process invoices correctly.
Original PR description
1) This commit adds the new generic methods to build an UBL file. The big objective is to remove the hierarchy of UBL later on and make BIS3 completely standalone. In this commit, BIS3 is not independent of UBL 2.1 & 2.0. 2) Missing schemeID for Belgium Company registry Since https://github.com/odoo/odoo/commit/d40652c17b43b6a9fd4d19ce84b943b2a51fad9c, in Belgium, we set by default the company registry. However the schemeID is missing and should be part of the ISO 6523 ICD list: https://docs.peppol.eu/poacc/billing/3.0/codelist/ICD/ 3) Fix PartyLegalEntity when the country is NL and there is no company registry/EAS/Endpoint That case was raising a traceback before this commit. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246377
3 changes
Resolved issues and error corrections
This update reverses a recent change that was causing all upsell quotes to be canceled and disrupting legitimate business processes. The issue stemmed from a technical error in how quotes were handled, specifically related to alternative quotes and a faulty action call. This fix ensures upsell quotes function as intended.
Original PR description
…mmit/55b6bbe27cc31abcaee40cd4a196e087fdfd4ce5 This commit introduced an issue. All upsell quote were canceled and no filtering was done on "alternative quotes". As a result it could disrupt legit business flow. Moreover, action_cancel was called instead of _action_cancell which can lead to ValueError: Expected singleton as action_cancel can require single record sometimes. Forward-Port-Of: odoo/enterprise#107503 Forward-Port-Of: odoo/enterprise#107417
This update addresses a recent finding that the SAT now accepts accented characters in tax documents. Previously, the system removed accents to align with SAT practices. This PR temporarily allows the ‘É’ character, acknowledging ongoing SAT acceptance of accented names as outlined in official guidelines.
Original PR description
An improvement in September (PR #95207) began removing accents from names in documents sent to the SAT, in order to comply with their own practices. In recent months, it has become clear that the SAT…
An improvement in September (PR #95207) began removing accents from names in documents sent to the SAT, in order to comply with their own practices. In recent months, it has become clear that the SAT does accept accents sometimes. First with umlauts on the `ü` in October (PR #96043), then all umlauts in February (PR #106557). As this PR has found another accepted accented character `É`, it may be necessary to undo the original improvment entirely. The [Anexo 20 Guía de llenado de los comprobantes fiscales digitales por Internet](http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Anexo_20_Guia_de_llenado_CFDI.pdf), pg 17, indicates that accented characters are maintained in legal names. At least, `Í` is allowed. At this point in time I only added the exception for `É`. Steps to reproduce are [on the ticket](https://www.odoo.com/mail/message/999357619), as it requires a real person's tax information. [opw-5915515](https://www.odoo.com/odoo/project.task/5915515) Forward-Port-Of: odoo/enterprise#107677
This update optimizes the MPS report to run faster and use less memory, especially when dealing with a large number of production schedules. By reducing the amount of data fetched and processed, the report now completes significantly quicker and avoids memory errors, improving overall system responsiveness. This change addresses a performance bottleneck impacting report generation speed.
Original PR description
Problem: When running the MPS report on a large number of production schedules, if the associated number of stock moves is high, the _get_moves_and_date method can cause a memory error. Solution: We…
Problem:
When running the MPS report on a large number of production schedules, if the associated number of stock moves is high, the _get_moves_and_date method can cause a memory error.
Solution:
We will fetch only the necessary fields to reduce queries and memory usage and set prefetch_fields=False to further reduce memory usage.
Benchmarks:
Run locally on a dupe of customer's db.
Time/queries measured by requests to /get_mps_view_state Memory measured using memray on method get_production_schedule_view_state()
<table>
<tr>
<th rowspan="2"># of Production Schedules</th>
<th colspan="3">Before</th>
<th colspan="3">After</th>
</tr>
<tr>
<th>Time</th>
<th># of Queries</th>
<th>Memory usage</th>
<th>Time</th>
<th># of Queries</th>
<th>Memory usage</th>
</tr>
<tr>
<td>20</td>
<td>22.846s</td>
<td>1,379</td>
<td>882.0MB</td>
<td>8.046s</td>
<td>1,180</td>
<td>103.4MB</td>
</tr>
<tr>
<td>300</td>
<td>41.098s</td>
<td>6,297</td>
<td>1.0GB</td>
<td>43.694s</td>
<td>5,732</td>
<td>363.5MB</td>
</tr>
<tr>
<td>1000</td>
<td>N/A (MemoryError)</td>
<td>N/A (MemoryError)</td>
<td>>2GB</td>
<td>88.416s</td>
<td>22,629</td>
<td>1.1GB</td>
</tr>
</table>
Average memory usage reduction: 75%
opw-5225472
Forward-Port-Of: odoo/enterprise#10639224 changes
Resolved issues and error corrections
This update simplifies the process for creating expense accounts by removing automated data pre-filling for KYC verification. This change addresses potential errors caused by inconsistent data formats in certain regions, like the Netherlands, and ensures a more reliable and accurate manual verification process.
Original PR description
Context:
When creating a livemode account, the data pre-sent by the database to stripe may cause issues in some localizations. e.g. the Netherland where people are forced to use a zip in the "\d{4} ?[A-Z]{2}" pattern, which they do not alway do
Solution:
Pre-filling KYC was deemed too error-prone and this would be switched to a fully manual KYC
OPW-5899276
Linked (but not depending on) https://github.com/odoo/iap-apps/pull/1431
Forward-Port-Of: odoo/enterprise#107115This update corrects a bug that occurred when KPIs with the same label but different identifiers were being sorted. The fix ensures accurate sorting by using a more efficient method within the system's data processing, preventing errors and improving data reliability.
Original PR description
When two KPIs have different identifiers but the same label, the call to `sorted` on a list of (priority, label, dict) tuples was wrong. As the two first criteria were the same, the comparison was made on the dict, which is not comparable, leading to the following error:
TypeError: '<' not supported between instances of 'dict' and 'dict'
With this commit, we instead use the `key=` argument to `sorted` in order to build the `(priority, label)` tuples, which is cleaner.
OPW-[5932549](https://www.odoo.com/odoo/project.task/5932549)
Forward-Port-Of: odoo/enterprise#107481This update resolves a problem where changing a bank account in the salary settings would incorrectly add multiple accounts to an employee's profile, leading to incorrect payment allocations. The fix now completely replaces existing bank accounts with the new one, ensuring accurate and consistent salary payments.
Original PR description
When changing a bank account in the salary configurator, the system was adding the new bank account to the employee's existing bank accounts list, ending up having multiple bank accounts where the first retained 100% allocation and subsequent ones had 0% allocation. The fix replaces all existing bank accounts with only the new one. task-5905542 Forward-Port-Of: odoo/enterprise#106333
This update resolves an issue related to how version numbers are tracked within the Belgian HR Payroll module. The fix ensures accurate identification and management of module versions, preventing potential errors during updates and deployments. This improves the stability and reliability of the payroll processing functionality.
Original PR description
Forward-Port-Of: odoo/enterprise#107482
This update corrects a display issue where percentage fields in employee contracts were showing decimal values (e.g., 0.25%) instead of the intended percentage format (e.g., 25%). The underlying calculations remain accurate, and this change ensures a more user-friendly presentation of percentage data within the HR contract module.
Original PR description
Percentage fields are stored as a decimal in the DB (0.25) but represent a percent value (25%) The calculations are correct but the display to the user shows 0.25%, this PR fixes that without modifying the values stored on the database task-5350196 Forward-Port-Of: odoo/enterprise#106989
This update fixes a problem where the system was creating multiple, empty pay runs when generating payslips. The change ensures that only one temporary pay run is created during the selection dialog process, preventing unnecessary database clutter and improving system stability. This resolves a potential performance issue and ensures accurate payroll data.
Original PR description
When generating payslips from the selection dialog the UI previously created a new hr.payslip.run on every attempt; server-side validation can fail and each failed attempt left an empty pay run in the database. Fixed by allowing the dialog to create at most one temporary pay run per dialog lifecycle, reuses it on retries, and removes it if generation fails or the dialog is closed. task-5920710 Forward-Port-Of: odoo/enterprise#106857
This update fixes a payment error related to work accident entries on employee payslips. Previously, a new entry type wasn't correctly linked, leading to accidental payments. The fix adds the necessary entry type to the payroll structure, ensuring accurate payment processing for work accident compensation.
Original PR description
The unpaid work accident work entry type was added, but not included in `unpaid_work_entry_type_ids`, causing it to be paid by mistake. Add it to `unpaid_work_entry_type_ids` for the following structures: - structure_type_employee_cp200 - structure_type_employee_cp200_pfi Task: 5484866 Forward-Port-Of: odoo/enterprise#106435
This update resolves an issue where FedEx freight requests were failing due to missing information required by the FedEx API. Specifically, the system was unable to send a crucial detail – a 'bookingConfirmationNumber' – which is necessary for the API to validate shipments. This fix ensures that rate calculations for FedEx freight can be retrieved, but delivery validation remains functional.
Original PR description
Issue ----- Fedex freights services require extra information not present in the db, so requests will not be accepted by the API. A rate can be retrieved but the delivery cannot by validated by users as they get a `SHIPMENT.LOADCOUNT.INVALID` error. This is due to the lack of a `expressFreightDetail` entry in the request sent to the Fedex API. This `expressFreightDetail` field should contain some information which Odoo does not have a way to retrieve, such as a `bookingConfirmationNumber`. API details: https://developer.fedex.com/api/en-us/catalog/ship/v1/docs.html#:~:text=expressFreightDetail Feedback 5913471 ----- Ticket: opw-5876616 Forward-Port-Of: odoo/enterprise#106590
This update corrects a minor issue in the calculation of payroll fees and deductions, specifically related to union and professional association fees. The change ensures more accurate processing of these deductions, improving the reliability of payroll reporting for Australian businesses using the Enterprise module.
Original PR description
. Update `Union and professional association fees` code in computations of `Fees and Deductions` rule task-5402666 Forward-Port-Of: odoo/enterprise#104911
This update resolves an error that occurred when generating timesheet reports grouped by employee, specifically when filtering by billing time. The fix corrects a data structure issue preventing the report from correctly displaying hours worked by each employee. This ensures accurate timesheet reporting functionality.
Original PR description
## Short functional explanation of the error In Timesheets, when reporting by billing time, if we try to group by employee, an error occurs. ## Reproduction Steps 1. Go to Timesheets. 2. Click on the…
## Short functional explanation of the error
In Timesheets, when reporting by billing time, if we try to group by employee, an error occurs.
## Reproduction Steps
1. Go to Timesheets.
2. Click on the Reporting tab > By Billing type.
3. Click on the search bar and click on Employee under the Group By section.
### Expected behavior
A report shows the different hours worked on billing time for each employee.
### Unexpected behavior
An error occurs:
```TypeError: data.forEach is not a function```
## Origin of the issue
When retrieving the data to show in the report after having grouped
it by employee, this piece of code is called:
https://github.com/odoo/enterprise/blob/42102423069c2cebbc01eb4d1d8f9b6215358639/sale_timesheet_enterprise/static/src/views/timesheet_analysis_pivot/timesheet_analysis_pivot_model.js#L23-L36
However, the variable (data) on which we perform the forEach isn't
an array: it's an object of structure:
```
{ "group": { "rowValues": [], "colValues": [] }, "rowGroupBy": [ "employee_id" ], "colGroupBy": [], "subGroupIndex": 2, "subGroups": [ { "employee_id": [ 1, "Administrator" ], "__extra_domain": [ [ "employee_id", "=", 1 ] ], "unit_amount:sum": 0, "__count": 2, "__domain": [ "&", [ "project_id", "!=", false ], [ "employee_id", "=", 1 ] ] } ] }
```
on which we can't perform a forEach. The data we want to access to
use in the report is actually the `subGroups` element of data.
__
opw-5864458
Forward-Port-Of: odoo/enterprise#106969This update resolves a technical issue that could have caused the payroll system to become stuck in an endless loop. The change ensures that data is fetched correctly, improving the stability and reliability of the HR payroll processing.
Original PR description
The new implementation uses a prefetch object that makes the union of prefetch ids. This commit fixes an infinite loop by imposing the prefetching with `records.with_prefetch()` Forward-Port-Of: odoo/enterprise#107480
This pull request addresses a critical issue (274XX) within the Belgian payroll module (l10n_be_hr_payroll). The fix corrects a problem impacting payroll calculations, ensuring accurate and compliant processing of employee wages. This update improves the reliability of the HR payroll functionality.
Original PR description
Forward-Port-Of: odoo/enterprise#107679
This update ensures that all rates displayed on printed payslips are formatted to a maximum of 4 decimal places. This improves the clarity and professionalism of the payslip document, aligning with standard reporting practices. The change was implemented to address a formatting issue.
Original PR description
This commit improves the payslip display by limiting all rates to 4 decimals max on the printed pdf payslip. Task: 5709739 Forward-Port-Of: odoo/enterprise#104915
This update resolves a bug preventing users from saving the CDI - Experienced Developer (BE) contract template. The change removes a default checkmark for an inventory car, which was causing a required field error. This ensures the template can be successfully saved and used.
Original PR description
Before this commit, when the CDI - Experienced Developer (BE) contract template is loaded, the inventory car is checked, but no car is selected, so you can't save. This commits unchecks the inventory car on the template to avoid this issue. Task: 5892344 Forward-Port-Of: odoo/enterprise#107584 Forward-Port-Of: odoo/enterprise#105992
This update corrects a data issue in the demo payroll system for Anita Oliver. Specifically, the first month's payslip data has been added, enabling the 'Time Off to Defer' functionality to work correctly. This ensures the demo data accurately reflects payroll processing.
Original PR description
Add first month's payslip in demo data for Anita Oliver, so that Time Off to Defer works correctly. task-5912512 Forward-Port-Of: odoo/enterprise#106685
This update resolves an issue where the header in the sign application was overlapping with a red color bar. The fix removed a styling tag that caused this overlap, ensuring the header is now displayed correctly and consistently. This improves the user experience for signing documents.
Original PR description
Remove `top` tag to prevent header overlap due to neutralize red color bar Before fix: <img width="1953" height="790" alt="image" src="https://github.com/user-attachments/assets/dd9f7a00-eaea-4304-a22d-d8df96203823" /> After fix: <img width="1892" height="639" alt="image" src="https://github.com/user-attachments/assets/247e6067-570a-4fcb-a0e9-6f2640940f21" /> opw-5900244 Forward-Port-Of: odoo/enterprise#106844
This update corrects a technical issue where the contract template was being unnecessarily created during salary configuration. This prevented certain calculations from running correctly. The fix ensures the template data is now correctly handled, resolving the problem and improving system performance.
Original PR description
Writing the contract template on the new version created by the salary configurator is not necessary and caused some computes to not trigger. The contract template values are already included in the `_get_version` method. task-5324222 Forward-Port-Of: odoo/enterprise#107582 Forward-Port-Of: odoo/enterprise#99781
This update resolves an issue where incoming calls were automatically rejected when Do Not Disturb (DND) mode was activated. The change restores the expected behavior, allowing calls to be accepted while still respecting DND by preventing the softphone from automatically opening or playing a ringtone. This ensures a smoother call experience for users.
Original PR description
Since https://github.com/odoo/enterprise/pull/104426, incoming calls were automatically rejected when Do Not Disturb (DND) mode was enabled. This commit restores the expected behavior: when DND is enabled, the incoming call is accepted and a session is created, but the softphone is not automatically opened (and no ringtone is played).
A recent update to the project timesheet forecasting module caused errors when accessing all timesheets. This fix addresses a technical issue where an outdated field reference was preventing proper grouping of timesheets by employee. The update ensures the timesheet functionality is stable and reliable.
Original PR description
Steps to reproduce: - install project_timesheet_forecast - open timesheets app - open all timesheets menu => error Source of the bug: - planning_slot has no more employee_id field, it was replaced by employee_ids - when trying to group planning slots by employee_id, the key "employee_id" doesn't exist. Fix: The group_expand based on planning when the section field in the grid view is employee_id. task-5945958
This update resolves an issue where the 'Mark as Paid' button was hidden for users in Mexico when the l10n_mx_hr_payroll_account module was installed. This change ensures the standard payment flow is clear and functional for Mexican users, improving their payroll processing experience.
Original PR description
The "Mark as Paid" (action_payslip_paid) button on the hr.payslip form view [is hidden](https://github.com/odoo/enterprise/blob/19.0/hr_payroll_account/views/hr_payslip_views.xml#L39) when the l10n_mx_hr_payroll_account module is installed, making the standard payment flow confusing for users in Mexico. target: 19.0 task-5434674 Forward-Port-Of: odoo/enterprise#104390
This update ensures that the SOL (Service of Logistics) is correctly displayed in the invoicing notebook for sales orders when the project is set to 'is_fsm' and the partner type is a delivery partner. Previously, this information was missing for delivery partners, leading to potential invoicing inaccuracies. This change improves the accuracy and completeness of invoices for delivery-based sales.
Original PR description
Before this commit: When the project `is_fsm`, the timesheet product is displayed in the invoicing notebook regardless of partner type. After this commit: When the project `is_fsm` and the partner is of type delivery, the SOL displays correctly in the invoicing notebook. task-4764834
This update removes automatic completion of document activities when an account move is created. Previously, activities were marked as done regardless of their purpose, which was causing confusion and potential errors. This change ensures activities are only marked complete when directly related to an account move action.
Original PR description
Purpose: Avoid closing document activities that may not be related to performing a document action. Specification: When an account move is created from a document, the current logic automatically marks all document activities as done. This behavior is removed because document activities can exist for purposes unrelated to the performed action, and should not be completed implicitly as a side effect of it. Task-5075307
This update strengthens the security of invoices by preventing the use of untrusted accounts when processing inbound invoices. The change addresses a vulnerability that could have allowed unauthorized access. Testing and related code updates were implemented to ensure proper functionality.
Original PR description
fixed some tests see odoo#247954 Forward-Port-Of: odoo/enterprise#106980
This update corrects a minor visual issue with the Gantt chart's side panel icon. The icon was previously displaying as if it should rotate, which was an unintended leftover setting. This change ensures the icon appears correctly, improving the overall user experience.
Original PR description
This commit removes the fa-flip-horizontal class from the gantt side panel icon which was mistakenly left as is in https://github.com/odoo/enterprise/pull/107520
3 changes
Resolved issues and error corrections
This update resolves a technical issue preventing users from removing the date filter on the Booking tab within the POS Kanban view. The fix involved adding a missing function to the button's click handler, ensuring the filter is now correctly removed. This improves the user experience when managing bookings.
Original PR description
Steps: - Install pos_appointment. - Open a POS session with bookings configured. - Open the Booking tab and click Remove date filter in the header. Issue: - A traceback occurs with `Invalid handler`. Cause: - The Remove date filter button’s onclick handler was not defined. Fix: - Define a valid onclick handler for the Remove date filter button. Task-5902656 Forward-Port-Of: odoo/enterprise#107579 Forward-Port-Of: odoo/enterprise#106684
This update addresses a technical adjustment to the ‘l10n_eu_iot_scale_cert’ module's checksum. The code for the scale driver was recently modified to resolve a bug, requiring a corresponding update to the checksum to ensure data integrity. This ensures continued accurate reporting and functionality.
Original PR description
Checksum needs to be updated as the code of the scale changed for a bugfix Cummunity PR: https://github.com/odoo/odoo/pull/249280
This update resolves an issue where the 'Mark as Paid' button was hidden in the payroll system for users in Mexico when the l10n_mx_hr_payroll_account module was installed. This change ensures that Mexican users can correctly process and mark payroll payments, streamlining the standard payment workflow.
Original PR description
The "Mark as Paid" (action_payslip_paid) button on the hr.payslip form view [is hidden](https://github.com/odoo/enterprise/blob/19.0/hr_payroll_account/views/hr_payslip_views.xml#L39) when the l10n_mx_hr_payroll_account module is installed, making the standard payment flow confusing for users in Mexico. target: 19.0 task-5434674
12 changes
Resolved issues and error corrections
This update fixes an error in how holiday pay recovery is calculated for employees with non-standard working schedules (e.g., 40 hours/week) in Belgium. Previously, the calculation used outdated standard hours, leading to incorrect deductions. Now, the system accurately uses the employee's actual weekly hours to ensure correct holiday pay recovery amounts.
Original PR description
**Steps to Reproduce:** 1 - create an employee in Belgium company with hourly rate 20.62 and 40h/week working schedule 2 - Set 10 paid time off to this employee 3 - Set 2000 euros in recovery amount…
**Steps to Reproduce:** 1 - create an employee in Belgium company with hourly rate 20.62 and 40h/week working schedule 2 - Set 10 paid time off to this employee 3 - Set 2000 euros in recovery amount holiday n-1 4 - Set 10 days in recovery day holiday n-1 5 - Employee takes 5 paid time off in February and 5 in December 6 - Do one payslip for this employee for February and validate it 7 - Do one payslip for this employee for December Current behaviour : - the holiday n-1 amount for February = 824.80 - the holiday n-1 amount for December = 742.32 Expected behaviour : - the holiday n-1 amount for December should be 20.62 (hourly_rate) * 5 (days) * 8 (hours) = 824.80 **Reason** - The daily recovery amount was calculated using hardcoded standard working hours (38h/week) instead of the employee's actual schedule (40h/week), causing an incorrect deduction rate for non-standard schedules. **Solution** - Replace the hardcoded reference with the actual hours per week from the employee's resource calendar to ensure the correct hourly rate is applied. Forward-Port-Of: odoo/enterprise#106205
This update resolves an issue where Peppol invoices were incorrectly using the wrong company context, leading to errors and inconsistencies when creating invoices. The fix ensures invoices are processed with the correct company details, preventing data mismatches and improving data accuracy for cross-company transactions.
Original PR description
Currently, the created move does not always use the company context of the related move/proxy user. As a result, default values may be taken from another company, which can lead to cross-company inconsistencies and access errors. Steps to reproduce: - Set up two companies, A and B - In company A, configure a default value for the partner.company_id field, applicable only to company A - When a Peppol invoice arrives for company B but is processed using the context of company A, and a new partner must be created, the partner is created with company A as the default value - This results in an incompatible companies on record error This fix ensures that the company context of the move or EDI user is used when creating the move, preventing cross-company issues. opw-5473233 Forward-Port-Of: odoo/odoo#249059
This update resolves an issue where Odoo couldn't connect to the database correctly when using the standard Odoo 18 setup. The fix ensures Odoo automatically uses the correct port for database connections, regardless of whether a replica database is configured. This improves overall stability and reduces potential connection problems.
Original PR description
Start postgres on an alternative port (e.g. 5434), start odoo with `--db_port 5434 --db_replica_host=''`, access /web/database/manager, there's a warning in the logs that says it is not possible to connect to the replica database.
The empty string for the replica host is Odoo 18 way to tell Odoo to simulate a replica database by connecting to the same db as the primary one. It should use `--db_replica_port` and when not set fallback on the same port as `--db_port`. The problem is that in case no `--db_replica_port` is set, the option is set `None` in the config, i.e. `get('db_replica_port', cfg)` was retuning `None` as was not using the fallback.
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-prThis update corrects a critical issue in the account_edi_ubl_cii module for Belgium, ensuring that the company registry is correctly identified within UBL invoices. This ensures compliance with industry standards and accurate invoice generation for Belgian businesses. The fix also addresses a related issue with PartyLegalEntity data for the Netherlands.
Original PR description
1) This commit adds the new generic methods to build an UBL file. The big objective is to remove the hierarchy of UBL later on and make BIS3 completely standalone. In this commit, BIS3 is not independent of UBL 2.1 & 2.0. 2) Missing schemeID for Belgium Company registry Since https://github.com/odoo/odoo/commit/d40652c17b43b6a9fd4d19ce84b943b2a51fad9c, in Belgium, we set by default the company registry. However the schemeID is missing and should be part of the ISO 6523 ICD list: https://docs.peppol.eu/poacc/billing/3.0/codelist/ICD/ 3) Fix PartyLegalEntity when the country is NL and there is no company registry/EAS/Endpoint That case was raising a traceback before this commit. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where order totals in Point of Sale weren't always rounded correctly before being saved to the database. This ensures accurate financial reporting and prevents discrepancies in order amounts. The change improves data integrity and reliability for sales transactions.
Original PR description
Before this commit, the total amount of an order could be not properly rounded in some cases, and would get stored in the database with more decimal places than allowed by the currency. opw-5919317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a synchronization issue that occurred when orders had both terminal and online payments. Previously, removing an online payment didn't properly remove the corresponding terminal payment from the system, leading to data inconsistencies. Now, only online payments are deleted, ensuring accurate order synchronization across the UI and server.
Original PR description
Before this commit, if an order had a terminal payment and an online payment was added accidentally, and then get removed, the terminal payment would get removed from server, while it won't be removed from the UI, resulting in a mismatch between the server and the UI, and the order would no be synced correctly. opw-5911699 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the 'Expenses Report' feature would fail when attached to encrypted PDF receipts. The fix skips these encrypted files and adds a note to the report explaining why the attachment was omitted. This ensures the report generation process continues smoothly.
Original PR description
**Steps to reproduce:** - Install hr_expense - Create an expense - Attach several receipts with at least one encrypted PDF - Create Report - From cog menu, print "Expenses Report" **Issue:** A traceback is raised while trying to add the attachments to the report: "File has not been decrypted". **Cause:** The encrypted file cannot be appended to the report PDF. **Solution:** Skip encrypted files and log a note with the reason in the report. opw-5194501 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248869
This update prevents tooltips from disappearing unexpectedly when a user navigates between a parent and child element within the Odoo interface. Previously, tooltips would be prematurely terminated, disrupting the user experience. Now, tooltips remain active as long as the user remains within the parent element's area.
Original PR description
Have a tooltip on a parent. Hover on a child of that parent. Now, leave the child but stay in parent. Before this commit, the tooltip would be killed and never respawn. After this commit, the tooltip is not even killed if we stayed within the parent's physical space. task-5346498 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 fixes an issue where OCR-extracted expense receipts were incorrectly converting foreign currencies to USD, forcing a 1:1 exchange rate. The fix ensures that the 'Total' amount is accurately displayed in the company's currency based on the system's exchange rates, improving the reliability of expense reporting.
Original PR description
Steps to reproduce: 1. Initialize an expense with a foreign currency (e.g., EUR). 2. Trigger OCR extraction on a receipt with a specific total. 3. Observe that both 'Total In Currency' and 'Total' (USD) are set to the same value. 4. The exchange rate is forced to 1.0, ignoring the system's exchange rate. Cause: The _fill_document_with_results method assigned the OCR total to both 'total_amount_currency' and 'total_amount' as a placeholder. This triggered the field's inverse logic during the write() call, causing Odoo to treat the input as a manual exchange rate override of 1:1. Solution: Remove the 1:1 placeholder assignment. The method now explicitly calculates 'total_amount' using the _convert() helper once the currency is identified, ensuring the company currency total reflects the actual system exchange rate. opw-5437611
This update corrects a bug where the 'CFDI to Public' checkbox was incorrectly checked when creating new invoices in the Mexican accounting module. The fix ensures this checkbox remains unchecked unless a customer is selected, preventing potential compliance issues. This change improves invoice creation processes for Mexican businesses.
Original PR description
Steps to produce: --- - Install `l10n_mx` and `accountant` modules. - Switch to a Mexican company. - Go to Accounting > Customers > Invoices. - Click on New to create a new invoice. Issue: --- - The `CFDI to Public` checkbox is automatically checked even when no customer is selected. Root cause: --- - Here at [1], the field l10n_mx_edi_partner_address_complete evaluates to False when no partner is set. - Due to the OR condition, this causes l10n_mx_edi_cfdi_to_public to be set to True, even though no partner has been selected yet. Solution: --- - We should only evaluate partner address completeness when a partner is explicitly set. - Also, add VAT check for `l10n_mx_edi_partner_address_complete`, as requested by mial(PO). [1] https://github.com/odoo/enterprise/blob/cc00e8f3bb75b8c782fea3a42ad3bbcdbc240e2f/l10n_mx_edi/models/account_move.py#L649 opw-5911542 ---
This update corrects a recent change that was causing all upsell quotes to be canceled, disrupting legitimate business processes. The fix resolves a technical error related to quote handling and prevents a potential ValueError, ensuring quotes are processed correctly.
Original PR description
…mmit/55b6bbe27cc31abcaee40cd4a196e087fdfd4ce5 This commit introduced an issue. All upsell quote were canceled and no filtering was done on "alternative quotes". As a result it could disrupt legit business flow. Moreover, action_cancel was called instead of _action_cancell which can lead to ValueError: Expected singleton as action_cancel can require single record sometimes. Forward-Port-Of: odoo/enterprise#107417
This update ensures that all rates displayed on the printed payslip are formatted to a maximum of 4 decimal places. This improves the clarity and consistency of the payslip output, aligning with reporting standards. The change was implemented to address a formatting issue.
Original PR description
This commit improves the payslip display by limiting all rates to 4 decimals max on the printed pdf payslip. Task: 5709739 Forward-Port-Of: odoo/enterprise#104915
3 changes
Resolved issues and error corrections
This update resolves a technical issue where `Image` and `Binary` objects were incorrectly linked. The fix ensures these object types maintain distinct type values, preventing potential data inconsistencies. This improves the stability and reliability of Odoo's image and binary management.
Original PR description
This fixes an oversight of 4840a6639deb171c28ae14b0269d420aa1503860 that `Image` and `Binary` objects have the same `self.type` value and thus an `Image` can relate to a `Binary`, after all. Forward-Port-Of: odoo/odoo#249260
This update ensures that Website Studio's translation terms are correctly applied only to views associated with the active website, resolving an issue where the default website's language was being used. This improves the accuracy and relevance of translations within the Studio interface, enhancing the user experience for website customization.
Original PR description
Problem: When opening the Studio XML editor when Website is installed, the translation terms corresponding to the Default Language of the first website in the database are used. This behavior should only be applied to the HTML/CSS Editor in Website. Purpose: Modify Website's override of get_related_views to only return translated views when called with a specific website in context. Steps to Reproduce in Runbot: 1. Activate a non-English (US) language. 2. Add this language to the Website with the lowest ID in the database, then set it to the Default Language of the Website. 3. Enter Studio and navigate to a view that has translation terms in its view (ex. Invoice PDF Report), then open the XML editor. opw-5136124
This update resolves an issue where Ecuadorian EDI reports generated duplicate headers, causing wasted space and inconsistent formatting. The fix ensures that only the required Ecuadorian header is displayed, aligning with legal requirements and improving report clarity. This change impacts reports for Ecuadorian companies.
Original PR description
**Steps to reproduce:** * Install the **l10n_ec_edi** module. * Use an **Ecuadorian company**. * Create and confirm a customer invoice, vendor bill, or delivery guide. * Print any Ecuadorian PDF…
**Steps to reproduce:** * Install the **l10n_ec_edi** module. * Use an **Ecuadorian company**. * Create and confirm a customer invoice, vendor bill, or delivery guide. * Print any Ecuadorian PDF report (invoice/credit note, purchase liquidation, withholding, or delivery guide). **Observed behavior:** * Generated PDFs display **two headers**: * The standard Odoo company header. * The legally required Ecuadorian EDI header. * This results in duplicated information and wasted space. **Cause:** * Ecuadorian report templates relied on `web.external_layout`, which automatically renders the Odoo company header. * A custom Ecuadorian header was added on top, instead of replacing the standard one. * Both headers were therefore rendered together. **Fix:** * Hide the standard Odoo header for **Ecuadorian companies** in `external_layout_standard`. * Use the Ecuadorian header as the document title for local EDI reports. **Before:** <img width="549" height="379" alt="image" src="https://github.com/user-attachments/assets/0352ddad-f4b5-4764-aed1-291f6f514f8d" /> **After:** <img width="606" height="516" alt="image" src="https://github.com/user-attachments/assets/2b491ffc-9430-4858-a25e-0423da59cfe5" /> opw-5414882