Website form submissions that contain hidden NUL characters are now handled gracefully instead of causing an error. This helps prevent failed submissions and improves reliability for visitors using website forms.

This error often occurs when the data submitted through forms contains NUL characters.

Error: 
``ValueError: A string literal cannot contain NUL (0x00) characters.``

This commit will catch ValueError when the data with NUL characters is submitted through forms.

sentry-5049576227

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Sales teams can now create CRM leads by scanning business cards, reducing manual data entry after meetings or events. This makes it faster to capture new prospects and helps ensure contact details are recorded more accurately.

This commit aims to improve crm module by adding the
feature of generating lead by scanning business cards.

Community PR - https://github.com/odoo/odoo/pull/204766

Task-4210816

Fiduciaries can now revoke Codabox connections even when they no longer have access to the client company's database. This helps prevent former clients from continuing to retrieve bank statements through the fiduciary's Codabox account.

### Before
Codabox connections could only be revoked within the company's db, so if the fiduciary didn't have access to their db anymore they wouldn't be able to revoke the connection and the company would still be able to retrieve their statements through the fiduciary's Codabox account.

### Now
A new revocation wizard allows for an editable company id field which then allows fiduciaries to revoke connections for companies' whose dbs they can't access anymore using the fiduciary password. 

odoo/iap-apps/pull/1012
task-4075805

Businesses can now sell partnership products that automatically assign commission plans to customers. The update also supports recurring memberships through subscriptions, making ongoing affiliate or partner relationships easier to manage.

task-4421310

The point-of-sale IoT customer display is now always enabled, so users no longer encounter an unnecessary configuration error. This reduces setup friction and makes the customer display behavior more predictable for stores.

In this commit:
================
Customer display configuration has been removed from res config settings and is
always enabled, the user error is no longer needed and has been removed.

Task-4604770

Related Community PR:https://github.com/odoo/odoo/pull/201637
Related Upgrade PR:https://github.com/odoo/upgrade/pull/7386

Users can now update a company’s shared address, VAT, and pricelist directly from a related contact, reducing extra navigation and avoiding inconsistent contact data. The change also removes the rarely used follow-up contact type in favor of invoice contacts, making customer records simpler to understand.

Rationale

When you edit the contact of a company, you actually edit the company
at least for what concerns the address.

Specifications for address
====================

Previously fields were readonly on form view and people had to
follow the m2o to edit it. However this is not really user friendly
and also eases desynchronization between code (that does not
prevent updating contact address) and interface (who does it).

We now consider contacts and their parent share the same address.
Synchronization is therefore done upstream.

There are still some limitations, like: address is not propagated
through the whole contact tree, all descendants are not necessarily
always updated, ... This would require a more in-depth rewrite of
the sync code. Maybe for later.

A new 'type address label' field is added that dynamically updated
the partner address label. That way we know we are editing the
Company Address when editing a contact. For other types the label
indicates it is a specific address (Invoice Address, Delivery, ...)

Varia

This notably fixes an issue when setting a parent on a contact partner.
Previously this parent was a company without address, and the address
on the contact was not editable (readonly due to parent). Now it is
correctly propagated to the parent.

This allows to remove a custom call to '_handle_first_contact_creation'
which was updating parent company when setting their first contact
child. This is now standard. Method is kept for optimized import that
is not touched in this PR to avoid adding performance issues.

Vat / Pricelist
==========

As for address fields, we now allow to edit VAT and pricelist on partners
that are children of companies. It directly edits company, instead of forcing
users to go to the parent and edit VAT.

Implementation choice is to make a subset of commercial fields, limiting
the sync currently on VAT only. Other commercial fields still behave
like before this PR, notably to limit side effects, and because VAT
is a more commonly updated fields than l10n or reference commercial
fields.

Varia

This fixes an issue when a new parent without values is set on a
contact child. Previously to this commit, commercial sync erased
child values, which is annoying. Now child is not erased anymore
and their values are sent to the parent, which is cool. This is
still limited to "synced" values, aka VAT only.

Task-4708358
Part of Task-4377720

The product version field in PLM has been repositioned into the traceability section of the product form. This makes version information easier to find alongside related tracking details, improving clarity for manufacturing and product lifecycle users.

Task-4441066

The website generator has been updated to stay compatible with recent changes in the main Odoo website platform. This helps ensure the website setup experience continues to work smoothly for users as the broader system evolves.

See also:

