Daily updates from Odoo
Navigate
Branch
Saturday, February 28, 2026
38 changes
10 changes
Resolved issues and error corrections
This update fixes an issue where QR code payment links for installment-based invoices were incorrectly showing the full outstanding amount. By using the default values for the payment link wizard, the links now accurately display the next payable installment, ensuring accurate payments.
Original PR description
The link from QR code in invoice pdf was explicitly passing `amount`, `res_model`, `res_id` to create `payment.link.wizard` using create method which overrides default_get() of wizard. As a result, installment-based invoices were generating payment links for the full residual amount. Also the `active_id` and `active_model` is passed in context which writes to `res_model` and `res_id` so no need to add it in create again. By letting default_get() populate the wizard values, the payment link now correctly reflects the next payable installment. task-5401335 Forward-Port-Of: odoo/odoo#241825
This update resolves an issue where selection fields would display an error if a chosen value wasn't available in the current options. Now, the field will gracefully display the original, raw value instead, preventing disruptions to the user experience. This ensures smoother operation and avoids unexpected errors when working with selection fields.
Original PR description
When a selection field contains a value not found in the current options list, display the raw value instead of raising an error. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251201
This update resolves a compatibility issue in Firefox 148 related to how initial blank pages are loaded. By using empty iframes, the website and snippet editors now load correctly and immediately, eliminating delays and ensuring a smoother user experience. This change improves performance and reliability for our users.
Original PR description
Firefox 148 fixed the behavior of `about:blank` documents, as explained in their [release notes]: > The initial about:blank document is now Web-compatible. If the first > navigation of a browsing…
Firefox 148 fixed the behavior of `about:blank` documents, as explained in their [release notes]: > The initial about:blank document is now Web-compatible. If the first > navigation of a browsing context goes to about:blank, it completes > synchronously and is no longer replaced by a second parser-generated > document. Commit [e0796020] added the new page dialog in website, and used empty iframes to load each page template. Commit [edf81c13] added the add snippets dialog in website, and used an empty iframe to load the snippets previews. In both cases, before Firefox' fix, it meant we had to wait the recreation of the 2nd document before proceeding. This is no longer the case in Firefox >= 148. [release notes]: https://www.firefox.com/en-US/firefox/148.0/releasenotes/ [e0796020]: https://github.com/odoo/odoo/commit/e0796020ee0c3188e1e9d9fa077de73a2211c6f7 [edf81c13]: https://github.com/odoo/odoo/commit/edf81c13d8f2f6d29a77d68cbfa0dc9216da3c2a Forward-Port-Of: odoo/odoo#251172 Forward-Port-Of: odoo/odoo#250592
This update enables the copying of the main attachment from a vendor to the newly created invoice when using the 'Reverse and Create Invoice' button. This streamlines the process for users needing to attach relevant documents during invoice reversal, improving data accuracy and efficiency. It addresses a previous limitation in the system.
Original PR description
This commit copies the main attachment to the newly created vendor through the "Reverse and Create Invoice" Button. task-5905299 Forward-Port-Of: odoo/odoo#250183
This update fixes an issue where QR codes generated in Point of Sale were incorrectly pointing to 'localhost:8069' instead of the associated company's website. The change ensures that QR codes now accurately reflect the correct URL for generating invoices, improving the customer experience.
Original PR description
Steps to reproduce ------------------ 1. Make a website, associated with company 'A' 2. Add a `domain` on that website, e.g. 'test.domain.com' 3. Select company 'A', and create a PoS shop for it 4.…
Steps to reproduce ------------------ 1. Make a website, associated with company 'A' 2. Add a `domain` on that website, e.g. 'test.domain.com' 3. Select company 'A', and create a PoS shop for it 4. Enable 'Self-service invoicing' for that PoS shop, select 'QR code' 5. Open the shop, select a client and make an order -> The generated QR code point to the domain 'localhost:8069' and not to the company's website domain 'test.domain.com'. Why the issue ------------- In 1ee02f8a47d42d3ba3fd11ffcf8d9768ea17678e, we moved the `_base_url` from the session to the config. So now we call `self.get_base_url` on the config and not on the session anymore. However, `self` is an empty config created on the fly, and it's not the `session.config_id` config object used by that shop. The fix ------- In `_load_pos_data_read` of the config model, we call `get_base_url` on the `config` instance, which is garanteed to be the valid config of that shop. opw-5942057 Forward-Port-Of: odoo/odoo#251177 Forward-Port-Of: odoo/odoo#249858
This update fixes an issue where the calculation of 'sandwich leave' (leave periods surrounding holidays) was incorrect. Specifically, when leave was approved and then re-approved, the system failed to properly account for neighboring leave days, leading to an inaccurate leave count. This change ensures that leave durations are calculated correctly, aligning with the intended business logic.
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 Forward-Port-Of: odoo/odoo#251111 Forward-Port-Of: odoo/odoo#244235
This update resolves an issue where the legal name displayed in payroll reports was not accurately reflecting the employee's legal name in Switzerland. The fix ensures that the correct legal name is computed and presented, complying with Swiss legal requirements and improving reporting accuracy. This update primarily impacts the l10n_ch_hr_payroll module.
Original PR description
task-5979726 Forward-Port-Of: odoo/enterprise#109037
This update resolves an issue where work entries weren't being created when multiple resource calendar attendances were close together in time. The fix prevents attendances from being incorrectly combined, ensuring accurate work entry generation for employees. The change improves the reliability of the payroll and time tracking processes.
Original PR description
When you have two resource calendar attendances that are stuck together, and you generate work entries, the second one doesn't appear: Bug is caused when having two attendances stuck together: In a resource.calendar, change the time of a resource.calendar.attendance to finish at 15.36 and create a new one that begins at 15.36 and finished at 16.36 with a work entry type of Credit time. Go and regenerate work entries and you can see that no work entries are generated for credit time. Fixed by adding keep_distinct in an interval to not fuse them together. Also added extra checks to another test to not pass with incorrect values. task-5894994 Forward-Port-Of: odoo/enterprise#108993 Forward-Port-Of: odoo/enterprise#105981
This update fixes an issue where the 'Billable' and 'Non-Billable' timesheet filters were inaccurate, preventing the KPI button from working correctly. The fix now uses a more reliable method based on analytic line associations, ensuring timesheets are correctly categorized for reporting. This improves the accuracy of time tracking data.
Original PR description
Due to a previous [commit](https://github.com/odoo/odoo/commit/8e8b273), the "Billable" and "Non-Billable" were incorrect for timesheets. This lead the billable timesheet KPI button not to filter the timesheets anymore. This is fixed by filtering based on whether the analytic line has an SOL associated to it, which is more robust to changes in the `billable_type` field, and improves clarity. See odoo/enterprise#108347 task-5956027
This update corrects an issue where the 'Billable' and 'Non-Billable' timesheet filters were inaccurate, preventing the KPI button from working correctly. The fix now uses a more reliable method – checking for a linked Service Order Line (SOL) – ensuring accurate filtering and improved clarity. This enhances reporting on billable time.
Original PR description
Due to a previous [commit](https://github.com/odoo/odoo/commit/8e8b273), the "Billable" and "Non-Billable" were incorrect for timesheets. This lead the billable timesheet KPI button not to filter the timesheets anymore. This is fixed by filtering based on whether the analytic line has an SOL associated to it, which is more robust to changes in the `billable_type` field, and improves clarity. Further, remove unnecessary service patch introduced in odoo/enterprise#108035. See odoo/odoo#250149 task-5956027
6 changes
Resolved issues and error corrections
This update fixes a potential issue where selection fields would display an error if a selected value wasn't available in the current options. Now, the field will gracefully display the original, raw value instead, preventing disruptions to the user experience. This ensures a smoother and more reliable selection process.
Original PR description
When a selection field contains a value not found in the current options list, display the raw value instead of raising an error. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251201
This update fixes an issue where QR code payment links on invoices were incorrectly showing the full outstanding amount, especially for installment-based invoices. By using the default values for the payment link wizard, the links now accurately reflect the next payable installment, ensuring accurate payments.
Original PR description
The link from QR code in invoice pdf was explicitly passing `amount`, `res_model`, `res_id` to create `payment.link.wizard` using create method which overrides default_get() of wizard. As a result, installment-based invoices were generating payment links for the full residual amount. Also the `active_id` and `active_model` is passed in context which writes to `res_model` and `res_id` so no need to add it in create again. By letting default_get() populate the wizard values, the payment link now correctly reflects the next payable installment. task-5401335 Forward-Port-Of: odoo/odoo#241825
This update resolves a minor issue where website page loading in Firefox 148 was delayed due to how the browser handled initial 'about:blank' documents. By using empty iframes to load page templates and snippet previews, the process is now faster and more reliable in Firefox, ensuring a smoother user experience. This change improves performance and stability for website features.
Original PR description
Firefox 148 fixed the behavior of `about:blank` documents, as explained in their [release notes]: > The initial about:blank document is now Web-compatible. If the first > navigation of a browsing…
Firefox 148 fixed the behavior of `about:blank` documents, as explained in their [release notes]: > The initial about:blank document is now Web-compatible. If the first > navigation of a browsing context goes to about:blank, it completes > synchronously and is no longer replaced by a second parser-generated > document. Commit [e0796020] added the new page dialog in website, and used empty iframes to load each page template. Commit [edf81c13] added the add snippets dialog in website, and used an empty iframe to load the snippets previews. In both cases, before Firefox' fix, it meant we had to wait the recreation of the 2nd document before proceeding. This is no longer the case in Firefox >= 148. [release notes]: https://www.firefox.com/en-US/firefox/148.0/releasenotes/ [e0796020]: https://github.com/odoo/odoo/commit/e0796020ee0c3188e1e9d9fa077de73a2211c6f7 [edf81c13]: https://github.com/odoo/odoo/commit/edf81c13d8f2f6d29a77d68cbfa0dc9216da3c2a Forward-Port-Of: odoo/odoo#251172 Forward-Port-Of: odoo/odoo#250592
This update enables the copying of the main attachment from a vendor to the newly created invoice when using the 'Reverse and Create Invoice' button. This streamlines the process for users needing to reverse invoices while retaining important supporting documents, improving efficiency and data accuracy.
Original PR description
This commit copies the main attachment to the newly created vendor through the "Reverse and Create Invoice" Button. task-5905299 Forward-Port-Of: odoo/odoo#250183
This update fixes an issue where the calculation of 'sandwich leave' (leave periods surrounding holidays) was incorrect. Specifically, when leave was approved and then re-approved, the neighboring leave days weren't properly recomputed, leading to a 1-day discrepancy. This ensures accurate leave tracking for employees.
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 Forward-Port-Of: odoo/odoo#251111 Forward-Port-Of: odoo/odoo#244235
This update fixes an issue where the legal name displayed in payroll reports was not accurately reflecting the employee's legal name in Switzerland. The change ensures that the correct legal name is computed and presented, complying with Swiss legal requirements and improving reporting accuracy. This update impacts the l10n_ch_hr_payroll module.
Original PR description
task-5979726 Forward-Port-Of: odoo/enterprise#109037
1 change
Resolved issues and error corrections
This update corrects a calculation error related to employee legal names within the Odoo Enterprise payroll module. The fix ensures that employee names are accurately reflected in reports and legal documents, complying with Swiss regulations. This improves data accuracy and reduces the risk of reporting discrepancies.
Original PR description
task-5979726
2 changes
Resolved issues and error corrections
This update fixes an issue where invoices generated using the PEPPOL standard were incorrectly using company registry information. Previously, the system didn't verify that company registry data matched the required BCE number. This change ensures invoices comply with PEPPOL regulations, preventing potential errors and improving data accuracy.
Original PR description
We expect people to put BCE number in the company registry. But it is not enforced client-side, resulting in invoices in error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251168
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, leading to consistent pricing and payment reconciliation. This improves the accuracy of sales transactions.
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#108957
Forward-Port-Of: odoo/enterprise#1015791 change
Resolved issues and error corrections
This update corrects a problem with how leave periods are calculated, specifically related to time zone differences. By using `request_date_from` and `request_date_to` instead of `date_from` and `date_to`, the system now accurately reflects leave interruptions, ensuring correct payroll processing in Switzerland.
Original PR description
This commit fixes the leaves work interruption constraint by replacing `date_from` and `date_to` with `request_date_from` and `request_date_to`, thereby resolving any inconsistencies that may arise from time zone differences. task-5966780 Forward-Port-Of: odoo/enterprise#108541
16 changes
New functionality added to Odoo
This update adds support for Bancontact Pay via QR code payments in our Point of Sale system. Customers can now pay by scanning a QR code generated by the POS, aligning with growing trends in Belgium and the evolution of payment methods. Internal changes ensure consistent payment processing across all POS systems.
Original PR description
..., pos_iot, pos_iot_six, pos_iot_worldline, pos_settle_due, pos_tyro --- Task: [#4875917](https://www.odoo.com/odoo/project/1737/tasks/4875917) --- This commit introduces a new payment method type, `external_qr`, to handle QR-based payment flows directly in the Point of Sale. With the widespread adoption of QR code payments in Belgium and the evolution of Payconiq under Wero (Bancontact Pay), POS systems need native support for these new payment experiences. A new module, `pos_bancontact_pay`, is added to provide a full integration with the Bancontact Pay platform, allowing customers to pay by scanning a QR code generated in the POS. The module manages the creation, verification, and tracking of these payments. Some internal refactoring was also done to align the payment terminal logic with this new `external_qr` method type and ensure consistency across payment flows in POS.
This update allows payroll officers to select between standard and instant delivery methods for SEPA payments, offering greater flexibility in salary disbursement. This change aligns with evolving payment regulations and provides a more efficient process for delivering salaries to employees in Europe. It improves the overall payroll processing experience.
Original PR description
Payroll officers can now choose between standard or instant salary delivery when processing SEPA payments. Task: 5109368
This update adds support for accessing real-time currency exchange rates from the Central Bank of Cuba (BCC). This allows Odoo to accurately reflect the current value of Cuban currency for transactions and reporting, expanding financial reporting capabilities.
Original PR description
This commit introduces a new exchange rate provider for the Central Bank of Cuba (BCC). - Implement new exchange rate provider for Central Bank of Cuba (BCC) - Retrieve rates from official BCC source - Reference: https://www.bc.gob.cu/tasas-de-cambio (official published data and documentation) - Parse and normalize published currency values - Support multiple rate types (official, public, special)" Forward-Port-Of: odoo/enterprise#108789 Forward-Port-Of: odoo/enterprise#108367
Enhancements to existing features
This update simplifies the employee salary configuration by removing irrelevant fields and restricting access to certain settings. Specifically, the 'Seniority at Hiring' input is now only available for Belgian companies, and demo data related to school and car plate information has been removed. This improves data accuracy and reduces complexity for Belgian users.
Original PR description
- Remove the School and Private Car Plate inputs from the employee salary configurator. - Restrict the "Seniority at Hiring" input to Belgian companies only. - Remove demo data and tour references related to study_school and private_car_plate. task-5420271
This update standardizes the appearance of progress bars across Odoo Enterprise, aligning with Bootstrap's design and adapting for dark mode. This simplifies the user interface and reduces the amount of code needed to maintain the progress bar style.
Original PR description
This commit implements a minor update to progress bars. Customized progress bars have been replaced with Bootstrap standard styles with some adapation for the dark mode. This change streamlines the visual consistency but also reduces the CSS footprint. Community PR: https://github.com/odoo/odoo/pull/151758 task-3605453
This update enhances the reliability of call management by allowing calls to be ended before they start, using client-side timestamps for greater accuracy and responsiveness. This eliminates a previous dependency on server response times, improving system stability and reducing potential delays. It also streamlines code maintenance and improves readability.
Original PR description
There are 2 commits in that PR: # [REF] voip(_ai): align Session and Registerer conventions Harmonize Session and Registerer to ease maintenance and readability: - Rename _sipSession to…
There are 2 commits in that PR: # [REF] voip(_ai): align Session and Registerer conventions Harmonize Session and Registerer to ease maintenance and readability: - Rename _sipSession to __sipJsSession in Session, matching the convention used in Registerer and UserAgent. - Unify the stateChange listener pattern across both classes. - Store isRegistered on the Registerer and trigger a bus notification on change, similarly to what is done in Session. # [IMP] voip: allow end_call before start_call with explicit timestamps Both start_call and end_call now accept an explicit `at` timestamp, captured on the client at event time. New state transitions (calling/missed → terminated) allow end_call to proceed independently of start_call, with placeholder logic to reconcile start_date and duration regardless of arrival order. This removes the need to wait for start_call's response before ending a call, improving system reliability in case the server becomes unreachable. Using client-side timestamps also improves the accuracy of start_date and duration, as they reflect the actual event times rather than when the server processed the requests. Preparatory work for task-4917399.
This update streamlines the user experience by changing how notification settings are accessed from the Discuss sidebar. Previously, settings opened in a dialog, now they open in a dropdown, creating a more consistent and user-friendly interface.
Original PR description
Before this PR, opening the notification settings from the thread action in the Discuss sidebar displayed them in a dialog, making the UI inconsistent with other thread actions. After this PR, the notification settings open in a dropdown instead of a dialog, ensuring a more consistent and streamlined user experience. community: https://github.com/odoo/odoo/pull/247352 task-5936685 Forward-Port-Of: odoo/enterprise#108523
This update simplifies account organization by replacing account groups with a parent account hierarchy. This change addresses previous limitations related to code ranges and reporting, offering a more flexible and user-friendly approach for financial reporting across different countries and business needs. It improves clarity and reduces complexity in how accounts are categorized.
Original PR description
Problems of account groups: 1. It's defined by code range. This means that it forces the use of codes and it creates the constraint that an account must be within a code range to be part of a group. This makes sense in countries like Belgium where there is a normalized plan, but this is a problem in countries where there is no normalized plan or in countries where the use of codes is optional (eg. USA). 2. It shows the code in front of the group in accounting reports (not always desirable). 3. It's difficult to discover. 4. It doesn't allow to use a group as an "intermediary account" in the hierarchy. (eg. using the account "Automobile" on a bill even though "Automobile" is a parent). 5. It doesn't display the CoA hierarchy. task-5055586
Resolved issues and error corrections
This update resolves a potential issue during database upgrades in the Odoo Enterprise payroll module. Previously, removing a payroll rule could cause upgrade scripts to fail. This fix ensures that upgrade scripts continue to function correctly even if a rule has been deleted, improving the reliability of database updates.
Original PR description
This method is used in various places, including when upgrading a database. When doing so, it is done in a post upgrade script. If later one of the updated rules is removed, the pre-script removing it will run before the post script trying to update it, causing the migration to fail as the update method tries to browse a falsy value. This updates the `update_properties_definition_domain` method so that it ignores falsy values when browsing, allowing previous upgrade scripts to run even if the referred rule has been since deleted. Forward-Port-Of: odoo/enterprise#102964
This update removes the 'amount' column from the worked days tab in payroll reports for the United Arab Emirates (AE) and Saudi Arabia (SA) localizations. This change aligns with local reporting requirements and simplifies the reports for users in these regions, improving clarity and accuracy.
Original PR description
The amount column should be removed from worked days tab for AE and SA localizations. task - 5111183
This update fixes a bug where deleting a partially signed offer would incorrectly delete the associated employee. The change ensures the employee is only deleted when the offer is archived and has no other active offers, preventing data inconsistencies. This improves data integrity and reduces the risk of lost employee records.
Original PR description
Version – saas-18.4 ### Issue: When an applicant has both a partially signed offer and a fully signed offer, deleting the partially signed one also deletes the employee that was created from the…
Version – saas-18.4 ### Issue: When an applicant has both a partially signed offer and a fully signed offer, deleting the partially signed one also deletes the employee that was created from the fully signed offer. ### Steps to Reproduce: - Create two offers for an applicant. - Fully sign the first offer and partially sign the second one. - Delete the partially signed offer. The employee created from the fully signed offer is also deleted. ### Cause: Due to this issue, the employee record is incorrectly deleted from the system, which is not expected behavior. ### Fix: Improved the employee deletion logic by deleting the employee only when: - the employee is archived, and - they do not have any other offers besides the one being deleted. ### Impact: The employee will no longer be deleted when another partially signed offer for the same applicant is removed. --- Task – 5347109 Forward-Port-Of: odoo/enterprise#108634 Forward-Port-Of: odoo/enterprise#100991
This update resolves an issue where the system incorrectly identified the currency of multiple journals with the same IBAN. The fix ensures that CODA transactions are now accurately routed to the correct journal based on its currency, improving financial accuracy and reducing potential errors in multi-currency accounting. This was a critical fix impacting financial reporting.
Original PR description
When having multiple journals with the same IBAN, but different currencies, upon fetching and dispatching the CODA into the right journals, the currency of the journal was not correctly taken into account as the condition was incorrect. This commit fixes this condition which was introduced in [^1] such that the right journal, with the right currency is correctly chosen. [^1]: 4fda4fb5353ed9c14dbc023ab7d07fabd3c06e98 opw-5723017 Forward-Port-Of: odoo/enterprise#108952 Forward-Port-Of: odoo/enterprise#108677
This update resolves an issue preventing the correct display of supplier names in SAF-T reports. The fix ensures that the system accurately identifies suppliers by incorporating depreciation lines alongside journal entries, addressing a discrepancy caused by bills posted in previous months.
Original PR description
**Steps to reproduce:** - Install l10n_ro_saft - Switch to a Romanian company (e.g. RO Company) - Create an asset model: * Method: Straight Line * Duration: 12 Months - Configure a "Fixed Assets"…
**Steps to reproduce:** - Install l10n_ro_saft - Switch to a Romanian company (e.g. RO Company) - Create an asset model: * Method: Straight Line * Duration: 12 Months - Configure a "Fixed Assets" account: * Automate Asset: Create and validate * Asset Model: [the asset model created above] - Create a bill: * Vendor: [create a new vendor] * Bill Date: [last month] * Invoice Line: [A line with the fixed asset account] - Confirm the bill - Go to "Accounting / Reporting / Audit Reports / General Ledger" - Select the current month (The fixed asset account should be present) - In the cog menu, select "SAF-T (D406 Asset Declaration)" **Issue:** A traceback is raised while trying to display the name of a supplier. **Cause:** To display the supplier name of an asset, a dict having the id of the customer or supplier as key (i.e. partner_detail_map) is used. This dict is build by getting the list of all partners linked to a posted journal item on an asset (or liability) account in the period of the report. In this case, it's the current month. However, the created bill has been posted the month before. So no journal item is found for the vendor that has been created just for the bill and therefore there is no key for him in the dict, which leads to the error when trying to get the id of the supplier of the asset in the dict. **Solution:** Instead of just fetching the posted entries linked to a receivable or payable account in order to get the list of the potential customers and suppliers, we also fetch the depreciation lines that are linked to an asset account and can still be in draft. opw-5499918 Forward-Port-Of: odoo/enterprise#109051 Forward-Port-Of: odoo/enterprise#105987
Features or functions removed from Odoo
This update simplifies the kitchen display by removing product reference information for restaurant and bar orders. This change streamlines the display for kitchen staff, improving efficiency. Product references will still be shown on the display for retail orders.
Original PR description
Following this commit: ==== - Product reference will no longer be shown in kitchen display for orders related to restaurant/bar config. - For retail config, we will continue showing product reference. task-5920462 Related PR : https://github.com/odoo/odoo/pull/248603
Code cleanup and technical improvements
This update standardizes how partner addresses are formatted across Odoo, eliminating duplicate formatting logic in various modules. By centralizing this process in the base, we ensure consistency and reduce potential errors in address data, improving data accuracy and reporting.
Original PR description
Before this commit: --- - Default address formatting could include unwanted blank lines when fields were empty. - Many modules/localization duplicated logic to get `clean` or `inline` address. In this commit: --- - Centralize address rendering logic in base to avoid duplicated formatting across modules. task-5455694
This update adds `.this` to template variables to align with upcoming OWL3 requirements. This change is a necessary preparation step to ensure compatibility with the new OWL3 rendering context, which will require this syntax for accessing component variables. It impacts several modules to ensure a smooth transition.
Original PR description
In preparation for OWL3, where template variables will need to use `.this` to target component variables, we add `.this` to template variables that are targetting the component.
Community PR: https://github.com/odoo/odoo/pull/250416
Script PR: odoo/odoo#247965
task: OWL3 prep - add this. to template variables
THIS_TARGETS = ["ai", "currency", "data", "digest", "delivery", "event", "fleet", "frontdesk", "gamification",
"google", "helpdesk"]1 change
Resolved issues and error corrections
This update resolves an issue where the legal name displayed in payroll reports was not accurately reflecting the employee's legal name as required by Swiss law. The fix ensures that the correct legal name is computed and presented, improving compliance and accuracy of payroll data. This change impacts the l10n_ch_hr_payroll module.
Original PR description
task-5979726 Forward-Port-Of: odoo/enterprise#109037
1 change
Resolved issues and error corrections
This update fixes a technical issue within the Odoo ‘pos_self_order’ module where commands were incorrectly used to update data instead of creating it. This change ensures that updates to self-order data are processed correctly, improving the reliability of the mobile ordering feature. It's a minor fix focused on internal module functionality.
Original PR description
Before this commit, all lines even updated one were using Command.CREATE instead of Command.UPDATE. This commit fix the issued.