Friday, April 17, 2026
29 changes · saas-19.1
Resolved issues and error corrections
This update corrects an issue where account searches on invoices only worked when searching by name, not by code. Now, account searches on invoices function correctly regardless of whether the user searches by name or code, ensuring accurate results. Additionally, a 'Search more...' option is always visible for Account searches.
Original PR description
Currently, on invoices, the account_id many2one field overrides `name_search` to limit search results based on account types, but that is applied only if the account is searched by name. If the account is searched by code, all the accounts appear in search results which is not intended. This commit fixes that issue. task-6075233 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257850
This update fixes an issue where custom snippets created in Website Edit Mode were only available as inner content. Now, snippets can be used both as blocks and inner content, aligning with previous versions. This improves flexibility for users creating website content.
Original PR description
Steps to reproduce: 1. Go to Website > Edit mode. 2. Drag and drop a `Map` from `Inner Content` snippets. 3. Save it as a custom snippet. Current behavior: - The custom snippet is saved only as inner content and does not appear as a block in custom snippets. Expected behavior: - The snippet should be available both as a block and as inner content, consistent with behavior in `saas-18.3`. Issue: - Custom inner content snippets were systematically extracted from `snippet_custom`. As a result, snippets that can serve both purposes were only kept as inner content, preventing their usage as blocks. Solution: - Update the logic to: 1. Keep dual-purpose snippets in `snippet_custom` (block usage). 2. Also add them to `snippet_custom_content` (inner content usage). 3. Remove only inner-only snippets from the block category to avoid display issues. task-6064917 Forward-Port-Of: odoo/odoo#259452 Forward-Port-Of: odoo/odoo#256777
This update fixes a bug that prevented users from using keyboard shortcuts (Tab, Enter, Shift+Tab) to select values within selection fields in list views. Previously, the system prioritized certain key presses, blocking the intended shortcut functionality. Now, users can seamlessly navigate and select values using their keyboard.
Original PR description
Steps: - Open any editable list view (for example sub-list view in sales) - Either it has a selection field or you add it via studio - With two values (for example "true" and "false") - Add a record to your list view - Try to edit the selection field - Popover is opened - You can select any value with a mouse click - You can navigate through values with arrows - You can't select values with `Enter` and `Tab` So list cell in edit mode has a function for all theses hotkeys: - `tab` - `shift+tab` - `enter` - `escape` Because `ListRenderer.onCellKeydown` is called before `hotkeyService.onKeyDown`, if any hotkeys is handled in cell edit mode it will be prevented and the hotkeyService will not propagate it to `select_menu`. That's why arrows are working, because there are not listed in cell edit mode keys. opw-6025476 Forward-Port-Of: odoo/odoo#255029
This update fixes an issue where users couldn't sort sale orders by delivery date. A recent change made the delivery date field un-sortable. This fix adds the 'promised delivery' date back to the list view, allowing users to sort sale orders effectively based on their promised delivery times.
Original PR description
Version: --- 19.1+ Issue: --- it's not possible to sort sale order list using `delivery date` anymore. After 30b895e3bd93ab3f0c0a86c3fcfd0fc0c3b6fb89, a `delivery_field` field is introduced, and `commitment_date`'s string is renamed to `promised delivery`. The new `delivery_date` is a compute field, hence it isn't sortable. The propostion here is to add `commitment_date` to the list view, in case users want to sort the list using `Promised delivery date`. opw-6112037
This update fixes a problem where the Point of Sale system was incorrectly trying to access printer settings. The fix ensures the system correctly identifies and uses available printers, preventing potential errors during sales transactions. This improves the reliability of the POS functionality.
Original PR description
We were looping over non existing `config.printer_ids`. It's either `config.receipt_printer_ids` or `config.preparation_printer_ids`. We now loop over a set containing values of both.
This update simplifies the process of reloading your chart of accounts. Previously, users received a confusing error message, but now a clear warning directs them to the necessary localization settings within the Odoo Apps menu. This change improves user experience and reduces potential frustration.
Original PR description
Previously, when new taxes with new tax tags were introduced, reloading the chart of accounts would raise a generic UserError suggesting to update the localization app. This could be confusing for users, as it did not indicate which app needed to be updated. With this commit, the UserError is replaced by a RedirectWarning that guides users directly to the Apps menu with the relevant localization modules, making the resolution clearer and more user-friendly. Forward-Port-Of: odoo/odoo#259539 Forward-Port-Of: odoo/odoo#257515
This update resolves issues preventing large actions (like printing receipts) from working correctly on the Windows IoT version of Odoo. Specifically, the Nginx configuration has been adjusted to handle larger file uploads and ensure compatibility with Virtual IoT environments, addressing previous LNA functionality problems.
Original PR description
Built installer for testing: https://drive.google.com/file/d/1wF7MCiQox3nAsW9CXg75wsV_Y5fF-5Rw/view?usp=sharing This commit makes the following changes that bring the Windows IoT nginx config in line with the Raspberry Pi version: - The `client_max_body_size` is set to 10MB. This prevents a 413 error from being received when sending large actions to the IoT (e.g. printing a large receipt). - It now listens on regular HTTP as well as HTTPS. This fixes LNA not working with Virtual IoT. opw-6106765, opw-6108700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259635
This update resolves a technical error that prevented users from selecting a store when the store's address information (city or street) was incomplete. The fix ensures the system correctly handles missing address details, improving the reliability of the Click and Collect feature. This prevents a frustrating user experience and ensures accurate store selection.
Original PR description
Issue: --- An owl error is raised in select store if the store's company location lacks city or street. Steps to reproduce: 1- Enable Click and Collect. 2- In pickup locations, set a company with an address with empty street or city. 3- Go to the shop. 4- Enable debug mode. 5- Select store. An owl error is raised due to not city and street not being string. opw-6050137 Forward-Port-Of: odoo/odoo#259397 Forward-Port-Of: odoo/odoo#259164
This update fixes an issue where offline orders were incorrectly having their payment dates automatically updated to the current date when brought into the POS. This ensures that the recorded payment date for saved orders remains accurate, improving the reliability of sales reporting and order management. This change was made to maintain data integrity.
Original PR description
Before this commit, saved orders that were captured offline, would have their payment_date overridden to the current date when they were loaded in the POS. opw-6117966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259114
This update resolves a technical problem where the website's cookie bar incorrectly persisted a value, leading to potential issues with website performance and error messages. The fix prevents the cookie bar from setting a default value when it's closed without user interaction, ensuring a smoother user experience.
Original PR description
Steps to reproduce: - Set the cookies bar - Do not accept nor reject it - On the website homepage, click on the search button => Check the cookies: website_cookies_bar=true is set. `Popup`…
Steps to reproduce: - Set the cookies bar - Do not accept nor reject it - On the website homepage, click on the search button => Check the cookies: website_cookies_bar=true is set. `Popup` initializes `cookieValue` to `true` and writes it in `onHideModal()`. If the cookies bar is closed before any explicit consent choice, it can therefore recreate the legacy invalid value `website_cookies_bar=true`. This happens because the search button uses `data-bs-toggle="modal"`, which is controlled by Bootstrap: if it is opened while another bootstrap modal is already open on the page, the latter is hidden. This in turn calls the popup interaction's `onHideModal()`, which sets `website_cookies_bar=true` as `cookieValue` hasn't been changed. That value is later treated as invalid and cleared repeatedly during website rendering, which can accumulate duplicate `Set-Cookie` headers in the same response and lead to `upstream sent too big header` behind nginx. Avoid persisting that legacy value by returning early from `CookiesBar.onHideModal()` while `cookieValue` is still the inherited default `true`. opw-6037573 Forward-Port-Of: odoo/odoo#258938
This update corrects a bug in the Point of Sale system's tax calculation process. Previously, when a fiscal position lacked tax information, an empty tax list was returned. This change ensures that tax calculations align with the underlying Python logic, improving accuracy and reliability of sales transactions. The fix addresses an internal issue identified in opw-6126210.
Original PR description
When a fiscal position has no tax_ids, the JS implementation was unconditionally returning an empty array. The Python map_tax method only removes all taxes when the taxes themselves carry fiscal_position_ids (the tax-units pattern); otherwise it passes the original taxes through. opw-6126210 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259555
This update fixes a problem where users without attendance officer or administrator permissions couldn't access overtime attendance records. The fix adds specific user groups to the 'Overtime Details' section, granting necessary read access and ensuring proper functionality for all users.
Original PR description
Steps to Reproduce: - Log in as user which has no access of attendance - Try to open attendance record with overtime Issue: - As users below attendance officer and hr administrator does not have access to rule_ids Fix: - Added groups on 'Overtime Details' section as other user does not have access to read. task-5886324 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue preventing users from adding TDS entries when working within branch companies in India. The fix corrects a currency access error caused by referencing the parent company instead of the branch company, ensuring proper access rights and functionality.
Original PR description
**Steps to reproduce:** * Install the **l10n_in** module. * Create a **branch company** under an Indian company. * Switch to the branch company only. * Create a user with **Accounting Administrator**…
**Steps to reproduce:** * Install the **l10n_in** module. * Create a **branch company** under an Indian company. * Switch to the branch company only. * Create a user with **Accounting Administrator** access (and bank validation rights) and also give permission of this branch company. * Login from this user . * Create and confirm a vendor bill in the branch company. * Click **TDS Entry** and select any TDS section. **Observed behavior:** * An **AccessError** is raised when selecting the TDS section. **Cause:** * In `_compute_amount` (wizard), currency is taken from `tax_id.company_id`. * For branch setups, taxes (and related accounts) belong to the **parent company**, so `tax_id.company_id` points to the parent. * The user operating in the branch company does not have access to the parent company, triggering an access error. **Fix:** * Use the wizard’s `company_id` instead of `tax_id.company_id` when determining currency. * The wizard `company_id` is correctly computed based on the active company, ensuring proper access rights. **Note:** * Regression test is not feasible due to ORM cache behavior: * In tests, `mock` environments share a transaction-level cache. * `compute_sudo=True` fields populate cache with superuser access. * By the time `_compute_amount` runs, values are already cached. * No database fetch occurs, so record rules are not evaluated and the AccessError cannot be reproduced. opw-6095312 Forward-Port-Of: odoo/odoo#259091
This update fixes a potential issue where Odoo would attempt to run a monitoring function during the Python interpreter's shutdown process. The interpreter clears resources, and this function would try to access data that no longer exists, causing an error. This change ensures the monitoring function doesn't run at shutdown, improving stability.
Original PR description
Odoo registers a callback function to track how much time is spent in garbage collection. But while the Python interpreter is shutting down and clearing out global modules and variables to free up memory and the Garbage Collector triggers one last time, the callback function `_timing_gc_callback` tries to run, but the function it depends on (like time.thread_time_ns) have already been set to None by the interpreter. Forward-Port-Of: odoo/odoo#259328
This update fixes an issue where images were repeatedly reloaded every time a user navigated between views in the employee management system. The fix prevents unnecessary image retrieval by caching images when they relate to different records. This results in faster page loading and a smoother user experience.
Original PR description
Steps to reproduce ================== - Login as Demo - Go to Employees - Open a record - Go back to the kanban view -> Every image is retrieved again Cause of the issue ================== When loading an image, we add a unique parameter with the write_date of the record. We cannot use that for images on another record. Since we have no way of knowing when the image was changed, we used the timestamp when instanciating the ImageField. The downside is that every time we navigate to a view, every image is reloaded Solution ======== When the image is on another model, we don't pass the unique parameter. This means the image will be cached. A page refresh will be needed if the image has been updated in the current browsing session. opw-6070176 Forward-Port-Of: odoo/odoo#258943
This update fixes a recent issue where generated PDF invoices from Peppol invoices were displaying company information incorrectly. The change reverses the order of the issuer and receiver addresses, presenting a cleaner and more standard layout. This ensures invoices are clearly identified as originating from Odoo and improves readability.
Original PR description
When an invoice is received through Peppol, it may not contain an embed PDF. If no, we create one. However, due to several complaints, this commit exchange the place of the issuer and receiver addresses and information. Company information were rendered in the header of the document through the external_layout. Switching to the internal layer avoid doing so. opw-5980655 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259578 Forward-Port-Of: odoo/odoo#254693
This update fixes an issue where the order report incorrectly showed a zero amount in the "Down Payments" section header. The change ensures that this section header displays correctly, providing a cleaner and more accurate report for customers and internal teams. This improves the clarity and professionalism of sales reports.
Original PR description
When creating an order with a down payment, the printed order report incorrectly shows a zero amount on the “Down Payments” line. This line acts as a section header and should not display any amount. opw-5446875 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242833
This update corrects a bug in the Timesheet Assistant that caused incorrect project suggestions when using aw.rules without associated tasks. The fix ensures that suggestions accurately reflect the project defined in the rule, improving the assistant's usability and data accuracy. This resolves a potential issue where users wouldn't see relevant project suggestions.
Original PR description
Steps to Reproduce --- - Define an aw.rule with a project set without a task (false) - The rule regex matches a desktop app event (e.g. Discord window) - Open the Timesheets Assistant for the current…
Steps to Reproduce --- - Define an aw.rule with a project set without a task (false) - The rule regex matches a desktop app event (e.g. Discord window) - Open the Timesheets Assistant for the current day Current Behavior --- - The matched event has _res_model set to "project.task" and _res_id set to undefined, despite no task being configured on the rule - The suggestion appears as "Unmatched" in the assistant even though a project was correctly defined on the rule Expected Behavior --- - The matched event should have _res_model set to "project.project" and _res_id set to the rule's project_id - The suggestion should appear under the configured project Issue --- - In extractWatcherActivity(), both project_id and task_id blocks used != null as the guard condition - When task_id is false, false[0] is undefined, overwriting the correctly set _res_model i.e. "project.project" and _res_id from the project_id block with "project.task" and undefined _res_id Fix --- - Replace with a truthy check task - 6089410
This update resolves an issue where tests were failing due to lingering data from previous attempts. The fix ensures each test run starts with a clean slate, preventing errors and improving overall test reliability. This change enhances the stability of the Odoo testing framework.
Original PR description
The autoretry don't recreate the test instance meaning that some pollution can remain there breaking the next test with a strange error. This pr recreates the test instance for each retry to avoid this kind of issue, and move the retry mechanism to the suite level. The core part of the fix is `test = test.__class__(test._testMethodName) # re-create the test to reset its state` While on it, moving the retry mechanism in the test suite since it makes more sense and allow a better control on what is retried or not since we don't rely on inheritance, and avoid dirty code with super(test) call to recreate the instance and execute it again. The tests needs to be adapted since the retry attribute is now in the loop, but we can have a quite reliable way to know if we are in a retry or not using inspect. Forward-Port-Of: odoo/odoo#258833
This update fixes an issue with invoice rounding related to down payments. The system now correctly uses specific currency values to ensure the total invoice amount matches expected calculations, particularly when a down payment is involved. This improves the accuracy of financial reporting.
Original PR description
'total_excluded_currency' is for the base amount. 'base_amount_currency' should be used only when getting the base per tax. When dealing with a down payment, a distortion in the taxes amounts might be introduced to ensure the total of the invoice is exactly the expected one. opw-6060486 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259426
This update resolves an issue where dropdowns within knowledge articles weren't closing properly when clicking outside the embedded view. The fix adjusts the way the system detects clicks, ensuring dropdowns close as expected. This improves the user experience when working with knowledge articles.
Original PR description
Steps to reproduce: - Go to knowledge - Type "/view" in the article -> add a list view - Open a dropdown in that list view (e.g. the cog icon next to "New") - Click outside the list view (e.g. first…
Steps to reproduce: - Go to knowledge - Type "/view" in the article -> add a list view - Open a dropdown in that list view (e.g. the cog icon next to "New") - Click outside the list view (e.g. first paragraph of the knowledge article that contains the list view) => The dropdown does not close Commit [1] removed the `activeEl` param of `popoverCloseOnClickAway`, and inverted the need for the knowledge patch added at [2] (before, it was needed to be able to close dropdowns by clicking inside knowledge embedded views, it is now needed to be able to close them by clicking outside the embedded views). In 19.2, this patch could be removed entirely as [3] made a generic solution for this to work (it will probably be done once this reaches master though). [1]: https://github.com/odoo/odoo/commit/1fb00045c6826ee7c8a7581ff4ab9b3eb2e83478 [2]: https://github.com/odoo/enterprise/commit/97c600ca35ae0513860467e572d587b977617d36 [3]: https://github.com/odoo/odoo/commit/48be3442b2b022c18d9e5d4fc8b9631563094d8e Forward-Port-Of: odoo/enterprise#114082
This update corrects an issue where negative numbers in accounting reports (like customer statements) were split across lines, making them difficult to read. The fix ensures that negative numbers are displayed as a single line, maintaining proper formatting and clarity in printed reports. This improves the user experience when reviewing financial data.
Original PR description
When printing accounting reports such as customer statements, a negative number may be split across two lines, leaving the minus sign on the first line and the amount on the second. Steps to reproduce: - Make an invoice for [Partner] with a total of 10.0 - Make another invoice for [Partner] with a total of 100.0 - Create a credit note for this last invoice - Open the customer statement report for [Partner] - Print PDF Issue: The first line of the partner section has fewer digits than the amounts of the subsequent journal items. On pdf, the column width is based on the smaller line, causing the longer negative strings to wrap and separate the minus sign from the amount. opw-5951300 Forward-Port-Of: odoo/enterprise#113727
This update resolves an issue where POS users with limited access rights were unable to fully close sessions when using the Fiskaly integration in Germany. The fix removes unnecessary security checks, allowing users to complete the closing process without requiring administrator privileges. This ensures a smoother user experience for POS operations.
Original PR description
In German location with Fiskaly setup. POS users hit an AccessError on read when closing the session from the frontend, then had to finish closing in the backend with admin (base.group_erp_manager)…
In German location with Fiskaly setup. POS users hit an AccessError on read when closing the session from the frontend, then had to finish closing in the backend with admin (base.group_erp_manager) rights. Steps to reproduce: ------------------- * Enable Germany + Fiskaly POS (l10n_de_pos_cert), with a company registered for Fiskaly * Use a user with POS rights only (no Access Rights) * Open POS, sell, then close the session from the POS UI > Observation: A warning redirects to the back end; manual close shows: insufficient rights to read l10n_de_fiskaly_api_secret on res.company (operation read). Why the fix: ------------ The guard only needs to know whether the company is in the Germany + Fiskaly flow; that is already expressed by l10n_de_is_germany_and_fiskaly(), without reading API credentials. Fiskaly RPC helpers on res.company continue to use sudo() where secrets are required; this change fixes unnecessary reads of protected fields in the tax helper, not the security model of the credentials themselves. opw-6074960 Forward-Port-Of: odoo/enterprise#113714 Forward-Port-Of: odoo/enterprise#112618
This update resolves an issue where the 'Create a Payslip' button was unresponsive when no payslips existed in the W2 report. The fix corrects a technical error in the system's code that prevented the button from functioning properly. This ensures users can consistently generate W2 reports.
Original PR description
1.Install l10n_us_hr_payroll 2 Navigate to Payroll>Reporting>W2 Report. 3.Open/Create W2 form and try to add payslip by clicking "Add a line". 4."Create a payslip" button appears if their are no valid payslips. 5.Click it, it won't work! Root cause: - `onAdd` bind was missing in the controller - Renderer applied an additional `.bind(...)`, breaking the callback Fix: - Pass a dedicated `createNewPayslip` action from controller - Remove double binding in renderer - Forward callback directly to helper component task-[5928770](https://www.odoo.com/odoo/project/1251/tasks/5928770) Forward-Port-Of: odoo/enterprise#113994 Forward-Port-Of: odoo/enterprise#111735
A technical issue causing negative values in the Luxembourg tax report's calculations has been resolved. The formula was incorrectly referencing a negative value, leading to inaccurate reporting. This update corrects the calculation, ensuring the tax report displays the correct credited amounts for Luxembourg companies.
Original PR description
Steps to reproduce: - Install `l10n_lu` module - Switch to `LU Company` - Create a invoice and in journal items use tax grid `226` - Open the Tax Report and check the line `226 - Supplies carried out within the scope of the special arrangement of art. 56sexies` - The value appears negative instead of positive. Cause: This issue is caused by the major tax revamp introduced in version 19 [commit]. The credited amount is currently displayed as a negative value, which is incorrect, it should be shown as positive. Solution: To resolve this issue, the formula has been modified from `226` to `-226`. [commit]: https://github.com/odoo/odoo/commit/17a6117ed88c29b5bc4db0c872bcdbc109a7d98b#diff-3441c5d05315ec0562923797f973eae66488452a6772d23e198998c1890aa06c opw-6050665 Forward-Port-Of: odoo/enterprise#113952
This update resolves an issue where the system incorrectly processed DTE XML files from the fetchmail server when a specific LATAM accounting setting wasn't enabled. The fix ensures the correct journal ID is used, preventing errors and allowing proper account move calculations. This improves the reliability of importing invoices from Chile.
Original PR description
Currently, when receiving a DTE XML fetched by the fetchmail server, if there is no purchase journal with `l10n_latam_use_documents` enabled, an empty recordset (account.journal()) is set in the default context values. This prevents the proper computation of the field and raises an error, since the `journal_id` is mandatory on account moves. Steps to reproduce: - Ensure you have no purchase journal with `l10n_latam_use_documents` enabled - Simulate the reception of a DTE XML via the fetchmail server - Observe the error: "NotNullViolation: null value in column 'journal_id'" opw-5950116 opw-6111041 Forward-Port-Of: odoo/enterprise#112168
This update resolves an issue where database synchronization would fail when a user's access was removed. Now, the synchronization process completes gracefully, ensuring data consistency even if user access is no longer valid. This enhances the stability of our SaaS offering.
Original PR description
The aim of this commit is to allow a db_user to synchronize a database without facing a Traceback. Context: - A new document has been received by a remote db and we try to synchronize it. - The current user access has been removed from the remote db. - The database is unreachable. Before this commit: In all 3 previous cases, an access error would be raised because a db_user can't write on a database. After this commit: The synchronization finish gracefully and the db_user should have lost his access if it was removed from the remote db. task-id: 6046087 Forward-Port-Of: odoo/enterprise#113826
This update fixes a bug that prevented users from saving appointments when removing the organizer. The issue stemmed from a mismatch in data expectations within the Google Calendar integration. By adjusting the code, the system now correctly handles appointments without a designated organizer, ensuring smooth appointment creation.
Original PR description
Currently an error is generated when the user tries to save an appointment as follows: - Install the appointment_google_calendar module without demo data - Create a new appointment as below: - Remove…
Currently an error is generated when the user tries to save an
appointment as follows:
- Install the appointment_google_calendar module without demo data
- Create a new appointment as below:
- Remove Organizer (user_id)
- Set the Google Meet link inside VideocallURL, e.g., https://meet.google.com/aaa-aaa-aaa
- An error occurs in the log and a message is shown to the user when save the record
- Also, an error occurs when trying to preview `Appointment: Attendee Invitation`
after creating appointment as follows:
- Set the Google Meet link inside Videocall URL > save
- Remove Organizer (user_id)
Error:
```
test odoo.addons.mail.models.mail_render_mixin: Failed to render QWeb template for Mail Template: 'Appointment: Appointment Booked' (ID: 12) - Context language:en_US
Target Model: calendar.event
Error: Error while render the template
ValueError: Expected singleton: res.users()
```
This is because the method `is_google_calendar_synced` expected a single
record, but since we removed `user_id` from the event (appointment),
it will generate a singleton error.
This commit will fix the above issue by not calling `is_google_calendar_synced`
when the event does not have `user_id`.
sentry-7393595716
Forward-Port-Of: odoo/enterprise#113966This update fixes a reporting issue on the Swiss Balance Sheet by changing the date range used to calculate 'Current Year Retained Earnings'. Previously, the report used a broad date range, leading to inaccurate figures. This change ensures the report accurately reflects retained earnings within the current fiscal year.
Original PR description
The "Current Year Retained Earnings" (CH_299_A) line on the Swiss Balance Sheet was using the default `strict_range` date scope. This commit forces the `date_scope` to `from_fiscalyear`. task-6119493 Forward-Port-Of: odoo/enterprise#113920