- https://github.com/odoo/odoo/pull/201410

Point of Sale users can now view and settle a customer's unpaid invoices during checkout. This makes it easier to collect outstanding balances in-store and gives staff clearer visibility by separating invoice amounts due from order amounts due.

- Added functionality to list and settle unpaid invoices in PoS.
- Introduced a "Settle Invoice" product for processing invoice order line.
- Enhanced customer balance tracking by distinguishing order due and invoice due amounts.
- Add access rights for PoS users to read account.move

community PR: https://github.com/odoo/odoo/pull/203672

task-id: 4501448

The spreadsheet test setup no longer loads chart resources that are already included automatically. This reduces duplicated test preparation work and helps keep internal testing simpler without changing business features.

In the helper `prepareWebClientForSpreadsheet`, we would explicitely load some ChartJs assets
to ensure their presence but those are already loaded in the tests assets bundle (the test loads
spreadsheet.o_spreadsheet which in turn depends on web.chartjs_lib).

Gantt popovers now reuse the existing Kanban-style card view and correctly carry the action context, so fields display or hide as expected. This makes scheduling popovers clearer and more consistent, with warning details such as time off and overlaps shown directly where users review planning items.

1)  web_gantt: pass the action context
    
   - Issue:
        When the Kanban view is opened from the Gantt popover, the context
        is not being passed in the record.If the visibility of the field is
        based on the context, it will not work, as shown in the example below.
   - For example:
     When a task is opened from a specific project, the project name should not be displayed.

  - xml:

      `<field invisible="context.get('default_project_id', False)" name="project_id" options="{'no_open': True}"/>` 


2) In this commit:
- We have used the existing Kanban view in the Gantt popover.
- Time-off, overlapping, and other warnings have been added to the Gantt popover's Kanban view.

task-4444660

Timesheet grids now keep their color indicators when entries are grouped by employee. This makes grouped timesheet views easier to scan and helps users spot important differences or statuses more quickly.

Before this commit there was no color indication on timesheets when grouped by employees. Now color indication is done when grouped by also.

task-4653902

This update adjusts Odoo spreadsheet features to stay compatible with recent spreadsheet engine changes. It improves chart, pivot table, comments, and field synchronization behavior, including restoring scrolling in read-only pivot panels.

This commit contains adaptations following the o-spreadsheet update.
See https://github.com/odoo/odoo/pull/206102

Fixed an issue in Documents where duplicating a selected document could make the browser tab stop responding. The selection now stays focused correctly after duplication, improving reliability for users working with documents.

Reproduce:
1. Open Documents
2. Select a document
3. Duplicate it
4. Close your now non-responsive tab...

Updating a state inside onWillUpdateProps triggered a new rendering cycle, where the `list` prop was different each time, and thus looped. Also, we do not change folder (after duplication for example), we must keep focus on the selection and not switch to the containing folder.

Task-4717552

Public website visitors now see the intended custom placeholder images for appointment-related products when no product image is set. This avoids fallback to a generic image and keeps appointment and sale pages visually consistent.

Placeholders were introduced in odoo/odoo@c52453f for meta products such as discounts, gift cards, event tickets, and appointments.

Previously, access rights prevented public users from viewing these placeholders. Even when no image was linked to a record, access was denied due to read restrictions, defaulting to the generic placeholder instead of the custom one provided by `_get_product_placeholder_filename`.

This commit overrides `_can_return_content` in relevant modules to allow proper access for public users, ensuring the intended placeholder is displayed.

See also:
- https://github.com/odoo/odoo/pull/205693

The VoIP softphone has been redesigned to make calling workflows easier and more connected. Users can search contacts more efficiently, see better phone country detection, send SMS from VoIP when available, and access linked recruitment applicants directly from calls.

This commit introduces a complete rewrite of the Odoo Softphone UI.

## Model changes:
- The computed field "t9_name" is added to res.partner to allow efficient searching by "[T9 code](https://en.wikipedia.org/wiki/T9_(predictive_text))".
- The computed field "country_code_from_phone" is added to res.partner, mail.activity and voip.phone. It computes the ISO country code corresponding to the country contained in their phone number field.

## Bridge modules:
- Introduction of the voip_sms bridge module, adding a button to the VoIP softphone to send SMS if both voip and sms are installed.
- Introduction of the voip_hr_recruitment bridge module, adding a button to open the form view of applicants linked to a VoIP contact.

