Daily updates from Odoo
Friday, April 3, 2026
32 changes · 18.0
New functionality added to Odoo
This update introduces a new module for Romania, specifically designed to generate the required 'On Demand' XML file for SAFT reporting. This file contains inventory valuation data, which is a mandatory submission to the Romanian tax authority (ANAF) as part of their digitalized reporting process. This addition ensures compliance with Romanian regulations.
Original PR description
Baiscally the SAFT for Romania consists of 3 xml files to submit. This commit focuses on the "On Demand" xml to submit, consisting in the inventory valuation of of the company. File with fields and value to export can be found here: https://www.anaf.ro/anaf/internet/ANAF/despre_anaf/strategii_anaf/proiecte_digitalizare/saf_t/ task-3748978
This update adds support for Peppol Business Level Responses (BLR) to invoices and credit notes, ensuring compliance with European standards for electronic invoicing. It introduces new response types – acknowledgement, confirmation, and rejection – required for Peppol participants to correctly process documents. This improves Odoo's integration with Peppol and supports international trade.
Original PR description
Peppol offers a response system to the document received through it. These are called Business Level Responses, and their documentation can be found here:…
Peppol offers a response system to the document received through it. These are called Business Level Responses, and their documentation can be found here: https://docs.peppol.eu/poacc/upgrade-3/profiles/63-invoiceresponse/#introduction-to-openpeppol-and-bis The specific BLR implemented in this commit is targeted to invoices and credit notes. 3 types of responses are mandatory for a Peppol participant to correctly adhere to the BLR service: acknowledgement (different to the transport ack), confirmation and rejection. More response's types are available but were not implemented as they're not mandatory/needed (for now). For rejection, a list of at least one reason must be given, and actions can be suggested to the sender of the document for the eventual next invoice shipment. Same principle goes for Nemhandel, with some differences: only 2 responses, BusinessAccept and BusinessReject (no Acknowledgement, and no reasons are needed in case of rejection. Instead, the user can send a string message. iap PR: https://github.com/odoo/iap-apps/pull/1364 task-5237698
Resolved issues and error corrections
This update resolves an issue where the POS IoT system wasn't functioning correctly with scales. The change removes a redundant check that prevented the scale service from working when the hardware proxy was unavailable, ensuring seamless operation with the new IoT image.
Original PR description
The new IoT image removes the `hw_proxy/status_json` endpoint, which results in the hardware proxy service thinking there are no devices connected to the IoT. We now remove this check from the scale service so that the new image works correctly with a scale.
This update fixes an issue where subscriptions could be automatically reopened after being manually closed by a salesperson. This prevented confusion and potential errors related to subscription status. The change ensures subscriptions remain closed when manually closed, streamlining the sales process.
Original PR description
Before this commit, when a subscription was closed manually by the salesperson, it could be reopened when a transaction was approved or an invoice paid. It could cause issue. In this case, we should not reopen automatically. task-5900481
This update fixes a layout issue in the Italian Libro Giornale PDF report. When accounts with long names are used, the report's formatting was broken, causing excessive column expansion and poor readability. The change adds a CSS class to handle long account names, resulting in a cleaner and more professional-looking report.
Original PR description
When generating the Libro Giornale (IT) PDF report with an account that has a very long name, the column expands excessively and break the layout. Steps to reproduce: - With an IT company setup - Have an account with a very long name - Create an invoice using the account - Open Accounting / Reporting / Audit Reports / Journal Audit - Select variant "Libro Giornale (IT)" - Print PDF Issue: The long account name makes the column excessively large. As a result, the font shrinks to fit the page width, leaving wide gaps between lines. **before patch** <img width="794" height="493" alt="screenshot_047" src="https://github.com/user-attachments/assets/6faa5b57-9c60-41cb-9200-003a50019180" /> **after patch** <img width="793" height="553" alt="screenshot_046" src="https://github.com/user-attachments/assets/e97c8948-410b-4201-83c3-04173220d9ce" /> opw-5457103
This update fixes an issue on mobile devices where the buttons within the transfer chatter view were too small, causing text to overflow and making the interface difficult to use. The change ensures that buttons are properly sized for mobile screens, improving the user experience when managing transfers. This resolves a reported usability problem.
Original PR description
Partial backport of d16480179ed73f25e0465e42c6fdef64e4fdc502 Steps to reproduce ================== - Navigate to Barcode, click on any transfer - Click on the name of the transfer in the header to open the form view - Scroll down to the chatter, the buttons are too small to contain the text, and much of the text flows over to other UI elements Cause of the issue ================== The barcode style override every buttons including the ones inside the chatter opw-6082959
This update ensures that Odoo's payroll calculations for Belgian employees accurately reflect the latest regulations regarding employment bonuses, as outlined by Partena Professional. The changes, effective April 1, 2026, correct a previous discrepancy in bonus amounts, ensuring accurate reporting and compliance.
Original PR description
https://www.partena-professional.be/fr/le-bonus-lemploi-au-1er-avril-2026?utm_source=sfmc&utm_medium=email&utm_campaign=InfoFlash+Daily+Mail+-+FR&utm_content=article-read-more-cta&utm_term=All%20Subscribers&utm_id=81873&sfmcContactKey=litom@odoo.com
This update resolves an issue where the LPP (Labor Pension Plan) was incorrectly applied to employee salaries in the Swiss payroll module when employees were not covered by insurance. The fix ensures that LPP contributions are only applied to insured employees, aligning with Swiss tax regulations and improving payroll accuracy.
Original PR description
Forward-Port-Of: odoo/enterprise#112824
This update enhances the process of importing invoices from UBL documents, addressing previous issues with data synchronization. Specifically, it adds a `partner` domain to the move line query builder, allowing for more accurate matching of invoices to related transactions. This improves the reliability of invoice import and reduces potential data discrepancies.
Original PR description
This commit is part of a bigger commit on the community side- to refactor the import code of BIS3 Invoice to fix various unsynchronized values issues. task-id: 5058687
This update fixes a display issue in the Danish balance sheet and profit & loss reports. It simplifies the report format and ensures accurate reporting by aligning with Danish accounting standards and translations. The fix addresses a bug related to hidden account lines, ensuring all financial data is correctly presented.
Original PR description
We updated the Danish balance sheet and profit and loss reports to reflect the changes in the Danish chart of accounts and common practice in Danish accounting. We also simplified the reports to use the accounts themselves as sublines instead of having a separate report line for each account. Finally we made sure we use the official Danish translations and updated the English translations as well. task-5929517 Related: https://github.com/odoo/odoo/pull/256541 Forward-Port-Of: odoo/enterprise#112430
This update fixes an issue preventing users from inserting snippets within forum help pages. The solution allows clicking on snippet groups within existing snippets, ensuring a smoother and more reliable snippet insertion experience. This improves usability and prevents a frustrating user experience.
Original PR description
Steps to reproduce the issue: - Go to Forum, then go to the Help page - Enter Edit mode - Try to drag and drop a snippet => The dropzone in the s_cover at the top of the page are available - Try to click on a snippet group => Nothing happen, because all dropzones are filtered The s_cover element has the [data-snippet] attribute. When clicking on a snippet group, the editor filters out dropzones inside other snippets. Since s_cover is treated as a snippet, its dropzones are excluded, even though they are the only ones available on the page. The solution is to treat dropzones inside snippets as low priority instead of strictly forbidden. If no other valid dropzones exist, we allow these as a fallback to ensure snippet insertion remains possible. task-5938138
This update resolves an issue where changing products within the product configurator dialog caused the Sale Order (SOL) to revert to its original state when switching browser tabs. The fix ensures that changes made through the dialog are correctly saved, preventing data loss and improving the user experience when using product configurations. This impacts users creating and modifying sales orders.
Original PR description
## Versions 18.0+ ## Issue When the product configurator dialog is open, a browser tab change acts like a discard on the SOL: coming back to the Odoo tab displays the dialog but the SOL has been…
## Versions
18.0+
## Issue
When the product configurator dialog is open, a browser tab change acts like a discard on the SOL: coming back to the Odoo tab displays the dialog but the SOL has been reverted to its previous state.
## Steps to reproduce
- Create a new SO for any customer:
- Add a standard (non-combo/non-variant) product (e.g. "Apple Pie");
- Save manually;
- Change the product for a combo or variant one (e.g. "Customizable Desk");
- With the opened dialog, change from browser tab then come back;
- The SOL has been reset to the standard product ("Apple Pie") and confirming the dialog has no effect).
## Cause
The `beforeVisibilityChange` hook is triggered by the tab change and saves the form without updated values. This is because the hook checks for two conditions to be true: https://github.com/odoo/odoo/blob/2f00b0085574653ca1a8f734ef91893a4a1c1a7c/addons/web/static/src/views/form/form_controller.js#L479-L483 The tab change indeed changes the document's visibility to "hidden" but the controller has never been updated with the form's display in the dialog and, therefore, `this.formInDialog` is indeed equal to zero.
## Test
No test as we cannot simulate a browser tab change then come back to the first tab.
opw-5494089This update prevents issues during demo data installation for the Romanian EDI stock module. Specifically, it allows carrier validation to run without blocking the installation process. Additionally, the update includes a default stock valuation account for Romanian companies, streamlining setup.
Original PR description
This commit ensures that stock picking carrier validation for Romanian EDI does not block demo data installation. task-3748978 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where POS orders created in Jordan without the l10n_jo_edi_pos module lacked a required UUID. This prevented successful submission to JoFotara. The fix automatically generates a UUID when the order is created, ensuring compliance and preventing submission errors.
Original PR description
Currently, POS orders in Jordan do not have a UUID if they were created before installing the module. This causes submission failures to JoFotara. Steps to reproduce: - Create a POS order in Jordan without the module l10n_jo_edi_pos installed - Install l10n_jo_edi_pos - Try to submit the order to JoFotara, it fails due to missing UUID with the error "Invoice UUID is required" This fix force a computation of the order UUID when we add the header node, to ensure that this will not cause submission failures to JoFotara. opw-6041688
This update fixes a reporting issue in Point of Sale orders using different currencies. Previously, the margin calculation didn't account for the currency conversion, leading to inaccurate reports. Now, the margin is correctly calculated and displayed in the order's currency, ensuring accurate financial reporting.
Original PR description
When making a pos order in a PoS that uses a different currency, the margin in the pos order report would not take the currency into account Steps to reproduce: ------------------- * Create a product with a price of 100€ and cost 0€ (margin = 100€) * Setup a PoS to use a different currency with a rate of 2 (so 1€=>0.5) * Create a PoS order for this product and validate it * Go to the pos order report and select the order you just made > Observation: The value of the margin is 200 expressed in the different currency, when the rest of the report is using the company currency. Why the fix: ------------ The currency was only applied on the product cost, we now apply it on the whole margin. opw-5927473
This update fixes an issue where session reports for point-of-sale (PoS) orders with decimal quantities displayed excessive decimal places. The fix ensures that totals by category and price are rounded to the standard two decimal places, providing more accurate reporting. This improves the reliability of sales data.
Original PR description
When selling a lot of product with different quantities (quantities with decimals) the session report total by category might have a lot of decimals instead of 2. Steps to reproduce: ------------------- * Open PoS * Make an order with a lot of product and modify the quantities to have random values with decimals * Close the session * Generate the session report > Observation: The total qty by category has a lot of decimals instead of the 2 expected. The same error also happens for the total price Why the fix: ------------ We round each value with their respective precision to make sure we don't have 15 decimals. opw-6039016
This update fixes a potential problem where errors during file uploads could lead to orphaned files consuming disk space and preventing new uploads. The change ensures files are properly cleaned up after write errors, preventing conflicts and maintaining system performance. This resolves a previous issue reported by our support team.
Original PR description
If an error occurs during the file write operation, the file will not be marked for garbage collection, which can lead to orphaned files taking up disk space or blocking other same file to be written. Step to reproduce the issue: 1. Create an attachment with a large file (e.g., 100MB) and save 2. During the file write operation, simulate an IOError (e.g., by filling up the disk space or changing file permissions) 3. The file will not be marked for garbage collection, and it will remain 4. Further attempts to create this same attachment will result in error: "The attachment collides with an existing file." opw-6055037 opw-5907025 Forward-Port-Of: odoo/odoo#257274
This update resolves an issue where the point-of-sale system was incorrectly blocking scale operations when the hardware proxy wasn't connected. The change removes a redundant check in the scale service, ensuring the new IoT image functions correctly with scales. This improves the overall reliability of the point-of-sale experience.
Original PR description
The new IoT image removes the `hw_proxy/status_json` endpoint, which results in the hardware proxy service thinking there are no devices connected to the IoT. We now remove this check from the scale service so that the new image works correctly with a scale. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the event ticket download button wasn't appearing for online payments in the POS system. The fix ensures that necessary data is always set, regardless of the order's status, allowing the download button to function correctly for all payment methods. This improves the user experience for event ticket purchases.
Original PR description
**Steps to reproduce:** - Set up an event, go put it's state to Annonced - Set up any online payment method (Demo also triggers the bug) - Go to a PoS that sells the event tickets - Purchase one and…
**Steps to reproduce:** - Set up an event, go put it's state to Annonced - Set up any online payment method (Demo also triggers the bug) - Go to a PoS that sells the event tickets - Purchase one and pay with the online payment method - Once on the ticket screen, the button to download the event tickets is not displayed **Why the fix:** The normal flow only works for offline payment methods, because we check if the ordered is either paid or invoiced before setting all the values needed by the frontend regarding the ticket registration. The problem is that with an online payment method, once we enter the **read_pos_data** method that sets the values for the frontend, the order is still in draft, so we just return without doing anything. We now set the values regardless of the order's status and send the confirmation mail in the same way as if it was an online payment. In the case of an online payment, the mail will be sent by the **action_pos_order_paid** function that is called once the payment is processed. A test might be a bit weird to make as we don't have a bridge for pos_online_payment and pos_event, and that we would need to mock the server's answer to be able to pay for the online payment and check that we have the needed values. So the setup for pos_event would have to be copied into pos_online_payment to test it and it would only be ran if both modules are installed. opw-5438432
This update reduces log clutter when QWeb templates fail to render, making it easier for support teams to diagnose issues. The fix automatically identifies failing templates and displays a concise snippet in logs and error messages, while still providing full source logging if needed. This improves system stability and support efficiency.
Original PR description
This is mainly a backport of an IMP done at https://github.com/odoo/odoo/pull/252455 Given it's potential to reduce server bloat and increase of QOL for sys admins and support agents, backporting (a…
This is mainly a backport of an IMP done at https://github.com/odoo/odoo/pull/252455 Given it's potential to reduce server bloat and increase of QOL for sys admins and support agents, backporting (a sligthly modified version) seemed adequate. Summary: When a QWeb template fails to render, the current logic logs the entire template source and raises a generic UserError. This leads to significant log bloat and makes it difficult for developers and support staff to identify the specific failing template or the root cause of the error. This commit improves the error handling in `mail.render.mixin` and `mail.template` by: - mail.render.mixin: Added logic to identify the failing template's name and ID if it belongs to a `mail.template` or `mail.compose.message` (mass mailing). - Log Truncation: Implemented truncation for identified templates, showing only a snippet (first and last 500 chars) in logs and UserErrors to prevent log/UI bloat while keeping full source logging as a fallback for unidentified templates. OPW-5980295 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257104
This update fixes an issue where the toolbar in the HTML editor wasn't correctly positioned when selecting columns within a table. Now, the toolbar appears accurately above the selected cells, ensuring a smoother and more intuitive user experience when editing tables. This improves usability and data entry accuracy.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Create a 3 x 3 table. - Select 3rd column and wait for toolbar. Currently, the toolbar is positioned at the start of the table even when the last column is selected. This happens because selecting cells in the 3rd column creates a DOM selection range that starts at the first cell and ends at the last cell of the column, traversing all intermediate elements. As a result, browser's range rectangle does not match the actual custom-selection rect. **Desired behavior after PR is merged:** Now, Toolbar is positioned correctly above the custom selected cells. task-5935587 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a bug that prevented textareas within the HTML editor from correctly receiving focus. The change backports a fix originally developed for Odoo's 19.0 release, ensuring proper functionality for users interacting with text areas in the editor. This improves the overall usability of the HTML editor.
Original PR description
Before this commit: in #253638 we override the focus function of the editable to focusEditable. A patch for textarea and resetting the focus function at destroy is introduced at the forward port 19.0. After this commit: we backport the patch from c9c2325a966db5abf61810000234042f45ef1728 task-6034339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update reorganizes a key test within the Odoo system. The test, previously located in the base module, has been moved to a dedicated testing utilities module. This improves the structure and maintainability of our tests, ensuring they are organized alongside related development efforts.
Original PR description
Move the test to test_testing_utilities where the model res.config.test is defined. Move test introduced in odoo/odoo#257033. runbot-242309 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves issues where URLs were incorrectly converted after inserting spaces or pasting URLs with backticks. Specifically, the undo functionality was flawed, and backticks were inadvertently included in pasted URLs. The changes improve the reliability and accuracy of URL handling within the HTML editor, ensuring a smoother user experience.
Original PR description
[FIX] html_editor: undo link autoconvert before space insertion When adding a space after an URL, the URL text is converted to an URL. When pressing undo, first the space is undone, then the link is…
[FIX] html_editor: undo link autoconvert before space insertion When adding a space after an URL, the URL text is converted to an URL. When pressing undo, first the space is undone, then the link is undone. This is wrong because if the user did not want a link, after undoing the link, inserting a new space will again convert to a link. This commit splits `handleAutomaticLinkInsertion` into two parts: determining if a link must be created, and actually inserting the link. This makes it possible to execute code within the condition before and after the insertion. To fix the similar behavior for enter and shift-enter, another before input handler is also added in order to let the default before input be executed before creating the link. Steps to reproduce: - Go to a "To do" note - Type "odoo.com" - Press space/enter/shift-enter - Undo a single time => The insertion was undone instead of the link transform. task-5936310 [FIX] html_editor: not include surrounding backtick in pasted URL When pasting an URL surrounded by backticks, the ending backtick is included inside the link's HREF. This commit fixes the regex for URL to also exclude backticks (like it did with `"` and `'`). Steps to reproduce: - Copy the following text in the clipboard: ``` `odoo.com` ``` - Go to a "To do" note - Paste => The link's URL was ``` odoo.com` ``` task-5936310
This update fixes an issue where newly created IAP account balances would reset to zero immediately after saving the record. Now, the balance accurately reflects the selected service and remains correct after saving, improving the user experience.
Original PR description
Before this commit: When creating an `iap.account`, selecting a service(`service_id`) showed the correct balance. However, as soon as the record was saved, the balance would reset to 0, and users had to refresh the page to see the real value. With this fix, the balance now stays accurate after saving the record. Task [link](https://www.odoo.com/odoo/project.task/6004546) task-6004546
This update fixes an issue where draft stock moves were incorrectly flagged as unavailable, even when sufficient stock existed. The change adjusts how availability is calculated to accurately reflect available quantities, ensuring accurate forecasts and preventing fulfillment delays. This improves the reliability of stock management.
Original PR description
Steps to reproduce: - Create a storable product "P1" - Update on-hand quantity to 2 units - Create a delivery with 2 units of P1 and keep it in draft state Problem: The forecast availability is…
Steps to reproduce: - Create a storable product "P1" - Update on-hand quantity to 2 units - Create a delivery with 2 units of P1 and keep it in draft state Problem: The forecast availability is displayed in red (not available), even though the stock is sufficient to fulfill the move. Explication: For draft consuming moves, the forecast availability is computed as: `virtual_available - move.product_qty` In the case where stock exactly matches the demand, this results in 0. However, on the JS side, availability is evaluated with: `forecast_availability >= product_qty` So with forecast_availability = 0 and product_qty = 2, the condition evaluates to False, incorrectly marking the move as not available. https://github.com/odoo/odoo/blob/c7fede7f44c668ccc0a094d8341c3cae8879a7f1/addons/stock/static/src/widgets/forecast_widget.js#L31 Solution: When the available quantity is sufficient to cover the move (using float_compare), set forecast_availability to the full available quantity instead of subtracting the move quantity. This ensures the JS condition correctly evaluates to True and the move is marked as available. opw-5159142
This update resolves an issue where invoice generation would fail when a line item lacked a tax setting. The fix adds a check to prevent the system from attempting to calculate tax values in these cases, ensuring invoices are created correctly. This improves invoice processing reliability.
Original PR description
Issue: Attempting to generate facturae document for an invoice without a tax set on one or more line resulted in an IndexError. Solution: adding a check that prevents the function from trying to build tax values when there is no tax on the line. task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where accrual calculations weren't working correctly for allocation plans using modes other than 'By Employee'. The change ensures that allocation durations are automatically calculated accurately regardless of the chosen allocation mode, improving the reliability of holiday accrual planning. This resolves a previous error that prevented proper holiday allocation management.
Original PR description
### Steps to reproduce: - Create an accrual plan of one level to give 20 days at the start of the year - Create an allocation with different mode than 'By Employee' - Set the accrual plan for the…
### Steps to reproduce: - Create an accrual plan of one level to give 20 days at the start of the year - Create an allocation with different mode than 'By Employee' - Set the accrual plan for the allocation and date from 1st Jan - Notice the Allocation number of days doesn't get automatically calculated ### Cause: This is happening because when trying to process the accrual plan we won't have any records in the field employee_id https://github.com/odoo/odoo/blob/bcdd12d13d73915e565fd2c8478b936a16efb9f4/addons/hr_holidays/models/hr_leave_allocation.py#L892-L893 And since employee_id is computed field when computing it we don't handle the case of any other mode other than 'By Employee'. https://github.com/odoo/odoo/blob/bcdd12d13d73915e565fd2c8478b936a16efb9f4/addons/hr_holidays/models/hr_leave_allocation.py#L259-L270 ### Fix: If we have different mode in the allocation we fetch the employees in this mode (Department, Company, Employee Tag) and set them as the allocation employee_ids so when computing the employee_id we will have a record in the field and it won't be null P.S. In the forward port we will have to introduce another fix for the multi allocation wizard opw-5888023 Forward-Port-Of: odoo/odoo#247091
This update resolves an issue where invoices with both price-included and zero-price excluded taxes were incorrectly calculating taxes. The change ensures that tax calculations are accurate, regardless of whether a price-included or excluded tax line is present on the invoice. This improves the reliability of financial reporting.
Original PR description
…xes_data Suppose an invoice with price-included taxes but with a zero price excluded one. We don't want to fallback on the excluded mode just for that. opw-6060486 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves issues where imported BIS3 invoices didn't accurately reflect the total amounts due to discrepancies between the source XML and the invoice data. The changes improve the import process by synchronizing values and correcting any calculated differences, ensuring accurate invoice totals.
Original PR description
This commit refactors the import code of BIS3 Invoice to fix various issues about unsynchronized values between the imported invoice and the source XML file. The new way we import BIS3 invoice can be categorized as: - collecting all the values from the XML to a dictionary object - prepare the values and amounts to write to the invoice in its entirety using the tax computation engine helpers - write the whole processed values to the invoice (as a single write) - (in 18.0 ~ 18.2) recalculate discrepancies and update the invoice lines (if needed) with the corrected amounts This commit also includes a new test suite for BIS3 import, and a new approach of import testing, "Partial Imports", is introduced to better atomize the big import test files (and make it understandable). In the long term, `l10n_account_edi_ubl_cii_tests` will eventually be removed in favor of these small-but-many partial tests. task-id: 5058687 Co-authored-by: Yosua Nicolaus <yoni@odoo.com>
This update resolves a technical error that prevented inactive tax calculations within the l10n_in_withholding module. The fix ensures that inactive taxes are no longer incorrectly processed, preventing tracebacks and ensuring accurate tax calculations. This improves the stability and reliability of the invoicing withholding functionality.
Original PR description
Before this **PR**, attempting to apply an inactive tax resulted in a traceback. This occurred because l10n_in_section_tax_ids was empty, resulting in an empty iterable being passed to max(), which caused the error. To resolve this issue, l10n_in_section_tax_ids is now called with the context `active_test=False`. task-6074534
This update ensures Odoo's Danish localization (l10n_dk) is fully compliant with the latest Danish tax regulations. It updates account details, translations, and account groups to match current standards, improving financial reporting accuracy for Danish businesses using Odoo.
Original PR description
We updated the following in the Danish localization: - Updated the accounts to match the latest version provided by the Danish tax authorities. - Made sure we use the official Danish translations for the accounts and updated all of the English reference translations. - Removed outdated accounts and tags and have a migration script archive them for existing users. - Updated the account groups to match the CoA structure and use the correct Danish and proper English translations. - Adapted the account tags to match the updated accounts/numbers and replaced the outdated ones with their new version on existing accounts. - Removed unused account tags. - Updated some of the default accounts and prefixes on the chart template. task-5929517 Related: https://github.com/odoo/enterprise/pull/112430 Forward-Port-Of: odoo/odoo#256541