Daily updates from Odoo
Thursday, July 24, 2025
29 changes · 18.0
Resolved issues and error corrections
The Calendar app now correctly filters events by the current user's attendance status, such as accepted or declined. This prevents users from seeing empty search results when matching events actually exist, making calendar management more reliable.
Original PR description
The filter on an event's "Attending?" status was not working correctly. When filtering, the search would always return an empty result set because the underlying search implementation was logically flawed. It incorrectly compared calendar.event IDs with calendar.attendee data, which could never match. This commit corrects the `_search_current_attendee` method to properly query the `calendar.attendee` model. It now finds the intersection of attendees that both belong to the current user and match the filter criteria (e.g., state is 'declined'). It then uses these results to return the correct parent calendar events. A unit test has been added to verify the filter now works as expected. opw-4892386
Italian electronic invoices now remove line breaks from product descriptions before sending them to the SDI tax agency portal. This prevents otherwise valid invoices from being rejected due to unsupported formatting in the description field.
Original PR description
**Steps to reproduce:** 1. Install l10n_it_edi module 2. Create an invoice where the product description includes a newline. 3. Make sure the invoice uses VAT tax. 3. Confirm the invoice. 4. Click on…
**Steps to reproduce:** 1. Install l10n_it_edi module 2. Create an invoice where the product description includes a newline. 3. Make sure the invoice uses VAT tax. 3. Confirm the invoice. 4. Click on send 5. Only enable Send to Tax Agency. 6. Click "Send" again. 7. Go to the Attach files and download the attachment. 8. Check the `<Descrizione>` (description) in the XML file. **Issue:** The `<Descrizione>` field in the `<DettaglioLinee>` tag includes newline characters, which are not accepted by SDI portal. **Causes:** The line description is using '\n'.join(...), which results in actual newline characters in the XML. https://github.com/odoo/odoo/blob/ca7de6b2fbe4626583b67a34d77bbb523d972f79/addons/account/models/account_move_line.py#L513 https://github.com/odoo/odoo/blob/a7a29ed691db4f1607c0d12929c56845681164fa/addons/l10n_it_edi/models/account_move.py#L316-L324 **Solution:** To fix this, replace newline characters in the description with spaces and Strip leading/trailing whitespace. This ensures SDI receives a single-line <Descrizione>value. **Before fix:**  **After fix:**  Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4808826) opw-4808826 co-authored by: Raj Bhuva (bhra@odoo.com)
The website editor toolbar has been adjusted so it does not leave unwanted blank space below the page footer when hidden. This keeps edited pages visually tidy and prevents confusing extra scrolling or empty space for users.
Original PR description
Description of the issue/feature this PR addresses: - Commit [189a7c96](https://github.com/odoo/odoo/commit/189a7c96e6e26825dc05c0c6466576fe63aa091e#diff-de0d67e89972b45b101a9c4b04f316824314b0d69aba6208528586f1edb4f01cL25-L40) moved scrollbar from `#wrapwrap` element to `<body>`, caused the space below the footer visible for the floating toolbar. Current behavior before PR: - Space below the footer was always visible, even when the toolbar was hidden. Desired behavior after PR is merged: - `top: 0;` is applied on `.oe-toolbar` to ensure it stays out of the layout flow. - This prevents unnecessary layout space and ensures correct toolbar positioning. task-4652202 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an unreliable automated test for live chat session navigation by removing an unnecessary step that sometimes failed. The change helps keep quality checks stable without changing how users experience live chat.
Original PR description
The `test_session_history_navigation_back_and_forth` test sometimes fail. The test ensures we can navigate between the session list view and discuss using the browser history. To do so, the tour first accesses the list view using the command palette. However, command palette sometimes doesn't open. The command palette part of the tour is useless as the view can directly be accessed by passing the correct url to the `start_tour` function. This commit removes the command palette part of the tour thus fixing the issue. fixes runbot-108129 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes an internal website test more reliable by waiting for an image to finish loading before checking its size. This helps prevent occasional false test failures, supporting smoother maintenance and release validation without changing customer-facing behavior.
Original PR description
The goal of this commit is to avoid potential undeterminism that could occur in the `drop_404_ir_attachment_url` test (introduced by [this commit]). Before this commit, an error was thrown if the image was not loaded at the time the test checks the `naturalWidth` and `naturalHeight` property of the image. This could lead to undeterministic error as nothing ensures that the image is loaded at that time. To solve the problem this commit first waits for the image to be loaded before accessing the `naturalWidth` and `naturalHeight` property of the image. Side note: even if the source of the image is of type `data:` it is not directly loaded. [this commit]: https://github.com/odoo/odoo/commit/fbc6a697c1adf67ee8a90c49b0150d6ca170e081 task-4931144 Forward-Port-Of: odoo/odoo#217968
To reproduce: ============= -1 Install Peru accounting -2 Change language to Spanish PE -3 Go to add a new Tax form -4 Change code to ISC -5 Debug mode you will see the selections are not well translated Problem: ======== Translation team requested to change selections translations Solution: ========= Update translations opw-4954487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220353
Original PR description
To reproduce: ============= -1 Install Peru accounting -2 Change language to Spanish PE -3 Go to add a new Tax form -4 Change code to ISC -5 Debug mode you will see the selections are not well translated Problem: ======== Translation team requested to change selections translations Solution: ========= Update translations opw-4954487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220353
This fix prevents electronic invoices from including an item identification field when no product barcode exists. It helps avoid invalid or misleading invoice data and adds test coverage for direct invoice export scenarios.
Original PR description
In the refactored UBL (with `account_edi_ubl_cii.use_new_dict_to_xml_helpers`): Currently we may generate the `StandardItemIdentification` node even in case the `barcode` is not set on the product. The issue was introduced as a FW-port issue in commit f46c10f03e59e8aae98079fc57f5295a376f2761 (18.0). The problem is that the `schemeID` attribute is always set. task-None (original fix is task-4941855)
Fixed an issue in Point of Sale loyalty programs where customers with existing points could still claim a reward after the program's maximum usage limit had already been reached in the session. This helps ensure promotions are applied consistently and prevents unintended extra reward redemptions.
Original PR description
When an existing partner with points tries to claim a reward from a loyalty program that has reached its max usage in the current session, he was still able to claim the reward. Steps to reproduce: ------------------- * Create a loyalty program with max usage set to 1 * Create a partner and assign points to him * Open PoS and select any partner and make an order * Claim the reward from the loyalty program * Select the partner that already has points * Make an order and try to claim the reward again > Observation: The reward can be claimed, even though the max usage is already reached. Why the fix: ------------ When updating programs, we were not removing the couponPointChanges for programs that are not applicable anymore. We now make sure to delete them when the program is not applicable anymore. opw-4805704 Forward-Port-Of: odoo/odoo#218425
Companies in Greece and Ireland with valid VAT numbers will now correctly see the Intra-Community Valid checkbox for VIES verification. This fixes a country code mismatch so affected businesses can use VAT validation as expected.
Original PR description
Current behavior before PR: - Intra-Community Valid checkbox (for vies verification) was not showing for Greece and Ireland companies with valid VAT number. This was because Greece ISO is GR and Ireland ISO in IX, but their VAT start with EL and IE Desired behavior after PR is merged: - Checkbox is shown despite differences between ISO and beginning of VAT Link to task : - https://www.odoo.com/odoo/project/967/tasks/4575784 Forward-Port-Of: odoo/odoo#201630
This fixes an issue in the website editor where pressing backspace after selecting content across paragraphs could remove text beyond the intended selection. Users can now delete selected editor content without accidentally losing following content.
Original PR description
Problem: Given content like: ``` <p>keep<br>[delete</p> <p>delete<br>delete<br>]</p> <p>keep</p> ``` Pressing backspace removes the last "keep" as well, which is incorrect. Cause: The merge logic uses `range.endContainer` as `joinWith`, but does not account for `range.endOffset`. When `range.endContainer` is a `<p>` with a non-zero offset, the condition `next.previousSibling && next.previousSibling === joinWith` fails. During merging, `next` may go inside `joinWith`, making the logic invalid. Solution: Prevent merging when `next` is positioned exactly at `range.endOffset`, preserving the correct boundary. Steps to reproduce: - Add the sample HTML to the editor - Select from `[delete` to `delete]` - Press backspace -> The final `<p>keep</p>` is deleted incorrectly opw-4905047 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219392
This fix ensures the image cropper closes when a user deletes the image being edited, preventing confusing leftover controls in the editor. It also makes the crop option reliably reopen after using or discarding image transformation tools, improving the image editing experience.
Original PR description
### Steps to reproduce: **Issue 1:** - Add an image in the editor. - Apply image transformation (e.g., shrink it). - Open the image cropper tools. - Press the Backspace key. - Observe that cropper…
### Steps to reproduce: **Issue 1:** - Add an image in the editor. - Apply image transformation (e.g., shrink it). - Open the image cropper tools. - Press the Backspace key. - Observe that cropper still visible. **Issue 2:** - Go to To-Do and insert an image. - Click on Image Transform, then on Image Crop — observe that Image Crop opens correctly. - Click the Discard button in the Image Crop UI. - Again select the image, click Image Transform, then Image Crop. - Notice that Image Crop no longer opens. ### Description of the issue/feature this PR addresses: - Pressing Backspace removes the image from the editor. - However, the cropper remains open, and focus returns to editable area, allowing to type with the cropper still visible. - Clicking Image Crop while Image Transform was active could destroy both due to async loadBundle() timing. On subsequent attempts, ImageCrop was added before ImageTransform was removed, causing Owl to destroy both in the same frame. ### Desired behavior after PR is merged: - When the image is removed, the associated cropper is also closed. - Clicking Image Crop button while Image Transform is active now works. task-4859869 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes activity deadline searches so activities already marked as done are no longer counted as overdue or due. It keeps activity lists and CRM follow-up views accurate when completed activities are retained for reporting.
Original PR description
The search for "my_activity_date_deadline" is used to find activities due before some set date. When keeping done activities for reporting purposes, we should never consider "done" activities for this search. Issue is introduced in CRM in [1] but it could happen anywhere task-4951716 [1]: https://github.com/odoo/odoo/commit/f9f0529c93614bb9f9deec1a5aaa1daccfe8b58c Forward-Port-Of: odoo/odoo#219426
This fix makes an automated sales project test wait for the expected screen behavior before continuing. It reduces false test failures during installation without changing how business users create or manage sales order lines.
Original PR description
Steps to reproduce the issue: 1- install sale_project without demo data 2- as the test is not deterministic, adding step_delay may help reproducing it The test was failing because the tour was not waiting for the modal to close before trying to click on the created sale order line. so accoding to this line https://github.com/odoo/odoo/blob/18.0/addons/sale_project/models/sale_order_line.py#L63-L63 the New Sale order line have in it a default product which doesnt open a modal build_error-163102
Country names entered during contact imports are now matched even when users type them in all caps or other capitalization styles. This prevents valid country values like "ARMENIA" from being rejected, reducing import errors and manual cleanup.
Original PR description
**Current behavior:** When importing a res.country record, if specifying a `name` then the search performed expects it to exactly match a first-letter-only capitalized pattern. **Expected behavior:** Let arbitrary capitalization be used on the input name string. **Steps to reproduce:** 1. Create a sheet to import to `Contacts` (res.partner) * `name`: anything * `country_id`: "ARMENIA" 2. Load the sheet for import -> test -> can't resolve country name **Cause of the issue:** The `res.country` records' names follow a first-letter-capitalized pattern and we do an exact search on the strings. **Fix:** Take the user input search strings and do additional searches on transformations of them that may match the sought after records. opw-4780334 Forward-Port-Of: odoo/odoo#216870
The shipping weight entered on a stock transfer now remains saved after refreshing or reopening the record. This prevents confusion and helps warehouse teams rely on the displayed shipment weight.
Original PR description
The Shipping Weight field was editable in the transfer, but upon refresh or reopening, it reverted to its previous value. This issue is now resolved by setting the field as store=True. 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
Fixed an issue where a failed company image download could trigger an additional error while being logged. This helps ensure company creation through the mail plugin continues to report the original download problem cleanly instead of producing a confusing traceback.
Original PR description
When logging a failed image download for a new company,
A traceback will appear.
[1]- https://github.com/odoo/odoo/blob/2317fec604907280aa89c52cfcaeb9adc30e5d04/addons/mail_plugin/controllers/mail_plugin.py#L360
https://github.com/odoo/odoo/blob/2317fec604907280aa89c52cfcaeb9adc30e5d04/addons/mail_plugin/controllers/mail_plugin.py#L342-L344
here, ``new_company_info`` is dictionary, but at [1] the code incorrectly accesses
``name`` as an attribute.
So, it will lead to the below traceback.
Traceback:
```
File "/home/odoo/src/odoo/addons/mail_plugin/controllers/mail_plugin.py", line 359, in _create_company_from_iap
_logger.warning('Download of image for new company %s failed, error %s', new_company_info.name, e)
AttributeError: 'dict' object has no attribute 'name'
```
sentry-6554480256
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#206771Saving a blog post after removing all content now shows a proper validation message instead of causing a system error. This prevents confusing backend errors and gives users clearer feedback when empty HTML content cannot be saved.
Original PR description
Currently an error occurs when we try to save a blog post with no content. Steps to replicate: - Install the `website_blog` module. - Navigate to the website, go to the Blogs section, and create a…
Currently an error occurs when we try to save a blog post with no content. Steps to replicate: - Install the `website_blog` module. - Navigate to the website, go to the Blogs section, and create a new blog. - Click to open the newly created blog. - Remove any existing content (e.g., placeholder text like 'Start Typing...'). - Type `/column` and click on the 2-column option. - Click on the columns that appear — you’ll see a delete icon. - Delete all the columns, click Save and check the terminal. Error: `ParserError: Document is empty` The error occurs when all content in the blog is deleted, resulting in empty HTML content. During saving, `html.fromstring(lang_value)` [1] is called with `lang_value` being effectively empty, which leads to a `ParserError`. [1] - https://github.com/odoo/odoo/blob/28c3b9cf10488536dce5a4927fdbe8fcd6e5a839/addons/web_editor/models/ir_ui_view.py#L126 This commit fixes the problem by catching the `ParserError` and raising a `ValidationError` when the HTML content is empty. sentry-5081806749 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216790
Odoo now handles attendance records that cross midnight by splitting them into separate daily work entries. This prevents duplicate or conflicting work entries when an employee has an overnight shift followed by another attendance on the next day.
Original PR description
Steps to reproduce the issue: 0. Set work_entry_source to "attendance" on the running contract of the employee. 1. Create an attendance for yesterday 23:00:00 UTC to today 06:00:00 UTC. 2. Create an…
Steps to reproduce the issue: 0. Set work_entry_source to "attendance" on the running contract of the employee. 1. Create an attendance for yesterday 23:00:00 UTC to today 06:00:00 UTC. 2. Create an attendance today from 08:00:00 UTC to 16:00:00 UTC. Current behavior before PR: Odoo will create a conflicting work entry with the one created in step 1, because the logic recreates all work entries in a timeframe between the start date at 00:00:00 and end date at 23:59:59. The first entry started before this timeframe, so the recreated work entry does not align with the existing one, causing a conflict. Desired behavior after PR is merged: The work entries now span a single day at a time. If an attendance starts at night and ends the next morning, two entries will be created: one from the start time to end of day, and another from the start of the next day to the end time. opw-4869604 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#90588
The Indian GST reporting module now creates the GSTR1 report with the required permissions during automated testing. This prevents permission-related failures and helps keep GST report validation reliable.
Original PR description
steps to reproduce: 1. Install l10n_in_reports module. 2. Run the test `TestReports.test_hsn_schema_change_gstr1_json`. this is required to avoid permission issues when creating the GSTR1 report in the test. build_error-223245 Forward-Port-Of: odoo/enterprise#90221 Forward-Port-Of: odoo/enterprise#89116
This fix prevents an error when users refresh or duplicate a browser tab while working with a sent Sign request. It makes the Sign page load more reliably by handling missing page context safely.
Original PR description
**Steps to reproduce:** 1. Install sign 2. Create a sign request and send it to someone 3. Now, either refresh the page or duplicate the page **Issue:** - Traceback Error ```UncaughtPromiseError > OwlError Uncaught Promise > The following error occurred in onMounted: "Cannot read properties of undefined (reading '4')" ``` **Cause:** - requestItemStates is not defined here, which is passed by context https://github.com/odoo/enterprise/blob/ceebc915607b471ffb8e3bbde055c6816cc06b43/sign/static/src/backend_components/sign_request/sign_request_control_panel.js#L34 **Solution:** - Add a safe fallback if requestItemStates is not present backport a5a6718c3a2fba226ecd7ed3efdb32d06777b6ae opw-4949153
Mexico payroll and salary offer calculations now handle employees who do not yet have an initial contract start date. This prevents invalid operation errors in the salary configurator and keeps payroll calculations stable by using safe default values.
Original PR description
Before this fix, various computations relying on `employee.first_contract_date` fails if the value was missing, notably: - `_compute_integration_factor` in payslips - Python expressions in MX salary rules (holiday bonus, ISR, etc.) Steps to reproduce: Install the following modules: - Recruitments, Payroll, Salary Configurator - Mexico - Payroll, Mexico - Payroll - Localisation, EDI for Mexico Go to Recruitment -> create or click on application in any offer -> click on generate offer(create a contract templates if needed) -> Click on Salary Configurator, notice the Invalid Operation Error After fix: - Default the integration factor to 1 and years worked to 0 when no start date exists - Safely guard salary rule conditions and computations with proper checks This ensures robust payroll calculation even for employees without an initial contract date. opw-4853613
This fixes occasional failures in automated Studio report tests caused by unreliable scrolling checks. The change makes the tests wait more reliably, helping reduce false alarms in quality checks without changing user-facing features.
Original PR description
Linked tests: - `test_add_field_blank_report` - `test_field_placeholder` These tests contained scroll-related indeterminacies that caused them to fail from time to time. This was due to the fact that we were modifying the scroll and we used this code to make sure it was done: ```js await new Promise(requestAnimationFrame); ``` However, sometimes this wasn't enough, so we now use `waitUntil`, which is more robust https://runbot.odoo.com/odoo/runbot.build.error/181989 runbot-181989
Fixed the website helpdesk contact form so the description label is translated correctly when users submit tickets in another language. The description field is also hidden when it is the only field, avoiding duplicate or confusing information on new tickets.
Original PR description
## Short functional explanation of the issue When a ticket is created and there are no additional fields, the only field in the ticket is the description field. Moreover, it is not translated. ##…
## Short functional explanation of the issue When a ticket is created and there are no additional fields, the only field in the ticket is the description field. Moreover, it is not translated. ## Reproduction Steps 1. Go to the general settings. Add a language where the term "description" differs from the english word (for example, Spanish). Do the same for the website settings. 2. Go to the website app. Scroll down and change the language. Then, click on the translated "contact us" tab. Fill the form and send the ticket. 3. Go to the helpdesk app and open the ticket you just created. ### Expected behavior The description field shouldn't show, as it appears in the description page. The field should only show if there are additional fields on the "contact us" page. ### Unexpected behavior The description field shows, untranslated. ## Origin of the issue In the ticket code, the field.name is used, instead of the field .field_description, which is translatable. Moreover, there isn't a condition checking if the field should appear or not. -- opw-4876726
This update adjusts automated checks for CRM activity handling after the activity action began loading in two steps. It also verifies that both active and inactive records are included where needed, helping keep CRM behavior reliable after related changes.
Original PR description
The crm activity action is now loaded in two steps Also check that the domain gets `active in [true, false]` added while we're here See linked community pull request task-4951716 Forward-Port-Of: odoo/enterprise#90762
Portal users can now see published Knowledge articles marked as visible to everyone from the website help page. This fixes an inconsistency where logged-in portal users were blocked from content that anonymous visitors could already view.
Original PR description
There is a bug, when portal user wants to access a article with visibility set to everyone through help page on the website, the portal user wouldn't be able to see anything by clicking on browse…
There is a bug, when portal user wants to access a article with visibility set to everyone through help page on the website, the portal user wouldn't be able to see anything by clicking on browse button, while if the portal users logs out and access the same page, they would be able to see the articles. The steps to reproduce: 1- Setup a database with helpdesk, website, and knowledge app installed. 2- On website app --> help --> Helpdesk Team, enable the knowledge checkbox. 3- Create an article and publish it on the website and set the visibility to everyone. 4- Login as an portal user. 5- Navigate to help page on the website. Click on Browse articles. 6- You can see the article is not shown here. 7- Logout from the portal user and repeat the step 5. You can now see the article. In the current version, if the user is not logged in, they will access the article with visibility set to everyone, which is expected. This is done by returning [] in the _search_is_article_visible. Elsewise, if the user is an internal user, the member_domain and is_article_visible_by_everyone are checked to see if either user has access on the article or the article is visible by everyone. If the user is not an internal user (portal user), the article will be only accessed if they are a member of the article, without checking article's visibility, which causes the bug. opw-4835998
Zero-cost Brazilian point-of-sale orders now include the required payment information when sent for electronic invoicing. This prevents Avalara submission errors and helps ensure free or fully discounted sales can still be invoiced correctly.
Original PR description
Right now, for 0 cost POS orders no `paymentMode` section is sent to Avalara, which leads to an error from them when trying to submit the invoice: Code 899: incorrectly entered payment method field The proper fix is to always send `paymentMode` with a value of 0.00 and mode of `Other`. (Note that there is a payment mode that corresponds to no payment, 90, but it only available for NF-e not NFC-e so we use 99) opw-4874094
The Swedish SIE4 import now reads files using UTF-8 so Swedish characters are handled correctly. This helps avoid import errors or incorrect text when customers upload accounting files containing local characters.
Original PR description
The aim of this commit is using UTF8 instead of ISO-8859-1 for the file decoding. We received feedback from customers that the previous decoding wasn't handle correctly swedish characters. The documentation tends to say that we should follow CP437. As UTF8 is a superset of CP437, we are now using it. opw-4868415 Forward-Port-Of: odoo/enterprise#90498
This fix ensures invoice policy calculations only consider consumable products, preventing incorrect results when other product types are present. It helps avoid test failures and supports more reliable sales and invoicing behavior in affected localizations.
Original PR description
steps to reproduce: 1- install l10n_ke_edi_oscu_mrp 2- run test test_discount_and_untaxed_subtotal The compute_invoice_policy method was not correctly filtering products by their type. This fix ensures that only consumable products are considered when computing the invoice policy. build_error-70728 Forward-Port-Of: odoo/enterprise#90252
The Czech VAT Control Statement XML export now uses the official date field name for B2 vendor bill entries. This prevents the Czech tax portal from treating the field as blank, reducing filing errors for affected companies.
Original PR description
**Steps to reproduce**: 1. Install `l10n_cz` and `l10n_cz_reports_2025`. 2. Create a vendor bill with a vendor whose place of supply is in-country, set the bill amount to more than 10,000, and…
**Steps to reproduce**: 1. Install `l10n_cz` and `l10n_cz_reports_2025`. 2. Create a vendor bill with a vendor whose place of supply is in-country, set the bill amount to more than 10,000, and confirm the bill. 3. Go to Reporting → Tax Return → VAT Control Statement (CZ). 4. You will see the bill listed under section B2. Now export the XML. 5. In the exported XML, the field `dan_dppd` is present. **Observations**: When exporting XML from the VAT Control Statement report, the date field in the B2 section is incorrectly named `dan_dppd`. According to the official CZ VAT Control Report documentation ([link](https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1#110009830_dppd)), As a result, when importing the generated XML into the CZ portal, the field appears blank because it is not recognized. **Issue**: The export template uses the incorrect tag `dan_dppd` instead of the correct `dppd` for the B2 section. **Solution**: The export template was updated to use `dppd` instead of `dan_dppd` in the B2 section, as per the official documentation. opw-4868515 Forward-Port-Of: odoo/enterprise#90394