Task-4642428
Community: https://github.com/odoo/odoo/pull/202558

Co-authored-by: Basioni (basm) <basm@odoo.com>
Co-authored-by: Brieuc-brd <brd@odoo.com>
Co-authored-by: Louis Wicket (wil) <wil@odoo.com>
Co-authored-by: yhu-odoo <yhu@odoo.com>

The social push notification component was updated to align with Odoo's newer website interaction framework. This is an internal modernization that helps keep the feature maintainable while preserving the existing user experience.

continuation of work continue working on the refactoring introduced by this commit: [1]

[1]: odoo/odoo@dd13994
task-4367641

The appointment booking slot selector was reorganized as part of a broader modernization of the website interaction code. This should preserve the same customer-facing booking experience while making the feature easier to maintain and evolve.

1/ 1. Select a record in kanban view in a folder with a few records (< page size) 2. Switch to list view 3. The documents should still be selected, some actions are visible, but not all This occurs because the old view is unmounted only after the new view is already mounted, so the service function is set to null. We don't need to clear it when unmounting because no other context (not a documents view) is expected to call this method on the documents service. 2/ 1. Select a pdf re

1/

1. Select a record in kanban view in a folder with a few records (< page size)
2. Switch to list view
3. The documents should still be selected, some actions are visible, but not all

This occurs because the old view is unmounted only after the new view is already mounted, so the service function is set to null.
We don't need to clear it when unmounting because no other context (not a documents view) is expected to call this method on the documents service.

2/

1. Select a pdf record in kanban view
2. Open Split Tools
3. Actions are not shown

Task-4702653

Forward-Port-Of: odoo/enterprise#82871

https://runbot.odoo.com/odoo/error/163099 This issue became visible as part of the change to test ACLs (removal of demo data, possibly change to groups too) as well as running the "single app tests" on *every module*, not just the apps. The issue is that `self.Requests.user` and `self.employee_user` are unrelated (the amazingly named `self.employee_user` doesn't even have a user). On leave creation, this triggers the rule `hr_leave_rule_employee_update` which checks if: - The current us

https://runbot.odoo.com/odoo/error/163099

This issue became visible as part of the change to test ACLs (removal of demo data, possibly change to groups too) as well as running the "single app tests" on *every module*, not just the apps.

