Daily updates from Odoo
Friday, July 3, 2026
28 changes · master
Resolved issues and error corrections
Payroll run creation now keeps the selected branch company instead of falling back to the main company. This prevents blocking warnings and supports accurate payroll processing for branch employees, including Hong Kong payroll flows.
Original PR description
[FIX] hr_payroll: fix correct company selection in payrun (branch case) Bug reproduc: 1 - Select 19.3 or master -> Open a branch to belgium company -> create an employee in that branch 2 - In your…
[FIX] hr_payroll: fix correct company selection in payrun (branch case)
Bug reproduc:
1 - Select 19.3 or master -> Open a branch to belgium company -> create an employee in that branch
2 - In your env, select both belgium and its branch, payroll->payrun->select branch as a company.
3 - Continue till the end of payrun creation, you will get warning (blocked) due to wrong company selection, main belg company is selected instead of branch
Bug cause:
1 - In selectEmployees function of hr_payslip_run_form, in the raw_record the company_id is passed as integer.
2 - In buildRawRecord function of hr_version_list_controller, we are assigning company_id as raw_record's company_ids id, but company id was already integer, company_id.id is undefined
3 - Since undefined is passed to the company_id, it uses the self.env.company_id as a default in the creation of hr payrun that cause to the error.
Bug fix:
1 - In the buildRawRecord function of hr_version_list_controller, I just assigned the company_id because it is already integer and all problem is solved.
task - 6326117
Forward-Port-Of: odoo/enterprise#122538
Forward-Port-Of: odoo/enterprise#121505Belgian payroll now handles cases where a student minimum wage salary scale cannot be found without causing the calculation to fail. This helps payroll teams avoid unexpected errors and keeps wage checks running reliably.
Original PR description
When computing _get_student_min_wage and the specific salary scale is not found, it returns None and then fails in the tuple compression as None is not an interable. task-6318004 Forward-Port-Of: odoo/enterprise#122500 Forward-Port-Of: odoo/enterprise#121392
Fixes a point of sale issue where deleting an order line with a custom product attribute could make the kitchen preparation display go blank. The display now stays available and continues showing the order information it can safely resolve, reducing disruption for kitchen staff.
Original PR description
When an order is sent to the preparation display and one of its products has an attribute with a custom (free text) value, completely deleting that line in the PoS makes the whole preparation display…
When an order is sent to the preparation display and one of its products has an attribute with a custom (free text) value, completely deleting that line in the PoS makes the whole preparation display crash and show a blank white screen, so the kitchen can no longer see any order. Steps to reproduce: ------------------- * Configure a PoS product with an attribute whose variant that has a custom (free text) value. * In the PoS, add the product, select that attribute value and send the order to the preparation display. * Back in the PoS, completely delete that order line (do not just set its quantity to 0) and send the order to the preparation display again. > Observation: The preparation display crashes and only a white screen is shown. The browser console reports "TypeError: Cannot read properties of undefined (reading 'id')". Why the fix: ------------ Completely deleting the line deletes the source pos.order.line, so the preparation line that is still displayed no longer resolves its `pos_order_line_id`. While building the attributes to display, the orderline component dereferenced `.id` on that (now undefined) relation, as well as on the related custom value records, which threw and brought down the whole preparation display instead of only that line. We now guard those relations: when the originating order line is gone, the unresolvable custom value is simply dropped and the attribute is still shown, keeping the preparation display alive. opw-6282607 Forward-Port-Of: odoo/enterprise#122691 Forward-Port-Of: odoo/enterprise#121194
This update fixes an internal test setup issue in the Urban Piper point-of-sale integration. It keeps test-only changes properly contained, helping maintain code quality checks without affecting day-to-day users.
Original PR description
Avoid polluting the Odoo model registry and failing `test_lint_override_signature` by using `patch.object` instead of manual assignment. This ensures the injected method is properly torn down after the test block, keeping the registry clean and bypassing static analysis failure as the patched method is only used for tests. runbot-939298 Forward-Port-Of: odoo/enterprise#122446 Forward-Port-Of: odoo/enterprise#122283
This update corrects automated test coverage for Swedish SEPA payment files when related payment modules are installed together. It helps ensure Sweden-specific bank payment exports remain validated without false test failures.
Original PR description
Here https://github.com/odoo/enterprise/pull/114662 we changed the way the CdtrAgt node is used in the SEPA XML file for Sweden. But this change broke a test when both account_iso20022 & l10n_se_bban are installed, leading to a Non-expected child error. This commit skip the failling test if l10n_se_bban is installed, and add a new one to replace it. runbot-938366 runbot-938367 Forward-Port-Of: odoo/enterprise#122599 Forward-Port-Of: odoo/enterprise#121485
This update resolves issues with knowledge tours and web_studio's Powerbox functionality. By inserting a forward slash into the DOM and adjusting event handling, the system now correctly simulates Powerbox opening, ensuring tours function as expected and web_studio's editing features are reliable.
Original PR description
#### Description of the issue: - Since the search powerbox plugin now checks for the actual existence of `/` in the DOM, some knowledge tours were failing because only the input event was dispatched without inserting `/`. - In web_studio, `insertText` was not positioning the selection correctly after insertion and was not dispatching beforeinput event before the DOM insertion. #### After this commit: - Adapt the `openPowerbox` utility in knowledge to insert `/` in the DOM before opening the powerbox. - Dispatch `beforeinput` before DOM insertion and `input` after it in web_studio, and move the selection after the inserted text. Community PR-https://github.com/odoo/odoo/pull/266284 task-6243724 Forward-Port-Of: odoo/enterprise#118310
This update fixes an issue where customer names weren't being correctly displayed in Odoo bookings created through Reserve with Google. Now, when booking through Google, the customer's full name (first and last) is used instead of just their email address, improving the user experience and contact information accuracy.
Original PR description
When a customer books through Reserve with Google, the createBooking payload carries the booker given_name and family_name next to the email, but the handler passed only the normalized email to…
When a customer books through Reserve with Google, the createBooking payload carries the booker given_name and family_name next to the email, but the handler passed only the normalized email to _mail_find_partner_from_emails. The new res.partner was therefore created with its name falling back to the email, see https://github.com/odoo/odoo/blob/aa7b5921191a0ff53ef1cc32af99fe458c45c0da/addons/mail/models/res_partner.py#L177 That name then flows into the calendar.event name, the attendee common_name and the contact details, all showing the email instead of the customer name. The module has read neither field since it was added in https://github.com/odoo/enterprise/commit/2e855b910173b56e8501d0ebe9ee6f83ac5845bc. Build the booker name from given_name and family_name and pass it with the email through formataddr in google_reserve_booking_create, so a newly created partner is named after the customer. A partner matched on an existing email keeps its current name. Steps to reproduce: 1. Enable Reserve with Google on an appointment type. 2. Book a slot from Google Maps with given name John and family name Doe. 3. Open the created booking and its contact in Odoo. => the contact name is the email instead of John Doe Ticket [link](https://www.odoo.com/odoo/project/49/tasks/6232318) opw-6232318 Forward-Port-Of: odoo/enterprise#120604
This update fixes an issue where the withholding tax return was incorrectly combining balances with regular tax returns. The change ensures the withholding tax return accurately calculates the independent balance due, resolving a discrepancy in reported tax liabilities for Italian companies. This improves the accuracy of tax reporting.
Original PR description
Steps to reproduce: - setup an Italian company - make an invoice (for example in May) with a withholding tax and make a transaction to pay it - generate tax returns (opening date in June so that it generates from May) - validate regular tax return for May - validate withholding tax return for May -> The withholding tax return shows an amount to pay with a balance that is a combination of both the regular tax return and the withholding one, while it should be independent of the regular one. task-6116304 Forward-Port-Of: odoo/enterprise#121254 Forward-Port-Of: odoo/enterprise#119375
A recent update removed a dependency and added a new project field to improve data accuracy. This change resolved a test failure (test_fsm_flow) that indicated missing project information. The update ensures correct project data is fetched within the planning module.
Original PR description
Currently, running test `test_fsm_flow` leads to a Attribute Error: `planning.slot' object has no attribute 'project_id'`. This happens because project_id field removed in this PR: https://github.com/odoo/enterprise/pull/113153 This field is removed to remove `project_timesheet_forecast_sale` module in the dependencies of `planning_field_service_sale_timesheet` module and add a project field in settings of planning when Billing feature of field service is enabled. Related PR: https://github.com/odoo/enterprise/pull/83012 runbot-[941219](https://runbot.odoo.com/odoo/error/941219) Forward-Port-Of: odoo/enterprise#122442
This update ensures that only complete and accurate address data is sent to Fiskaly when creating POS certificates. Previously, placeholder values like 'N/A' were included, which is now corrected to omit fields when data isn't available, streamlining the process and improving data quality. This change enhances integration with Fiskaly and reduces potential errors.
Original PR description
In this commit: ------------------- - Buyer address fields are optional and should only be sent to Fiskaly when they are actually available. - Avoid sending placeholder values like "N/A". If the data is not present, the fields should simply be omitted from the request. task: 6113133 Forward-Port-Of: odoo/enterprise#122188 Forward-Port-Of: odoo/enterprise#113621
This update resolves an issue where downloading the ETA payroll form generated an error due to incorrect file formatting. Additionally, a warning about missing employee data (like Social Insurance Number) was fixed by adding a dependency to automatically recompute warnings when the data changes. These improvements ensure accurate payroll reporting and data integrity.
Original PR description
Issue 1: Steps to Reproduce: -> Create Payslip for Employee -> Once payslip is validated, Click Pay, and for Mode Choose ETA Form 2 -> Download and open the File it throws Formatting error Cause: The Excel workbook was base64-encoded before being written to the binary field, which expects raw bytes. Fix: Save raw binary data directly and update the test case to load it using `io.BytesIO` on binary field content Issue 2: Steps to Reproduce: -> Create a payslip for an employee missing (like EG Social Insurance Number) -> A warning is raised that field is missing. -> Even if the field is filled, the warning does not disappear. Cause: There is no compute dependency to recompute warnings when value changed. Fix: Added dependency in `_issues_dependencies` so it recomputes when value changes. task-**6292194** Forward-Port-Of: odoo/enterprise#122474 Forward-Port-Of: odoo/enterprise#120544
This update fixes an issue where sales from European companies to Northern Ireland (XI) were incorrectly calculating intra-community taxes. The change adds a check to ensure these transactions are treated as third-country sales, aligning with tax regulations. This ensures accurate financial reporting.
Original PR description
…stomers The services sales done from a European company to a Northern Ireland (XI) company should not contain intra-community taxes but should be treated as third country (non-EU) transactions. We solve it by adding a check in the EC Sales List return that is only visible when a wrong record occurs. task-6007931 Forward-Port-Of: odoo/enterprise#122535 Forward-Port-Of: odoo/enterprise#121487
This update fixes an issue where the payrun chatter window would disappear unexpectedly during certain actions, disrupting the payroll process. The change ensures the chatter window stays open and functional, improving the user experience when continuing pay runs. The fix was triggered by a bug in how the system refreshed messages related to pay runs.
Original PR description
The payslip run aside chatter was keyed on a revId counter that _updatePayRun bumps on every payrun update (view button actions, the HR_PAYROLL:UPDATE_PAYRUN bus, the step bubble refresh). Changing a t-key makes Owl destroy and recreate the whole chatter, which resets composerType to false. When a refresh landed while the log note composer was open, the composer input disappeared. In the payrun tour this happens right after continuing a pay run, so posting the third note timed out waiting for .o-mail-Composer-input. Remove the t-key and refresh its messages through the MAIL:RELOAD-THREAD bus that the Thread already listens to. The server posted status messages still show up without throwing away the composer. https://runbot.odoo.com/odoo/error/941272 Forward-Port-Of: odoo/enterprise#122518
This update fixes an issue where GS1-compliant barcodes were not correctly interpreted as product scans. When enabled, the system now accurately processes these barcodes, ensuring correct quantity updates during scanning, improving inventory accuracy.
Original PR description
In certain cases the barcode of a product could be a valid standalone GS1 sequence. In that case it needs to be be correctly interpreted as a product scan. ### Steps to reproduce: - In the settings…
In certain cases the barcode of a product could be a valid standalone GS1 sequence. In that case it needs to be be correctly interpreted as a product scan. ### Steps to reproduce: - In the settings enable "Default GS1 Nomenclature" - Create a storable product P with the barcode 3701762412212 - Create and confirm a delivery for 2 units of P and set the qty to 2 - Go to the barcode app and open your delivery - Scan 3701762412212 > The line of P is now selected with a quantity of 1/2 - Scan 3701762412212 #### > A new line is created for 1762411 units ### Cause of the issue: According to the GS1 nomenclature, the barcode 3701762412212 matches the scan of a quantity of "1762412" units of the lot name "2". As the scan of the of the product match a pattern for the GS1 nomenclature before matching a product, its barcode data is expected to be reset by these lines: https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/stock_barcode/static/src/models/barcode_model.js#L1320-L1324 In order to bypass the GS1 parser and to add 1 unit of the product. This is what happen on the first scan. However, performing the first scan also selects the associated line and, hence on the second scan the lines just above this check do set the product to match the product of the current line: https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/stock_barcode/static/src/models/barcode_model.js#L1294-L1320 In particular, we do not bypass the result provided by the GS1 parser and add `1762412` units of the product. opw-6175621 Forward-Port-Of: odoo/enterprise#122256 Forward-Port-Of: odoo/enterprise#120035
This update fixes an issue where bank reconciliation calculations were incorrect when dealing with foreign currencies. The system now properly converts amounts from the journal currency to the company currency, ensuring accurate balance calculations and preventing constraint errors. This improves the reliability of bank reconciliation processes.
Original PR description
### Issue: When a bank journal uses a foreign currency, reconciliation model lines with `Amount Type: From Label` (regex) could raise a constraint error or produce incorrect balances on the journal…
### Issue: When a bank journal uses a foreign currency, reconciliation model lines with `Amount Type: From Label` (regex) could raise a constraint error or produce incorrect balances on the journal entry ### Cause: The `balance` of the generated move line was set to the raw value extracted by the regex, without converting it from the journal currency to the company currency This violated the sign constraint between `balance` and `amount_currency` when the exchange rate caused a mismatch, raising a `_check_amount_currency_balance_sign` error The `amount_currency` was already correctly set Only the `balance` conversion was missing ### Steps to reproduce: - Install `accountant` - Enable a foreign currency (e.g. EUR) with two rates: yesterday: ratio < 1 (e.g. 0.5), today: ratio > 1 (e.g. 2.0) - Create a Bank journal in EUR - Open Bank Reconciliation for that journal - Add two transactions (one dated yesterday, one today) (Ref: "test BANK:0001690,00EUR EXP:00033,80", amount: 1656.20) - Create a reconciliation model (3 dots > Manage Models) (name: From Label): -- Account: 101401 Bank, Amount: BANK:0*(\d+),(\d+) -- Account: 600000 Expenses, Amount: EXP:0*(\d+),(\d+) - Apply the model on both transactions Before the fix, one raised an error due to the constraint violation - From the list view, open the Journal Entry for the other transaction Before the fix, `balance` was not converted to company currency opw-6292839 Forward-Port-Of: odoo/enterprise#121114
This update fixes an issue where group payments weren't correctly updated when invoices were modified, leading to reconciliation problems. The change ensures that all payments, including group payments, transition to 'In Process' state when a statement line is unreconciled, resolving a discrepancy in payment status.
Original PR description
**Steps to reproduce:** - Install Accounting - Create an invoice: * Customer: Partner A * Total: 30.00 - Confirm the invoice - Create a second invoice for the same customer: * Customer: Partner A *…
**Steps to reproduce:** - Install Accounting - Create an invoice: * Customer: Partner A * Total: 30.00 - Confirm the invoice - Create a second invoice for the same customer: * Customer: Partner A * Total; 10.00 - Confirm the invoice - From the invoice list, select both invoice - Create payment: * Journal: Bank * Group Payments: [checked] * Group Payments: [checked] * Amount: 40.00 - Create a third invoice for another customer: * Customer: Partner B * Total: 25.00 - Confirm the invoice - Register payment from the invoice - Create a fourth invoice for another customer: * Customer: Partner C * Total; 40.00 - Confirm the invoice - Register payment from the invoice - From the payment list, select all 3 payments and create batch payment - Validate the batch payment - From Accounting dashboard, open Bank journal - Create a new bank statement line of 105.00 - Match it with the batch payment At that point, the statement line is reconciled with the 4 invoices and the 3 payments are marked as paid. - Go to the fourth invoice - Reset it to draft - Change the price - Save When the amount of the invoice is changed, the statement line is unreconciled and all the payments should change state from "Paid" to "In Process". **Issue:** All the single payments have their state correctly changed to "In Process", except for the group payment for the 2 first invoices, which leads to undesired values when trying to reconcile the statement line with the batch payment again. **Cause:** When the statement is unreconciled, all the partial reconcile records are deleted and the state of the linked payments are updated to "In Process". The payments are retrieved by checking if there are linked to an account move present in the partial reconcile record and if the amount of the payment matches the amount of the partial reconcile record. In case of a group payment, there are 2 partial reconcile records for each invoice linked to the payment. Therefore, in that case, the amount doesn't match the amount of the payment because it matches the amount of one of the invoice. opw-6141089 Forward-Port-Of: odoo/enterprise#122585 Forward-Port-Of: odoo/enterprise#120210
This update fixes a display issue in the Intrastat report where bill names were being cut off before hyphens. The change adjusts a regular expression to correctly handle hyphen characters in bill names, ensuring complete and accurate reporting. This improves the clarity and usability of Intrastat reports.
Original PR description
**Steps to reproduce:** - Install Accounting - In Accounting settings, activate "Intrastat" - Create a product with Intrastat info - Create a bill: * Product: [the created Intrastat product] *…
**Steps to reproduce:** - Install Accounting - In Accounting settings, activate "Intrastat" - Create a product with Intrastat info - Create a bill: * Product: [the created Intrastat product] * Intrastat Country: [any] * Intrastat Transport Mode: [any] - Confirm the bill - Make sure that the bill name contains a hyphen character (i.e. "-") For example, "BILL/2026-06/0001". Use the "Resequence" action from the bills list view if needed. - Go to "Accounting / Reporting / Audit Reports / Intrastat Report" - Expand the line to display the bill name **Issue:** The bill name is not fully displayed. It is cropped right before the hyphen character (i.e. BILL/2026). **Cause:** A regex is used to retrieve the bill name from the report line name, but it is only allowing "/" character. **Solution:** Just allow "-" character in addition. No other character is allowed to limit the risk of matching something that should not. opw-6299854 Forward-Port-Of: odoo/enterprise#120979
This update fixes an issue where users would lose the project, description, and task information they entered in the Timesheets systray when closing it. The previous fix was an unnecessary precaution, and this update removes it, ensuring data is saved correctly.
Original PR description
## Issue When using the Timesheets systray, if we set a project after clicking the *Save* or *Reset* button, the project is not saved after closing the systray. ## Steps to reproduce 1. Install…
## Issue When using the Timesheets systray, if we set a project after clicking the *Save* or *Reset* button, the project is not saved after closing the systray. ## Steps to reproduce 1. Install *Timesheets* (`timesheet_grid`) 2. Open the Timesheets systray 3. Click *Reset* and set a description, a project and/or a task, then close the systray 4. Open the systray again 5. **The description/project/task set in step 3 do(es) not appear anymore.** ## Cause Commit https://github.com/odoo/enterprise/commit/b9b7f8a0acf7a1c545c6613cf8bbc29871632e26 introduced the `preventUnmountSave` attribute. The attribute is set to `true` after saving and discarding an entry. When the systray is unMounted, the manual values (e.g., description, project and task) are not saved if the attribute is set to `true`: https://github.com/odoo/enterprise/blob/7cd8dd008eb88d6c12f3e65fb8d311058290a301/timesheet_grid/static/src/components/timesheet_timer_inline_form/timesheet_timer_inline_form.js#L171-L174 ## Fix After discussing with the author of the previous commit, it appears this was done to prevent an issue with values stored in cache, but that issue does not seem to occur anymore, which leads to believe that the attribute is not required anymore. opw-6284016 Forward-Port-Of: odoo/enterprise#122332 Forward-Port-Of: odoo/enterprise#121605
This update reverts a recent change that allowed employees to directly edit personal information within Odoo. Management requested this change to prevent potential inaccuracies in payroll calculations and ensure compliance with tax regulations. HR team oversight will now be required for any updates to this sensitive data.
Original PR description
This reverts the recent changes that exposed the "Family" and "Personal Info" sections (such as Marital Status) in the employee's "My Preferences" menu. While the initial addition was intended to improve employee self-service, management requested this revert because allowing employees to directly edit these fields poses a risk to payroll accuracy and compliance. Data points like marital status or family dependents directly impact tax deductions and benefit enrollments. To ensure data integrity, any modifications to payroll-affecting information must remain the exclusive duty of the HR team, who can require and verify the proper legal documentation before updating the system. task-6304031
This update resolves an issue where signed documents were incorrectly placed in separate folders, leading to duplicate entries and confusion. Now, signed documents from both the Documents and HR apps appear only in their respective folders (Employee/Payroll), and no extra documents are created upon completion. This ensures data consistency and simplifies document management.
Original PR description
Before: - Documents flow: after signing, the signed copy was placed in the Sign folder instead of the same folder as the original document. - HR flow: after signing a sign.request linked to an HR…
Before: - Documents flow: after signing, the signed copy was placed in the Sign folder instead of the same folder as the original document. - HR flow: after signing a sign.request linked to an HR record (e.g. hr.employee, hr.version), the signed document appeared twice, once in the Employee/Payroll folder and again in the Sign folder. - [_sign()](https://github.com/odoo/enterprise/blob/19.0/sign/models/sign_request.py#L505) attaches a copy of the signed document to the linked record, but the missing `no_document=True` was mistakenly creating an extra document - Import from Documents flow: after signing via "Import from Documents" in the Sign app, the signed copy was placed in the original document folder instead of the Sign folder. After: - Documents flow: the signed document is now placed in the same folder as the original document. - HR flow: the signed document is created only once, in the Employee/Payroll folder. No copy is made in the Sign folder. - No extra documents are created in the background when a sign request linked to a record is completed. - Import from Documents flow: the signed document is now placed in the Sign folder. Impact: - Signed documents from the Documents app stay in the same folder. - Signed HR contracts appear only in the Employee/Payroll folder. - No duplicate documents are created on completion. Task: 6176315
This update resolves a tour test failure in the Belgian HR contract salary module. The issue stemmed from a configuration that incorrectly expected an identification number or NISS when the core payroll module was not installed. The fix ensures the necessary fields are displayed correctly when the Belgian payroll module is active, improving test reliability.
Original PR description
[FIX] l10n_be_hr_contract_salary: fix NISS runbot error in salary config Bug reproduction: 1 - Get 19.4, only install hr_contract_salary and execute tour test hr_contract_salary_employee_flow_tour 2…
[FIX] l10n_be_hr_contract_salary: fix NISS runbot error in salary config
Bug reproduction:
1 - Get 19.4, only install hr_contract_salary and execute tour test hr_contract_salary_employee_flow_tour
2 - When only single app is installed without installing l10n_be_hr_contract_salary, the tour test fails
Bug cause:
1 - When the employee's company's country is belgium we were showing NISS instead of identification number.
2 - But NISS field is appended in l10n_be_hr_contract_salary and if you do not install, there is no identification number and NISS.
3 - That's why the test fails (it looks for identification number or NISS but none of them is there)
Bug solution:
1 - I moved the code of hiding identification number or hiding NISS to the l10n_be_hr_contract_salary. So, when only hr_contract_salary is installed, identification number field won't get hided.
task - 6333129
runbot error link: https://runbot.odoo.com/odoo/error/941044
Forward-Port-Of: odoo/enterprise#121800This update removes the ability to quickly create new journals from the POS payment method form. The accounting team requested this change to ensure users only create journals within the dedicated accounting application, improving process control and data accuracy. This change applies locally and can be extended where needed.
Original PR description
Currently on the pos payment method form, if you click "Select more" on the journal field, you will see two buttons 'New' & 'Create New'. Steps to reproduce: ------------------- * Open any pos…
Currently on the pos payment method form, if you click "Select more" on the journal field, you will see two buttons 'New' & 'Create New'. Steps to reproduce: ------------------- * Open any pos payment method * Select the journal field * Select "Search more" > See two creation buttons Why the fix: ------------ One button is the standard "On search more" button which can be hidden using options such as no_create, no_create_edit, ... The second button is defined on the list view for journals and since the search more uses the list view it shows the button as well. Currently we can do that with a context key to ensure that on the "real" list view it's still visible. Why do we want to hide those buttons? Asked the R&D accounting team, it should not be allowed to create journals on the fly. You should only be able to create them inside accounting app. This behavior is not limited to this view but will only be applied locally. The fix can however be applied everywhere where needed. Before the fix: ------------------- <img width="700" height="417" alt="image" src="https://github.com/user-attachments/assets/ca11ea13-c38e-40a1-9848-cbc5edc6226e" /> <img width="1507" height="887" alt="image" src="https://github.com/user-attachments/assets/1cde5d3b-3372-4aca-b5d0-2319bd82c1de" /> After the fix: ---------------- <img width="707" height="474" alt="image" src="https://github.com/user-attachments/assets/01dc7b42-43d6-4b18-a12d-54330d51b92b" /> <img width="1457" height="870" alt="image" src="https://github.com/user-attachments/assets/ff387d3f-f59c-47ad-abfe-a2003669db1a" /> opw-6131231 Forward-Port-Of: odoo/enterprise#120379
This update fixes an error in calculating holiday attest annual taxable income for employees on long-term sick leave (over 30 days). Previously, the calculation was incorrect due to a reliance on zero-valued payslips. Now, the system uses the employee's monthly wage to ensure accurate taxable income calculations, aligning with Belgian tax regulations.
Original PR description
Problem ---------------------- When an employee takes a long sick leave (more than 30 days), the basic wage on the payslip is set to 0, leading to the holiday attest annual taxable income to be…
Problem ---------------------- When an employee takes a long sick leave (more than 30 days), the basic wage on the payslip is set to 0, leading to the holiday attest annual taxable income to be calculated as 0 * 12, which is incorrect. Reason ------------------- The calculation for the holiday attest uses the last payslip for the employee, and if the employee had leave type LEAVE214, the last payslip has the basic wage set to zero, so the taxable wage that is used in the annual taxable wage calculation is wrong. The monthly wage should be used as the basic wage in the payslip to get the correct computation. Solution ------------------- The GROSS (taxable income) line that is used is computed as (basic wage - ONSS total + BIK), but the basic wage was 0. This commit checks whether the basic wage is 0 and if the time off type was longterm sick leave, and simulates a payslip using the monthly wage from the contract as basic wage to get the accurate computation for the taxable income. task-6237717 Forward-Port-Of: odoo/enterprise#120180
This update resolves a technical issue that caused build failures in certain testing modes. The team moved assertions to their correct locations, ensuring consistent build behavior across all environments. This improves the reliability of our software development process.
Original PR description
Oversight of: https://github.com/odoo/enterprise/pull/98569 Some assertions were put in the wrong module, making the builds work in "all apps" mode but fail in "single app" mode. This commit moves assertions where they belong. Task-6353709 Forward-Port-Of: odoo/enterprise#122486
This update fixes an issue where CFDI documents generated after payment updates incorrectly displayed rates, particularly when payments were made in foreign currencies (like USD). The fix ensures the correct payment amount and rate are reflected in the CFDI document, improving accuracy and compliance for Mexican tax reporting.
Original PR description
The rate and payment amount shown on the CFDI document generated after updating payments was wrong when the payment was made in a foreign currency. Steps to reproduce: ------------------- * Create a journal that use USD as currency and set the rate to 20 MXN for 1 USD * Create an invoice in MXN and make sure it is set to PPD * Add any product to the invoice for 300$ and post it * Send the invoice to CFDI (a first document should be generated) * Create a payment of 15 USD in the new journal and reconcile it with the invoice * Go back to the invoice and click on "Update payments" to generate the second CFDI document > Observation: The payment document shows an amount of 300 USD with a rate of 1 instead of 15 USD with a rate of 20. Why the fix: ------------ We make sure to use the amount from the statement line when there is one. opw-5974519 Forward-Port-Of: odoo/enterprise#122117 Forward-Port-Of: odoo/enterprise#115779
This update fixes a vulnerability in the Odoo test for Brazilian Electronic Invoice (BR-EDI) processing. The previous test was overly reliant on a specific message format, making it prone to failure due to minor changes in invoice data. The fix now searches for the key information across all invoice messages, ensuring more reliable test results.
Original PR description
The test was relying on a fixed chatter message position. Another tracking message can be inserted before the informative taxes message, so the assertion may read the wrong body. Search the expected informative taxes content among all invoice messages instead. Broke the runbot of : https://github.com/odoo/odoo/pull/273569
This update resolves a technical problem where web studio's technical names were incorrectly generating `x_studio_<type>_NaN` values. The fix ensures these names are generated correctly, preventing potential errors and improving the stability of the web studio functionality. This change ensures consistent and reliable technical naming conventions.
Original PR description
The PR #119993 introduced a bug leading to technical names being named `x_studio_<type>_NaN`. This commit fixes the issue. A `_NaN` increment is only possible if the increment reach int max size. task-6353814 Forward-Port-Of: odoo/enterprise#122594
This update corrects a warning in the planning module that occurred when trying to modify certain settings. The change ensures data restrictions are applied correctly, preventing potential issues with data integrity. This improves the stability and reliability of the system.
Original PR description
The `@api.constrains` decorator was listening to `company_id`, which is a readonly related field. This triggers an ORM warning ("parameter 'company_id' is not writeable").
Swapped the constraint trigger from `company_id` to `warehouse_id`. Since the company is fully dependent on the warehouse, this safely achieves the exact same trigger logic.
build: [940408](https://runbot.odoo.com/odoo/runbot.build.error/940408)
Forward-Port-Of: odoo/enterprise#121584