The issue is that `self.Requests.user` and `self.employee_user` are unrelated (the amazingly named `self.employee_user` doesn't even have a user). On leave creation, this triggers the rule `hr_leave_rule_employee_update` which checks if:

- The current user is the employee's, which is not the case because the employee doesn't have a user.
- Or the current user is the employee's leave manager, which is also not the case because the employee does not have a leaves manager.

As a result the creation of the leaves fails immediately.

Fix in 17.4 as the test was introduced in #53940 which was merged in (what would become) 17.3, even though the test setup means it might not be possible to trigger there because of all the demo messing with groups.

Forward-Port-Of: odoo/enterprise#83427

pos*: l10n_ec_edi_pos, l10n_ke_edi_oscu_code, l10n_ke_edi_oscu_pos l10n_mx_edi_pos, pos_blackbox_be, pos_settle_due Before this commit, when wanting to synchronize a record from the server to a pos via websocket, we were only reading the record without post_processing it as we do when we load the data from the server at the opening of the pos. This would lead to error when synching the data as some data were lost when replacing old records with new ones. Community PR: odoo/odoo#200992 For

pos*: l10n_ec_edi_pos, l10n_ke_edi_oscu_code, l10n_ke_edi_oscu_pos l10n_mx_edi_pos, pos_blackbox_be, pos_settle_due

Before this commit, when wanting to synchronize a record from the server to a pos via websocket, we were only reading the record without post_processing it as we do when we load the data from the server at the opening of the pos. This would lead to error when synching the data as some data were lost when replacing old records with new ones.

Community PR: odoo/odoo#200992

Forward-Port-Of: odoo/enterprise#81052

Previously, the intrastat_code_id was filtered by checking against a large list that is sent to the frontend. This caused huge memory usage due to the list being used in many objects and the list itself being large, around 10k items. This memory leak caused slowness in the frontend while going through the product form views. Currently, the list is not being sent. The domain itself is evaluated from the frontend without sending a list. This reduces memory footprint and slowness. Forward-Port-

Previously, the intrastat_code_id was filtered by checking against a large list that is sent to the frontend. This caused huge memory usage due to the list being used in many objects and the list itself being large, around 10k items. This memory leak caused slowness in the frontend while going through the product form views.

Currently, the list is not being sent. The domain itself is evaluated from the frontend without sending a list. This reduces memory footprint and slowness.

Forward-Port-Of: odoo/enterprise#82239

**Steps to reproduce:** - Install Accounting and l10n_pe_edi - Switch to a Peruvian company (e.g. PE Company) - Go to "Settings / Technical / Database Structure / Decimal Accuracy" - Set 4 digits for "Product Price" - Create a product with a lower price than 0.01 (e.g. 0.0045) - Create an invoice: * Customer: [a Peruvian customer] (e.g. Comercial Constructora los Patitos S.A.) * Product: [the created product] * Quantity: 100 - Confirm the invoice - Process the invoice by the E-i

**Steps to reproduce:**
- Install Accounting and l10n_pe_edi
- Switch to a Peruvian company (e.g. PE Company)
- Go to "Settings / Technical / Database Structure / Decimal Accuracy"
- Set 4 digits for "Product Price"
- Create a product with a lower price than 0.01 (e.g. 0.0045)
- Create an invoice:
  * Customer: [a Peruvian customer] (e.g. Comercial Constructora los Patitos S.A.)
  * Product: [the created product]
  * Quantity: 100
- Confirm the invoice
- Process the invoice by the E-invoicing service

**Issue:**
An error is triggered because "PriceTypeCode" is set to "02", which is the code used to declare that it is free.
But in this case, it is not free.

**Cause:**
"PriceTypeCode" is computed by using "is_zero" method of the currency on the unit price.
As the decimal accuracy of the currency is set to 2 and the unit price is 0.0045, "is_zero" is returning True.

**Solution:**
Compute "PriceTypeCode" from the line subtotal instead of the unit price.
This is not perfect as it can also be lower than 0.01, but it's less probable.

opw-4608671

Forward-Port-Of: odoo/enterprise#83401
Forward-Port-Of: odoo/enterprise#82019

Commits fc49984a and 2644a63b introduced changes to: - Prevent rejections for invoices older than 72 hours (error 301). - Use the correct partner/branch timezone when generating the CFDI. However, these changes also cause each re-stamping attempt to use the current timestamp, resulting in duplicates on the SAT if the first attempt times out or is lost (e.g., due to a disconnection). The PAC sees each request as a distinct CFDI if there is even a slight difference in the timestamp. This f

Commits fc49984a and 2644a63b introduced changes to:
- Prevent rejections for invoices older than 72 hours (error 301).
- Use the correct partner/branch timezone when generating the CFDI.

However, these changes also cause each re-stamping attempt to use the current timestamp, resulting in duplicates on the SAT if the first attempt times out or is lost (e.g., due to a disconnection). The PAC sees each request as a distinct CFDI if there is even a slight difference in the timestamp.

This fix ensures that the same emission timestamp (stored in `l10n_mx_edi_post_time`) is reused for subsequent stamping attempts, producing an identical XML and preventing duplicates on the SAT.

Steps to reproduce the original issue:
1. Create and confirm an invoice.
2. Stamp the invoice.
3. Manually set the EDI status to “to_send”: ```python record.edi_document_ids.write({"state": "to_send"}) ```
4. Stamp again without persisting the emission timestamp => a new CFDI is generated.

Expected result after the fix:
- The system reuses the same emission timestamp (l10n_mx_edi_post_time) for each attempt, preventing duplicate CFDIs on the SAT.

According to the [SAT
documentation](http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Anexo_20_Guia_de_llenado_CFDI.pdf)
the attribute `Fecha` must be the expedition date.

Forward-Port-Of: odoo/enterprise#83319
Forward-Port-Of: odoo/enterprise#81882

Currently, when settling customer's account using the mexican localization, the session crashes after selecting the payment method. Steps to reproduce: ------------------- * Install the mexican localization and switch to one of the company * Create a new contact of type "Company" * Create an invoice for that contact so that he has a due amount set * Open session * Select the customer and settle due amount * Select any payment method > Observation: Blank screen Why the fix: -------

Currently, when settling customer's account using the mexican localization, the session crashes after selecting the payment method.

Steps to reproduce:
-------------------
* Install the mexican localization and switch to one of the company
* Create a new contact of type "Company"
* Create an invoice for that contact so that he has a due amount set
* Open session
* Select the customer and settle due amount
* Select any payment method
> Observation: Blank screen

Why the fix:
------------
Same issue addressed here but at a different place: https://github.com/odoo/enterprise/commit/e1e1abdd23cead2bcd7b8170da28161c3f5b2e15

Cause by the fact that when a customer of type "company" is selected we automatically invoice orders.
https://github.com/odoo/odoo/commit/270779c8250272920d759fbe7b6cfc889e2f5969

Instead of going in the same direction of the first fix, we never set `to_invoice` to true when we are settling customer accounts. It's pointless to set invoice to true when settling accounts as it's impossible to create an invoice without any product. This should also benefit localizations that invoice by default every order by bypassing the invoice in that case.

opw-4685842

Forward-Port-Of: odoo/enterprise#83172
Forward-Port-Of: odoo/enterprise#82785

When a company partner is selected for an order, the commit https://github.com/odoo/odoo/commit/270779c8250272920d759fbe7b6cfc889e2f5969 automatically sets the order to invoice. This causes the order to miss required localization fields, leading to an error during payment. opw-4670131 Forward-Port-Of: odoo/enterprise#82211 Forward-Port-Of: odoo/enterprise#82061

When a company partner is selected for an order, the commit https://github.com/odoo/odoo/commit/270779c8250272920d759fbe7b6cfc889e2f5969 automatically sets the order to invoice. This causes the order to miss required localization fields, leading to an error during payment.

opw-4670131

Forward-Port-Of: odoo/enterprise#82211
Forward-Port-Of: odoo/enterprise#82061

This update fixes two issues: customer details from UrbanPiper orders now refresh correctly when the same phone number is reused, and Mexican EDI documents can correctly read fiscal folio data from longer uploaded XML files. This helps keep customer records accurate and prevents missing fiscal identifiers on payment documents.

Fixes an issue where uploading longer Mexican Payment 2.0 XML files could leave the Fiscal Folio blank. The system now reads the full XML content instead of a file-size placeholder, ensuring the document identifier is extracted correctly.

**Steps to reproduce:**
With mexican localisation installed:
- Open form view for the model 'l10n_mx_edi.document'
- Prepare a payment document in the Payment-20 format (https://www.sat.gob.mx/sitio_internet/cfd/Pagos/Pagos20.xsd)
- Remove existing attachment
- Change attachment on the document to the relatively long XML file

**Issue:**
After saving the change, the attachment_uuid (Fiscal Folio) is left blank.

**Cause:**
Normally, the uuid should be extracted from the uploaded attachment, but the computation of the 'raw' field on the attachment returns the value "b'56.00 bytes'", leaving the attachment_uuid field empty because the XML is assumed to be in the wrong format.
The issue doesn't exist for shorter XML files in the Payment-10 format (https://www.sat.gob.mx/sitio_internet/cfd/Pagos/Pagos10.xsd)

**Solution:**
Before computing the attachment_uuid from the attachment, we set the bin_size to False in the context.

opw-4641487

Orders coming from the same phone number now refresh the customer's name and address when those details change. This helps restaurants and delivery operations keep customer records accurate and avoid sending orders to outdated addresses.

Before this commit:
========================
- The customer name was not updated when an order was received from the same phone number but with a different name.
- If the ZIP code remained the same, changes in the address were not reflected in Odoo.

After this commit:
========================
- The customer name is now updated if it differs, even when the phone number is the same.
- Address updates are now applied in Odoo, even if the ZIP code has not changed.

---
task - 4714559

This fixes an error that could appear when exporting the XML file for the Italian tax return. The export now uses the correct process depending on whether it is run from the tax report or from the closing entry, helping users complete the required filing without interruption.

Since https://github.com/odoo/enterprise/commit/7323435468c8db15cd5643f7d6ecf5928ab2f3dc , a traceback shows up when exporting the xml of the italian tax return. It was fixing a traceback on the closing entry export which was not usable in the report itself an created another issue there.

This fix makes the method chosen depend on wether we are in the report or the closing entry.

no-task

STEPS ------------ 0. You'll require IAP credit for PDF extraction 1. Create 1 POs (we'll call it PO-1) and set the vendor as the current company 2. Duplicate PO-1 (we'll call the duplicate PO-2) and change the amount value of one product 3. Create an invoice with the extact same values as PO-2 and set the customer reference (in the 'Other Info' tab) to "PO-2"; we'll call it INV-1 4. Create a bill and use the Auto-Complete field to manually select PO-1 5. Drag and drop INV-1 in the chatte

STEPS
------------
0. You'll require IAP credit for PDF extraction
1. Create 1 POs (we'll call it PO-1) and set the vendor as the current company
2. Duplicate PO-1 (we'll call the duplicate PO-2) and change the amount value of one product
3. Create an invoice with the extact same values as PO-2 and set the customer reference (in the 'Other Info' tab) to "PO-2"; we'll call it INV-1
4. Create a bill and use the Auto-Complete field to manually select PO-1
5. Drag and drop INV-1 in the chatter -> IAP should trigger -> The chatter says
'''
The invoice already contains lines, it was not updated from the attachment.

'''
but yet, it updated the purchase reference to PO-2 and updated the lines

OBJECTIVE
------------
If a bill has lines, it should not be updated with the content of the PO.

task-4633298

Forward-Port-Of: odoo/enterprise#83336
Forward-Port-Of: odoo/enterprise#83246

https://runbot.odoo.com/odoo/error/163099 This issue became visible as part of the change to test ACLs (removal of demo data, possibly change to groups too) as well as running the "single app tests" on *every module*, not just the apps. The issue is that `self.Requests.user` and `self.employee_user` are unrelated (the amazingly named `self.employee_user` doesn't even have a user). On leave creation, this triggers the rule `hr_leave_rule_employee_update` which checks if: - The current us

https://runbot.odoo.com/odoo/error/163099

This issue became visible as part of the change to test ACLs (removal of demo data, possibly change to groups too) as well as running the "single app tests" on *every module*, not just the apps.

The issue is that `self.Requests.user` and `self.employee_user` are unrelated (the amazingly named `self.employee_user` doesn't even have a user). On leave creation, this triggers the rule `hr_leave_rule_employee_update` which checks if:

- The current user is the employee's, which is not the case because the employee doesn't have a user.
- Or the current user is the employee's leave manager, which is also not the case because the employee does not have a leaves manager.

As a result the creation of the leaves fails immediately.

Fix in 17.4 as the test was introduced in #53940 which was merged in (what would become) 17.3, even though the test setup means it might not be possible to trigger there because of all the demo messing with groups.

Forward-Port-Of: odoo/enterprise#83427

**Steps to reproduce:** - Install Accounting and l10n_pe_edi - Switch to a Peruvian company (e.g. PE Company) - Go to "Settings / Technical / Database Structure / Decimal Accuracy" - Set 4 digits for "Product Price" - Create a product with a lower price than 0.01 (e.g. 0.0045) - Create an invoice: * Customer: [a Peruvian customer] (e.g. Comercial Constructora los Patitos S.A.) * Product: [the created product] * Quantity: 100 - Confirm the invoice - Process the invoice by the E-i

**Steps to reproduce:**
- Install Accounting and l10n_pe_edi
- Switch to a Peruvian company (e.g. PE Company)
- Go to "Settings / Technical / Database Structure / Decimal Accuracy"
- Set 4 digits for "Product Price"
- Create a product with a lower price than 0.01 (e.g. 0.0045)
- Create an invoice:
  * Customer: [a Peruvian customer] (e.g. Comercial Constructora los Patitos S.A.)
  * Product: [the created product]
  * Quantity: 100
- Confirm the invoice
- Process the invoice by the E-invoicing service

**Issue:**
An error is triggered because "PriceTypeCode" is set to "02", which is the code used to declare that it is free.
But in this case, it is not free.

**Cause:**
"PriceTypeCode" is computed by using "is_zero" method of the currency on the unit price.
As the decimal accuracy of the currency is set to 2 and the unit price is 0.0045, "is_zero" is returning True.

**Solution:**
Compute "PriceTypeCode" from the line subtotal instead of the unit price.
This is not perfect as it can also be lower than 0.01, but it's less probable.

opw-4608671

Forward-Port-Of: odoo/enterprise#83401
Forward-Port-Of: odoo/enterprise#82019

The miscellaneous were displayed in the VIES summary report (even if it was rare as it needs to have the field l10n_cz_transaction_code set). A common case would be to create deferred entries with this transaction field set. opw-4688616 Forward-Port-Of: odoo/enterprise#83112

The miscellaneous were displayed in the VIES summary report (even if it was rare as it needs to have the field l10n_cz_transaction_code set).
A common case would be to create deferred entries with this transaction field set.

opw-4688616

Forward-Port-Of: odoo/enterprise#83112