Odoo Changelog — 2026-07-04

Saturday, July 4, 2026

36 changes

Branch: saas-19.4

5 changes

Improvements(1)

Enhancements to existing features

[IMP] point_of_sale: apply removal strategy for tracked products with lots

PR #274066

Coresaas-19.4point_of_salestockMEDIUM

This update streamlines the process of adding tracked products (with lots/serials) to a Point of Sale order. Now, products using FIFO or LIFO removal strategies are automatically added to the cart without requiring users to manually select a lot. This simplifies the checkout process and improves efficiency.

Original PR description

Before this commit:
====
- The lot/serial selection popup was always shown when adding products tracked by lots.

Following this commit:
====
- Products configured with FIFO/LIFO removal strategies are automatically assigned the corresponding lot and added directly to the cart without opening the selection popup.
- If no removal strategy is configured, the existing lot selection behavior is preserved.

task-6226577

Forward-Port-Of: odoo/odoo#273880
Forward-Port-Of: odoo/odoo#265708

#pos#inventory#tracked products#lots#fifo#lifo

Bug Fixes(4)

Resolved issues and error corrections

[FIX] l10n_be_coda: use communication as ref in unstruct cases

PR #122815

Enterprisesaas-19.4l10n_be_codaMEDIUM

Belgian CODA bank statement imports now use the full communication text as the payment reference for unstructured payments. This makes imported transactions easier to identify and match correctly, reducing manual reconciliation work.

Original PR description

### Issue:
When a CODA file was imported, the communication was fetched but it wasn't use as the payment ref
Causing difficulty to match with the transactions

### Cause:
For simplicity reason, the payment_ref and the communication where different
The `payment_ref` was fetched once and replace
The `communication` was always completed by new lines

### Steps to reproduce:
- Install `l10n_be_coda`
- Set the account on the Bank Journal to GR5605700000000928073840752
- Import the Simplied CODA (On the ticket) from the bank dashboard

Before the fix, the ref was just `Liquidation des ventes par carte Mastercard` instead of the full communication that can be found in the chatter

opw-6245848

Forward-Port-Of: odoo/enterprise#122344
Forward-Port-Of: odoo/enterprise#120536

#Belgium#CODA#bank statements#payment matching

[FIX] pos_enterprise: access error when opening Preparation Display app

PR #122957

Enterprisesaas-19.4pos_enterpriseMEDIUM

This fix lets authorized Point of Sale users open the Preparation Display app without hitting an access error. The app now opens the display directly instead of using an intermediate step that required higher permissions than these users have.

Original PR description

A recent fix in the base module requires users to have "write" access on ao model to execute its server actions.
commit: odoo/odoo@846eb51a02baaf2e4f6e6780f8d0ceb23322c38b

Previously, the Preparation Display was opened through the server action `action_pos_preparation_display_kitchen_display`, which then redirected to the URL action `action_pos_preparation_display_bar_restaurant_filter_link`.

However, PS users only have read access on `pos.prep.display`. As a result, executing the server action triggers an access error when opening the Preparation Display.

This commit bypasses the intermediate server action and opens the URL action directly.

Task-6311320

Forward-Port-Of: odoo/enterprise#121293

#point-of-sale#preparation-display#access

[FIX] stock_barcode{,_product_expiry}: convert line qty to move uom qty barcode

PR #122918

Enterprisesaas-19.4stock_barcodestock_barcode_product_expiryMEDIUM

This fixes an issue where receipt quantities could be reduced incorrectly after using the barcode screen with packaged units of measure, such as packs of six. Businesses can rely on inventory receipts to keep the correct total quantity when products are handled in alternate units.

Original PR description

**Steps to reproduce:** - Install `stock` and `purchase` modules - Enable `Units of Measure and Packages` and `Storage Locations` from setting - Create a storable product with vendor purchase UoM set…

**Steps to reproduce:**
- Install `stock` and `purchase` modules
- Enable `Units of Measure and Packages`  and `Storage Locations` from setting
- Create a storable product with vendor purchase UoM set to "Pack of 6"
- Create and confirm a Purchase Order with quantity 6 Units
- Open the generated receipt
- Update a move line in Detailed Operations:
  - Quantity: 1
  - UoM: Pack of 6
- Save and open the Barcode view using smart button.
- Increase quantity using "+" button by 1.
- Exit barcode view without validating and refresh the receipt

**Issue:**
After refresh, the stock move quantity becomes 1 instead of 6,
while the move line correctly shows 1 Pack of 6.

**Cause:**

https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/static/src/components/main.js#L161-L162

- Exiting the barcode view triggers `__onExit()`, which forwards
`reserved_uom_qty` and `qty_done` from move lines to
`post_barcode_process()`.
https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/static/src/models/barcode_picking_model.js#L1885-L1898

This `post_barcode_process()` function triggers `_truncate_overreserved_moves()`
https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/models/stock_move.py#L56-L58

- During this flow, `_truncate_overreserved_moves()` updates the stock move quantity
by taking the maximum of `qty_done` and `reserved_uom_qty`. However, it assigns
this value directly to the move without converting it into the stock move UoM.

- In this case, both values are 1 because the move line is UoM is "Pack of 6"
Logically, 1 Pack corresponds to 6 units, but since the stock move UoM is in units,
this conversion is skipped. As a result, the move quantity is incorrectly set to 1
instead of 6.

https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/models/stock_move.py#L52-L54

**Fix:**

- Convert quantities coming from barcode processing into the stock
move UoM before updating the move quantity, ensuring packaged
UoM values are preserved correctly.

----

opw-5472598

Forward-Port-Of: odoo/enterprise#122769
Forward-Port-Of: odoo/enterprise#116022

#inventory#barcode#units-of-measure#receipts

[FIX] pos_discount: format global discount with locale decimal separator

PR #273918

Coresaas-19.4pos_discountMEDIUM

This update corrects a bug where global discount percentages displayed in Dutch (and similar locales) were incorrectly calculated in the Point of Sale system. The fix ensures that discounts are applied accurately, preventing orders from being incorrectly discounted to 100% when using the Dutch locale.

Original PR description

When using Dutch (or similar locales where the decimal separator is a comma), a configured global discount percentage with decimals is misapplied in POS. For example, a default discount of 8,33% is…

When using Dutch (or similar locales where the decimal separator is a comma), a configured global discount percentage with decimals is misapplied in POS. For example, a default discount of 8,33% is shown in the discount popup as 8.33% and, when confirmed without editing, applies a 100% discount on the order instead of 8,33%.

Steps to reproduce:
-------------------
* Activate Belgian localization for accounting
* Set the user language to Dutch (Netherlands) or Dutch (Belgium)
* In Point of Sale settings, enable global discounts and set the default discount percentage to 8,33%
* Open a POS session, add a product to the cart, and click Discount
* Confirm the popup without changing the value

> Observation:
The popup displays 8.33% (with a dot). After confirmation, the order receives a full discount instead of 8,33%.

Why the fix:
------------
The discount popup initialized its value with `String(discount_pc)`, which always uses a dot as decimal separator. POS then parses the input with locale-aware rules where `.` is the thousands separator, so "8.33" is read as 833 and capped to 100%. Format the default discount percentage with `formatFloat` so the popup starts with the correct localized value (e.g. "8,33").

opw-6334367

Forward-Port-Of: odoo/odoo#273594
Forward-Port-Of: odoo/odoo#273022

#POS#discount#localization#Dutch

Branch: saas-19.3

5 changes

Bug Fixes(5)

Resolved issues and error corrections

[FIX] stock_barcode{,_product_expiry}: convert line qty to move uom qty barcode

PR #122904

Enterprisesaas-19.3stock_barcodestock_barcode_product_expiryMEDIUM

Fixes an issue where leaving the Barcode view could reduce a receipt quantity when products were handled in packs instead of individual units. Quantities are now converted correctly, helping keep inventory receipts accurate and preventing understated stock levels.

Original PR description

**Steps to reproduce:**
- Install `stock` and `purchase` modules
- Enable `Units of Measure and Packages`  and `Storage Locations` from setting
- Create a storable product with vendor purchase UoM set to "Pack of 6"
- Create and confirm a Purchase Order with quantity 6 Units
- Open the generated receipt
- Update a move line in Detailed Operations:
  - Quantity: 1
  - UoM: Pack of 6
- Save and open the Barcode view using smart button.
- Increase quantity using "+" button by 1.
- Exit barcode view without validating and refresh the receipt

**Issue:**
After refresh, the stock move quantity becomes 1 instead of 6,
while the move line correctly shows 1 Pack of 6.

**Cause:**

https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/static/src/components/main.js#L161-L162

- Exiting the barcode view triggers `__onExit()`, which forwards
`reserved_uom_qty` and `qty_done` from move lines to
`post_barcode_process()`.
https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/static/src/models/barcode_picking_model.js#L1885-L1898

This `post_barcode_process()` function triggers `_truncate_overreserved_moves()`
https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/models/stock_move.py#L56-L58

- During this flow, `_truncate_overreserved_moves()` updates the stock move quantity
by taking the maximum of `qty_done` and `reserved_uom_qty`. However, it assigns
this value directly to the move without converting it into the stock move UoM.

- In this case, both values are 1 because the move line is UoM is "Pack of 6"
Logically, 1 Pack corresponds to 6 units, but since the stock move UoM is in units,
this conversion is skipped. As a result, the move quantity is incorrectly set to 1
instead of 6.

https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/models/stock_move.py#L52-L54

**Fix:**

- Convert quantities coming from barcode processing into the stock
move UoM before updating the move quantity, ensuring packaged
UoM values are preserved correctly.

----

opw-5472598

Forward-Port-Of: odoo/enterprise#122769
Forward-Port-Of: odoo/enterprise#116022

#barcode#inventory#units-of-measure#receipts

[FIX] l10n_be_coda: use communication as ref in unstruct cases

PR #122775

Enterprisesaas-19.3l10n_be_codaMEDIUM

Belgian CODA bank imports now use the full payment communication as the reference when transactions have unstructured communication. This makes imported bank transactions easier to identify and match with the correct payments or invoices.

Original PR description

### Issue:
When a CODA file was imported, the communication was fetched but it wasn't use as the payment ref
Causing difficulty to match with the transactions

### Cause:
For simplicity reason, the payment_ref and the communication where different
The `payment_ref` was fetched once and replace
The `communication` was always completed by new lines

### Steps to reproduce:
- Install `l10n_be_coda`
- Set the account on the Bank Journal to GR5605700000000928073840752
- Import the Simplied CODA (On the ticket) from the bank dashboard

Before the fix, the ref was just `Liquidation des ventes par carte Mastercard` instead of the full communication that can be found in the chatter

opw-6245848

Forward-Port-Of: odoo/enterprise#122344
Forward-Port-Of: odoo/enterprise#120536

#bank-import#CODA#Belgium#payment-matching

[FIX] pos_enterprise: access error when opening Preparation Display app

PR #122946

Enterprisesaas-19.3pos_enterpriseMEDIUM

The Preparation Display app now opens directly instead of using an intermediate action that required extra permissions. This prevents certain point-of-sale users from being blocked by an access error, helping kitchen and restaurant workflows continue smoothly.

Original PR description

A recent fix in the base module requires users to have "write" access on ao model to execute its server actions.
commit: odoo/odoo@846eb51a02baaf2e4f6e6780f8d0ceb23322c38b

Previously, the Preparation Display was opened through the server action `action_pos_preparation_display_kitchen_display`, which then redirected to the URL action `action_pos_preparation_display_bar_restaurant_filter_link`.

However, PS users only have read access on `pos.prep.display`. As a result, executing the server action triggers an access error when opening the Preparation Display.

This commit bypasses the intermediate server action and opens the URL action directly.

Task-6311320

Forward-Port-Of: odoo/enterprise#121293

#point-of-sale#preparation-display#access-error

[FIX] pos_hr: Miscellaneous "Scan Badge to Login" fixes in PoS

PR #274259

Coresaas-19.3pos_hrMEDIUM

This update fixes issues preventing barcode scans of employee badges from correctly logging users into the Point of Sale (PoS) system. Specifically, it ensures that scanning a badge triggers the correct PIN entry and correctly switches cashiers when scanning another employee's badge. This improves the user experience and streamlines the login process for PoS staff.

Original PR description

See commit messages.

[[FIX] pos_hr: scanning badge should work with PIN input focused](https://github.com/odoo/odoo/commit/95d9329674e81b2659445e2021a35b21bbbc81a3)

[[FIX] point_of_sale: scanning a badge should not auto confirm the PIN](https://github.com/odoo/odoo/commit/d59fb1f6fe27d117579b3945c5bba400d17d0014)
(Note: this is only needed up to saas-18.4 included -- 19.0 already has this diff)

[[FIX] pos_hr: scanning another cashier's badge switches to that cashier](https://github.com/odoo/odoo/commit/c812fe596694b16a494e3dcf908d17f621f7ce92)

opw-6125029

Forward-Port-Of: odoo/odoo#273838
Forward-Port-Of: odoo/odoo#262474

#pos#login#employee badge

[PERF] point_of_sale: batch split bank payments on session close

PR #274258

Coresaas-19.3point_of_saleMEDIUM

This update significantly speeds up the process of closing a Point of Sale session, particularly when using 'Identify Customer' for bank payments. Previously, closing a session with many payments could take over 10 minutes, but now it completes in approximately 75 seconds. This improves efficiency and reduces delays for users.

Original PR description

Steps to reproduce
------------------
1. On a bank payment method, enable "Identify Customer".
2. Create a lot of orders paid with this method (the client reporting the issue had 1700), and put a customer on each order.
3. Close the session.

With "Identify Customer" enabled, closing the session creates one `account.payment` for each payment and posts it one by one, then reconciles each payment separately. With many payments this is slow and the close takes several minutes and the worker is stopped by its time limit, so we get the error "Cursor already closed".

Now we create and post all these payments at once in a single batch, and reconcile the payments in one call too.

Benchmark
---------
These numbers come from closing a session that has 1700 orders paid with such a payment method, on a test database:
- before: the close did not finish after more than 10 minutes.
- after: the close takes around 75 seconds.

opw-6242303

Forward-Port-Of: odoo/odoo#269306

#performance#pos#payments

Branch: saas-19.2

4 changes

Bug Fixes(4)

Resolved issues and error corrections

[FIX] l10n_be_coda: use communication as ref in unstruct cases

PR #122668

Enterprisesaas-19.2l10n_be_codaMEDIUM

Belgian CODA bank imports now use the full payment communication as the payment reference when the communication is unstructured. This makes imported bank transactions easier to identify and match correctly, reducing manual reconciliation work.

Original PR description

### Issue:
When a CODA file was imported, the communication was fetched but it wasn't use as the payment ref
Causing difficulty to match with the transactions

### Cause:
For simplicity reason, the payment_ref and the communication where different
The `payment_ref` was fetched once and replace
The `communication` was always completed by new lines

### Steps to reproduce:
- Install `l10n_be_coda`
- Set the account on the Bank Journal to GR5605700000000928073840752
- Import the Simplied CODA (On the ticket) from the bank dashboard

Before the fix, the ref was just `Liquidation des ventes par carte Mastercard` instead of the full communication that can be found in the chatter

opw-6245848

Forward-Port-Of: odoo/enterprise#122344
Forward-Port-Of: odoo/enterprise#120536

#bank-import#reconciliation#belgium#CODA

[FIX] pos_enterprise: access error when opening Preparation Display app

PR #122945

Enterprisesaas-19.2pos_enterpriseMEDIUM

The Preparation Display app now opens directly instead of using an intermediate action that required extra permissions. This prevents point-of-sale users with standard read-only access from being blocked by an access error.

Original PR description

A recent fix in the base module requires users to have "write" access on ao model to execute its server actions.
commit: odoo/odoo@846eb51a02baaf2e4f6e6780f8d0ceb23322c38b

Previously, the Preparation Display was opened through the server action `action_pos_preparation_display_kitchen_display`, which then redirected to the URL action `action_pos_preparation_display_bar_restaurant_filter_link`.

However, PS users only have read access on `pos.prep.display`. As a result, executing the server action triggers an access error when opening the Preparation Display.

This commit bypasses the intermediate server action and opens the URL action directly.

Task-6311320

Forward-Port-Of: odoo/enterprise#121293

#point-of-sale#preparation-display#access

[FIX] sign: lock PDF form fields

PR #122914

Enterprisesaas-19.2signMEDIUM

PDF form fields are now locked during the signing process instead of being flattened in a way that could change how the document looks. This preserves the original PDF appearance for signers while ensuring fields cannot be edited once signing is underway.

Original PR description

Currently, we flatten fields in a naive way which does not handle many edge cases and can alter the PDF appearance for users. We could use pypdf to handle production-grade flattening, but Odoo's `pypdf` dependency (5.4.0) does not support native form field flattening (which was introduced in 5.8.0).

To resolve this, rather than flattening, we lock the interactive fields so they are no longer editable while signing, which perfectly maintains the original appearance. In the future, when we support higher pypdf versions, we can truly flatten the PDF to provide a better user experience.

task-6037759

Forward-Port-Of: odoo/enterprise#112351

#pdf#signatures#documents

[FIX] pos_hr: Miscellaneous "Scan Badge to Login" fixes in PoS

PR #274256

Coresaas-19.2pos_hrMEDIUM

This update fixes issues preventing badge scanning from correctly logging users into Point of Sale (PoS) sessions. Specifically, it ensures badge scans work with PIN input and correctly switches cashiers when scanning another employee's badge. These changes improve the user experience and reliability of the PoS login process.

Original PR description

See commit messages.

[[FIX] pos_hr: scanning badge should work with PIN input focused](https://github.com/odoo/odoo/commit/95d9329674e81b2659445e2021a35b21bbbc81a3)

[[FIX] point_of_sale: scanning a badge should not auto confirm the PIN](https://github.com/odoo/odoo/commit/d59fb1f6fe27d117579b3945c5bba400d17d0014)
(Note: this is only needed up to saas-18.4 included -- 19.0 already has this diff)

[[FIX] pos_hr: scanning another cashier's badge switches to that cashier](https://github.com/odoo/odoo/commit/c812fe596694b16a494e3dcf908d17f621f7ce92)

opw-6125029

Forward-Port-Of: odoo/odoo#273838
Forward-Port-Of: odoo/odoo#262474

#pos#login#scanning#cashier

Branch: saas-19.1

12 changes

Bug Fixes(12)

Resolved issues and error corrections

[FIX] documents_project: keep project folders out of the trash GC

PR #122323

Enterprisesaas-19.1documents_projectMEDIUM

Archived document folders that are linked to projects are now excluded from automatic trash cleanup. This prevents cleanup jobs from failing and keeps project document access working correctly, including when viewing archived project folders.

Original PR description

## Problem

  When a folder linked to a project gets archived, the documents trash autovacuum unlinks it along with regular trash. That triggers the constrains . This happens whether the project is still active or also archived.

  ## Fix

  Add one leaf on the GC domain: `('project_ids', '=', False)`.  so the document is not deleted if linked to a project

Forward-Port-Of: odoo/enterprise#117692

#documents#projects#trash#archived-folders

[FIX] industry_fsm_sale: fix project creation issue via sale order

PR #114523

Enterprisesaas-19.1industry_fsm_saleMEDIUM

Confirmed sale orders that create field service projects now assign the delivery address as the project customer. Creating projects from field service templates also avoids an incorrect default sales line, preventing setup errors.

Original PR description

FIX 1: industry_fsm_sale: set delivery address on project customer] ----------------------- **Steps to reproduce:** - Create a product: - Product Type: Service - Service Tracking: Create on Order…

FIX 1:  industry_fsm_sale: set delivery address on project customer]
-----------------------
**Steps to reproduce:**
- Create a product:
   - Product Type: Service
   - Service Tracking: Create on Order (project)
   -  Project Template: FSM type project template
- Confirm a sale order with this product
- Check the generated project customer

**Issue:**
   The customer's delivery address is not set on the generated project.

**Fix:**
  Set the delivery address as the project customer when creating the project.

[FIX] industry_fsm_sale: remove default sale line in fsm projects
------------
**Steps to reproduce:**
   - Install industry_fsm_sale
   - Create a project template of fsm type
   - Create a sale order (service-type product)
   - Confirm the sale order
   - Create a project and select the fsm-type project template
   - Create the project

**Issue:**
  - SQL constraint is triggered, preventing project creation.

**Fix:**
  - If the project template is of fsm type, remove the default sale line from the context.

task-5074893

Forward-Port-Of: odoo/enterprise#95920

#field-service#sales-orders#project-creation#customer-address

[FIX] l10n_be_coda: use communication as ref in unstruct cases

PR #122593

Enterprisesaas-19.1l10n_be_codaMEDIUM

Belgian CODA bank imports now use the full payment communication as the transaction reference when no structured reference is available. This makes imported bank transactions easier to identify and match, reducing manual reconciliation effort.

Original PR description

### Issue:
When a CODA file was imported, the communication was fetched but it wasn't use as the payment ref
Causing difficulty to match with the transactions

### Cause:
For simplicity reason, the payment_ref and the communication where different
The `payment_ref` was fetched once and replace
The `communication` was always completed by new lines

### Steps to reproduce:
- Install `l10n_be_coda`
- Set the account on the Bank Journal to GR5605700000000928073840752
- Import the Simplied CODA (On the ticket) from the bank dashboard

Before the fix, the ref was just `Liquidation des ventes par carte Mastercard` instead of the full communication that can be found in the chatter

opw-6245848

Forward-Port-Of: odoo/enterprise#122344
Forward-Port-Of: odoo/enterprise#120536

#CODA#bank-import#reconciliation#Belgium

[FIX] sign: lock PDF form fields

PR #122882

Enterprisesaas-19.1signMEDIUM

Signing now preserves the original look of PDFs by locking existing interactive form fields instead of flattening them in a way that could change their appearance. This prevents users from editing those fields during signing while reducing the risk of visual issues in signed documents.

Original PR description

Currently, we flatten fields in a naive way which does not handle many edge cases and can alter the PDF appearance for users. We could use pypdf to handle production-grade flattening, but Odoo's `pypdf` dependency (5.4.0) does not support native form field flattening (which was introduced in 5.8.0).

To resolve this, rather than flattening, we lock the interactive fields so they are no longer editable while signing, which perfectly maintains the original appearance. In the future, when we support higher pypdf versions, we can truly flatten the PDF to provide a better user experience.

task-6037759

Forward-Port-Of: odoo/enterprise#112351

#pdf#signing#documents

[FIX] pos_enterprise: access error when opening Preparation Display app

PR #122880

Enterprisesaas-19.1pos_enterpriseMEDIUM

Users with limited permissions can now open the Preparation Display app without seeing an access error. The app now opens the display page directly, avoiding an extra step that required permissions those users do not have.

Original PR description

A recent fix in the base module requires users to have "write" access on ao model to execute its server actions.
commit: odoo/odoo@846eb51a02baaf2e4f6e6780f8d0ceb23322c38b

Previously, the Preparation Display was opened through the server action `action_pos_preparation_display_kitchen_display`, which then redirected to the URL action `action_pos_preparation_display_bar_restaurant_filter_link`.

However, PS users only have read access on `pos.prep.display`. As a result, executing the server action triggers an access error when opening the Preparation Display.

This commit bypasses the intermediate server action and opens the URL action directly.

Task-6311320

Forward-Port-Of: odoo/enterprise#121293

#point of sale#preparation display#access error

[FIX] timesheet_grid: fix timesheet unavailabilities

PR #122932

Enterprisesaas-19.1timesheet_gridMEDIUM

The timesheet view now correctly marks days as unavailable based on the current employee's working schedule when users open their own timesheets. This prevents employees from accidentally entering time on days they are not scheduled to work.

Original PR description

To reproduce:
=============
- modify Mitchel Admin's working schedule and remove a day of work
- open timesheet app as Mitchel Admin
- the removed day is not grayed out as unavailable

Porblem:
========
the method `get_unavailabily` was handling only the case when calling it with `groupby=employee_id` otherwise it returns the company's unvailability

Solution:
=========
when the "My Timesheet" action is opened, the method `get_unavailabily`
is now called with a specific context key, allowing to return the current
user's unavailability instead of the company's one.

opw-5949236

Forward-Port-Of: odoo/enterprise#122720
Forward-Port-Of: odoo/enterprise#113984

#timesheets#scheduling#availability

[FIX] {,website_}mass_mailing: use recipient base URL for unsubscribe

PR #273888

Coresaas-19.1mass_mailingwebsite_mass_mailingwebsite_mass_mailing_smsMEDIUM

This fix ensures that mass mailing unsubscribe links direct recipients to the correct website based on their company affiliation. Previously, the links pointed to the main company's login page, regardless of the contact's company. This update corrects the URL generation process, guaranteeing accurate redirection for a better user experience.

Original PR description

In a multi-company setup with a website per company, the unsubscribe link in mass mailing emails could send recipients to the login page instead of the unsubscribe confirmation page. ### Steps to…

In a multi-company setup with a website per company, the unsubscribe link in mass mailing emails could send recipients to the login page instead of the unsubscribe confirmation page.

### Steps to reproduce

1. Enable multi-company and create a second company `Company B`.
2. Create two websites with different domains, one per company:
- `Website A` on the main company, domain `http://website-a.test`
- `Website B` on `Company B`, domain `http://website-b.test`
3. Set the system parameter `web.base.url` to `http://website-a.test`. System parameters are global, so this value applies to the whole database regardless of the company you switch to.
4. Create a contact and set its `Company` field to `Company B`.
5. In Email Marketing, create a mailing with recipient model `Contact`, target the contact above, pick any template with an unsubscribe link, and send it.
6. Open the email in an incognito window and click the unsubscribe link: you land on the login page instead of the unsubscribe page.

### Cause

Mass mailing builds the unsubscribe link in two steps.

First, each email body is rendered for its recipient. While rendering, relative URLs like `/unsubscribe_from_list` are turned into absolute URLs by prepending a base URL. That base URL comes from the recipient record itself: `recipient.get_base_url()`. The `website` module overrides this so that, when the record has a company, it returns that company's website domain. For a contact in `Company B`, the body ends up with `http://website-b.test/unsubscribe_from_list`.

Second, right before sending, `mail_mail._prepare_outgoing_list` replaces that placeholder URL with a per-recipient signed URL pointing to `/confirm_unsubscribe`. It does this by plain string replacement: it looks for `{base_url}/unsubscribe_from_list` in the body and swaps it. The `base_url` used here came from `self.mailing_id.get_base_url()`. A mailing has no company, so its base URL falls back to the global `web.base.url`, which in our setup is `http://website-a.test`.

The two base URLs no longer match. The body contains the website B URL, but the replacement code searches for the website A URL. The search fails, the placeholder stays in the email, and the recipient clicks a link to `/unsubscribe_from_list`. That route only redirects to `/mailing/my`, which requires being logged in, so the user lands on the login page.

### Fix

Compute the base URL from the recipient record (the same record used when rendering the body) instead of the mailing. The two URLs then agree and the replacement works. Fall back to the mailing's base URL if there is no recipient model on the mail.

opw-4914203

Forward-Port-Of: odoo/odoo#273583
Forward-Port-Of: odoo/odoo#264055

#email marketing#multi-company#unsubscribe

[FIX] web: don't close dialogs opened from a kanban quick create on tab switch

PR #274054

Coresaas-19.1webMEDIUM

This update fixes an issue where dialogs opened from Kanban quick creates would unexpectedly close when switching tabs. Now, dialogs remain open and functional, ensuring a smoother user experience when navigating between Kanban views and creating related records. This enhances usability and prevents data loss.

Original PR description

similar fix: https://github.com/odoo/odoo/pull/181220 - On a kanban view, click "New" to open a quick create record; - On a many2one field, type a value and click "Create and edit..."; - A dialog…

similar fix: https://github.com/odoo/odoo/pull/181220

- On a kanban view, click "New" to open a quick create record;
- On a many2one field, type a value and click "Create and edit...";
- A dialog opens to create the related record;
- From that dialog, open another many2one field the same way, so a second dialog opens on top of the first one;
- Change tab in the browser.

Before this commit, the quick create's `beforeVisibilityChange` handler unconditionally validated and closed itself as soon as the tab became hidden, with no regard for what was happening around it. Since the "Create and edit" dialogs are owned by the field widgets living inside the quick create (`useOwnedDialogs`), closing the quick create also close those dialogs, with no action from the user.

This reuses the `formInDialog` counter already relied on by `FormController` for the same kind of issue: the quick create now listens to the same `FORM-CONTROLLER:FORM-IN-DIALOG` bus events, and only validates/closes itself on visibility change once every dialog opened from it has been closed.

opw-6357255

#kanban#dialog#user experience

[FIX] sale_project: fix project creation issue via sale order

PR #260496

Coresaas-19.1sale_projectcrm_sale_projectprojectMEDIUM

This update fixes issues where project templates weren't correctly associated with sale orders and allowed selection from incorrect companies. It now ensures project templates are displayed based on the sale order's company or are universally available, improving project creation workflows and data accuracy. This resolves inconsistencies in how project templates were presented.

Original PR description

Fix 1 : project, sale_timesheet: remove default_allow_billable context in Create a Project --------------------- **Issue:** When a project is created from the sale app, it is not billable by default,…

Fix 1 : project, sale_timesheet: remove default_allow_billable context in Create a Project
---------------------
**Issue:**
  When a project is created from the sale app, it is not billable by default, and the sale order / sale order line are not set.

**Fix:**
 Remove default_allow_billable = False in the Create a Project

**Note:**
  default_allow_billable = True already exists in action_view_project_ids, but that default context is replaced when opening the project directly from the view. This happens because default_allow_billable = False is set in the Create a Project
  action.

Fix 2: sale_project: show only relevant project templates per company
----------------
**Steps:**
   - Install sale_project
   - Create two companies (A, B)
   - Create three project templates:
	 - Template A (company A)
	 - Template B (company B)
	 - Template C (no company → visible to all)
   - Create a sale order for company A with a service product
   - Confirm the sale order
   - Create a project and try to select a template

**Issue:**
   All project templates were visible even if the sale order had a company set.

**Fix:**
   Added a filter (domain) on the project template field so only templates for the sale order’s company or templates with   no company are shown. Users cannot select templates from other companies.

fix 3 : crm_sale_project: show only relevant project templates per company
--------------------------------------------------------------------------------
Steps:
   - Install crm_sale_project
   - Create two companies (A, B)
   - Create three project templates:
	 - Template A (company A)
	 - Template B (company B)
	 - Template C (no company → visible to all)
   - Create a lead for company A
   - Create a project and try to select a template

Issue:
   All project templates were visible even if the lead had a company set.

Fix:
   Added a filter (domain) on the project template field so only templates
   for the lead’s company or templates with no company are shown.
   Users cannot select templates from other companies.
task-5074893

Forward-Port-Of: odoo/odoo#229309

#project#template#sale order#company

[FIX] pos_online_payment: sync order when re-adding online payment

PR #274053

Coresaas-19.1pos_online_paymentMEDIUM

This update fixes an issue where increasing the amount of an online payment didn't correctly update the order on the server. Now, adding an online payment line automatically syncs the order, ensuring the customer's payment information is always accurate and up-to-date.

Original PR description

When an online payment line is added, the order is synced to the server so the customer can pay it online. This sync was only performed when the order did not yet exist on the server (string id). As a result, once an order had already been synced, modifying it (e.g. increasing the amount) and adding the online payment line again did not push the new amount to the server.

opw-6314690

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

Forward-Port-Of: odoo/odoo#272961
Forward-Port-Of: odoo/odoo#271542

#payment#online#order

[PERF] point_of_sale: batch split bank payments on session close

PR #274143

Coresaas-19.1point_of_saleMEDIUM

This update significantly improves the speed of closing Point of Sale sessions, particularly when using 'Identify Customer' for bank payments. Previously, closing a session with many payments could take over 10 minutes, but now it completes in approximately 75 seconds. This change reduces processing time and improves overall system performance.

Original PR description

Steps to reproduce
------------------
1. On a bank payment method, enable "Identify Customer".
2. Create a lot of orders paid with this method (the client reporting the issue had 1700), and put a customer on each order.
3. Close the session.

With "Identify Customer" enabled, closing the session creates one `account.payment` for each payment and posts it one by one, then reconciles each payment separately. With many payments this is slow and the close takes several minutes and the worker is stopped by its time limit, so we get the error "Cursor already closed".

Now we create and post all these payments at once in a single batch, and reconcile the payments in one call too.

Benchmark
---------
These numbers come from closing a session that has 1700 orders paid with such a payment method, on a test database:
- before: the close did not finish after more than 10 minutes.
- after: the close takes around 75 seconds.

opw-6242303

Forward-Port-Of: odoo/odoo#269306

#performance#pos#payments

[FIX] pos_hr: Miscellaneous "Scan Badge to Login" fixes in PoS

PR #274159

Coresaas-19.1pos_hrMEDIUM

This update fixes issues where scanning employee badges during login wasn't working correctly, specifically when using a PIN. The changes ensure that badge scans are properly recognized as PIN inputs, allowing users to seamlessly log in with their badges and resolve 'Wrong PIN' errors. This improves the overall login experience for PoS employees.

Original PR description

See commit messages.

[[FIX] pos_hr: scanning badge should work with PIN input focused](https://github.com/odoo/odoo/commit/95d9329674e81b2659445e2021a35b21bbbc81a3)

[[FIX] point_of_sale: scanning a badge should not auto confirm the PIN](https://github.com/odoo/odoo/commit/d59fb1f6fe27d117579b3945c5bba400d17d0014)
(Note: this is only needed up to saas-18.4 included -- 19.0 already has this diff)

[[FIX] pos_hr: scanning another cashier's badge switches to that cashier](https://github.com/odoo/odoo/commit/c812fe596694b16a494e3dcf908d17f621f7ce92)

opw-6125029

Forward-Port-Of: odoo/odoo#273838
Forward-Port-Of: odoo/odoo#262474

#pos#login#employee badge

Branch: saas-18.4

1 change

Bug Fixes(1)

Resolved issues and error corrections

[FIX] l10n_be_coda: use communication as ref in unstruct cases

PR #122498

Enterprisesaas-18.4l10n_be_codaMEDIUM

Belgian CODA bank imports now use the full payment communication as the payment reference when the communication is unstructured. This helps businesses match imported bank transactions more accurately and reduces manual reconciliation work.

Original PR description

### Issue:
When a CODA file was imported, the communication was fetched but it wasn't use as the payment ref
Causing difficulty to match with the transactions

### Cause:
For simplicity reason, the payment_ref and the communication where different
The `payment_ref` was fetched once and replace
The `communication` was always completed by new lines

### Steps to reproduce:
- Install `l10n_be_coda`
- Set the account on the Bank Journal to GR5605700000000928073840752
- Import the Simplied CODA (On the ticket) from the bank dashboard

Before the fix, the ref was just `Liquidation des ventes par carte Mastercard` instead of the full communication that can be found in the chatter

opw-6245848

Forward-Port-Of: odoo/enterprise#122344
Forward-Port-Of: odoo/enterprise#120536

#Belgium#CODA#bank import#payment matching

Branch: saas-18.3

4 changes

Improvements(1)

Enhancements to existing features

[IMP] l10n_uk_reports: tax return filing to HMRC from the tax unit

PR #122908

Enterprisesaas-18.3l10n_uk_reportsMEDIUM

UK VAT returns now warn users when their company belongs to a tax unit and guide them to file from that tax unit. When a return covers a tax unit, the tax unit's VAT number is used for HMRC connection and submission, reducing filing errors.

Original PR description

BEFORE:
- Before this commit, when the current company is a member of the tax unit, there is no blocking level error for the user to select the tax unit.
- And the vat used while creating a connection to the HMRC or while sending a tax report to the HMRC is of the current company.

AFTER:
- After this commit, there is one blocking level error, which tells the user that the current company is part of a tax unit, and on confirmation, the tax unit will automatically be selected for the current report.
- And if the return contains the data of a tax unit, then the vat set on the tax unit will be considered while establishing the connection and sending the tax report to HMRC.

Task-5865605

Forward-Port-Of: odoo/enterprise#107253

#uk#vat#hmrc#tax-unit

Bug Fixes(3)

Resolved issues and error corrections

[PERF] point_of_sale: batch split bank payments on session close

PR #273917

Coresaas-18.3point_of_saleMEDIUM

This update significantly improves the speed of closing Point of Sale sessions, particularly when multiple bank payments are involved. Previously, closing a session with many payments could take over 10 minutes, but now it completes in approximately 75 seconds. This enhancement reduces operational delays and improves the overall efficiency of the POS system.

Original PR description

Steps to reproduce
------------------
1. On a bank payment method, enable "Identify Customer".
2. Create a lot of orders paid with this method (the client reporting the issue had 1700), and put a customer on each order.
3. Close the session.

With "Identify Customer" enabled, closing the session creates one `account.payment` for each payment and posts it one by one, then reconciles each payment separately. With many payments this is slow and the close takes several minutes and the worker is stopped by its time limit, so we get the error "Cursor already closed".

Now we create and post all these payments at once in a single batch, and reconcile the payments in one call too.

Benchmark
---------
These numbers come from closing a session that has 1700 orders paid with such a payment method, on a test database:
- before: the close did not finish after more than 10 minutes.
- after: the close takes around 75 seconds.

opw-6242303

Forward-Port-Of: odoo/odoo#269306

#performance#pos#payments

[PERF] account: optimize _compute_made_sequence_gap

PR #274182

Coresaas-18.3accountMEDIUM

This update optimizes how Odoo identifies gaps in move sequence numbers, leading to significantly faster processing. The previous method was inefficient, consuming excessive resources when checking for sequence gaps. This change improves overall system performance and responsiveness.

Original PR description

The function _compute_made_sequence_gap is designed to determine if an updated move created a sequence gap. This is currently done with several performance issues. Firstly, the search domain simply…

The function _compute_made_sequence_gap is designed to determine if an updated move created a sequence gap. This is currently done with several performance issues.

Firstly, the search domain simply uses a min/max sequence number of the updated moves. However, we only ever need the sequence number that comes before each changed move.

Example:
Let's say we updated 3 moves.
Move A: sequence_number = 27
Move B: sequence_number = 235
Move C: sequence_number = 100342

The search domain then becomes:
('sequence_number', '>=', min(moves.mapped('sequence_number')) - 1),
('sequence_number', '<=', max(moves.mapped('sequence_number')) - 1),

('sequence_number', '>=', 26),
('sequence_number', '<=', 100341),

The search domain can now return up to 100315 moves! Since we then loop over each updated move (Move A,B,C) and check if the previous sequence number exists, we are never using 100312 of the records from the search.

Instead, we can compute what sequence numbers we are looking for ahead of time, and specifically search for those.

We can also convert this to a search_read to retrieve only sequence_number.

|  | Two Moves 35,000 apart | 1000 sequential moves |
| --------- | ------ | ------ | 
| Queries Before |129 | 4,300|
| Queries After | 24|4,291|
| Time Before |0.90 seconds |2.92 seconds|
| Time After | 0.11 seconds|2.69 seconds|

opw-6330731

Forward-Port-Of: odoo/odoo#273124

#performance#optimization#account

[FIX] l10n_cz: update TSD while reversing an invoice

PR #274060

Coresaas-18.3l10n_czMEDIUM

This update resolves an issue where reversing invoices with credit notes in the Czech localization (l10n_cz) didn't correctly update the Taxable Supply Date (TSD). The fix ensures the TSD is accurately reflected during the reversal process, aligning with accounting requirements. This improvement impacts invoice accuracy and reporting for Czech-based businesses.

Original PR description

### Issue before this commit: When reversing an invoice with a credit note in the l10n_cz and l10n_sk only the invoice_date is updated with the reversal_date but not the TSD date. ### Steps to…

### Issue before this commit:
When reversing an invoice with a credit note in the l10n_cz and l10n_sk only the invoice_date is updated with the reversal_date but not the TSD date.

### Steps to reproduce the issue:
1. Download Accounting and l10n_cz (same steps can be done for l10n_sk)
2. Go to invoices and put as not invisible the Accounting Date field
3. Create and post the invoice setting as Taxable Supply Date (TSD) a previous date
4. Create a credit note for the invoice with reversal date as today for example and then click Reverse
5. See the dates (as taxable supply date and accounting date) are not updated

### Cause of the issue:
Prior to version 19, the taxable_supply_date (TSD) was a localization-specific field and did not exist in the core account.move model. Consequently, when the reverse_moves method:
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/account/wizard/account_move_reversal.py#L110-L174
executed, the accounting date was recomputed but the TSD was left unhandled. Thanks to PR https://github.com/odoo/odoo/pull/225035, which natively integrates this field into the core account module in version 19, the fields are now properly aligned and the issue is no longer reproducible.

### Reason to introduce the fix:
The fix explicitly populates taxable_supply_date with the wizard's reverse_date during the reversal preparation process.

opw-6102869

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

Forward-Port-Of: odoo/odoo#265016

#accounting#czech#tsd#reversal

Branch: master

3 changes

Bug Fixes(3)

Resolved issues and error corrections

[FIX] stock_barcode: display package type selection in barcode put in pack

PR #122874

Enterprisemasterstock_barcodeMEDIUM

The barcode app now shows the package type selection step when users click Put in Pack and the delivery operation requires a package type. This prevents warehouse staff from accidentally creating packages without the required packaging information.

Original PR description

### Steps to reproduce: - In the settings enable: Packages - On the operation type `Delivery Order` set "Set Package Type" - Create and confirm a delivery for 1 unit of a product P + reserve it - Got…

### Steps to reproduce:

- In the settings enable: Packages
- On the operation type `Delivery Order` set "Set Package Type"
- Create and confirm a delivery for 1 unit of a product P + reserve it
- Got to the barcode app to process the delivery
- Scan your product and click "put in pack"
#### > The put in pack wizard allowing you to set a package type on the new package does not pop up.

### Cause of the issue:

As a general rule of thumb the wizard is suppose to be displayed when the option is enabled and when a package/package type is not already provided to the call:
https://github.com/odoo/odoo/blob/5dbc448d336c7ff22803ae91d5014eb6d0a07234/addons/stock/models/stock_package.py#L332-L341 https://github.com/odoo/odoo/blob/5dbc448d336c7ff22803ae91d5014eb6d0a07234/addons/stock/models/stock_move_line.py#L1236-L1238 However an override was added to the barcode module so that the wizard is never displayed when the action is launched from the barcode app: https://github.com/odoo/enterprise/blob/673d449f38cd3eff27c44270c8f7edf91d0ecd02/stock_barcode/models/stock_move_line.py#L193-L196

The idea behind this override was that you could provide the package type id via scans and hence that is was not necessary. However, if you click directly on the put in pack button, the wizard still make sense and should therefore be displayed under the same conditions.

opw-6325092

Forward-Port-Of: odoo/enterprise#122308

#barcode#inventory#packages#delivery

[FIX] l10n_be_coda: use communication as ref in unstruct cases

PR #122864

Enterprisemasterl10n_be_codaMEDIUM

Belgian CODA bank imports now use the full transaction communication as the payment reference when no structured reference is available. This makes imported card payment transactions easier to identify and match during bank reconciliation.

Original PR description

### Issue:
When a CODA file was imported, the communication was fetched but it wasn't use as the payment ref
Causing difficulty to match with the transactions

### Cause:
For simplicity reason, the payment_ref and the communication where different
The `payment_ref` was fetched once and replace
The `communication` was always completed by new lines

### Steps to reproduce:
- Install `l10n_be_coda`
- Set the account on the Bank Journal to GR5605700000000928073840752
- Import the Simplied CODA (On the ticket) from the bank dashboard

Before the fix, the ref was just `Liquidation des ventes par carte Mastercard` instead of the full communication that can be found in the chatter

opw-6245848

Forward-Port-Of: odoo/enterprise#122344
Forward-Port-Of: odoo/enterprise#120536

#CODA#bank-import#reconciliation#Belgium

[FIX] stock_barcode{,_product_expiry}: convert line qty to move uom qty barcode

PR #122927

Enterprisemasterstock_barcodestock_barcode_product_expiryMEDIUM

Barcode receipt updates now keep quantities correct when products are handled in packs or other alternate units of measure. This prevents received stock from being reduced incorrectly after leaving the barcode screen, improving inventory accuracy for purchasing and warehouse teams.

Original PR description

**Steps to reproduce:**
- Install `stock` and `purchase` modules
- Enable `Units of Measure and Packages`  and `Storage Locations` from setting
- Create a storable product with vendor purchase UoM set to "Pack of 6"
- Create and confirm a Purchase Order with quantity 6 Units
- Open the generated receipt
- Update a move line in Detailed Operations:
  - Quantity: 1
  - UoM: Pack of 6
- Save and open the Barcode view using smart button.
- Increase quantity using "+" button by 1.
- Exit barcode view without validating and refresh the receipt

**Issue:**
After refresh, the stock move quantity becomes 1 instead of 6,
while the move line correctly shows 1 Pack of 6.

**Cause:**

https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/static/src/components/main.js#L161-L162

- Exiting the barcode view triggers `__onExit()`, which forwards
`reserved_uom_qty` and `qty_done` from move lines to
`post_barcode_process()`.
https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/static/src/models/barcode_picking_model.js#L1885-L1898

This `post_barcode_process()` function triggers `_truncate_overreserved_moves()`
https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/models/stock_move.py#L56-L58

- During this flow, `_truncate_overreserved_moves()` updates the stock move quantity
by taking the maximum of `qty_done` and `reserved_uom_qty`. However, it assigns
this value directly to the move without converting it into the stock move UoM.

- In this case, both values are 1 because the move line is UoM is "Pack of 6"
Logically, 1 Pack corresponds to 6 units, but since the stock move UoM is in units,
this conversion is skipped. As a result, the move quantity is incorrectly set to 1
instead of 6.

https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/models/stock_move.py#L52-L54

**Fix:**

- Convert quantities coming from barcode processing into the stock
move UoM before updating the move quantity, ensuring packaged
UoM values are preserved correctly.

----

opw-5472598

Forward-Port-Of: odoo/enterprise#122769
Forward-Port-Of: odoo/enterprise#116022

#barcode#inventory#units of measure#receipts

Branch: 19.0

1 change

Bug Fixes(1)

Resolved issues and error corrections

[FIX] l10n_be_coda: use communication as ref in unstruct cases

PR #122541

Enterprise19.0l10n_be_codaMEDIUM

Belgian CODA bank imports now use the full transaction communication as the payment reference when the reference is unstructured. This makes imported bank transactions easier to identify and match correctly, reducing manual reconciliation effort.

Original PR description

### Issue:
When a CODA file was imported, the communication was fetched but it wasn't use as the payment ref
Causing difficulty to match with the transactions

### Cause:
For simplicity reason, the payment_ref and the communication where different
The `payment_ref` was fetched once and replace
The `communication` was always completed by new lines

### Steps to reproduce:
- Install `l10n_be_coda`
- Set the account on the Bank Journal to GR5605700000000928073840752
- Import the Simplied CODA (On the ticket) from the bank dashboard

Before the fix, the ref was just `Liquidation des ventes par carte Mastercard` instead of the full communication that can be found in the chatter

opw-6245848

Forward-Port-Of: odoo/enterprise#122344
Forward-Port-Of: odoo/enterprise#120536

#CODA#Belgium#bank import#payment matching#reconciliation

Branch: 18.0

1 change

Bug Fixes(1)

Resolved issues and error corrections

[FIX] l10n_it_stock_ddt: drop DatiDDT without a number from the e-invoice

PR #271009

Core18.0l10n_it_stock_ddtMEDIUM

This update resolves an issue where FatturaPA (an Italian e-invoice system) rejected invoices linked to deliveries without a DDT number. The change ensures that invoices without a DDT number are no longer included in the XML export, preventing errors and ensuring compliance with FatturaPA requirements. This improves the reliability of e-invoice generation.

Original PR description

### Before this PR FatturaPA wants a `NumeroDDT` inside every `DatiDDT` block. When an invoice is linked to a delivery that never got a DDT number (its picking type has no DDT sequence), we still…

### Before this PR

  FatturaPA wants a `NumeroDDT` inside every `DatiDDT` block. When an invoice is linked to a delivery that never got a DDT number (its picking type has no DDT sequence), we still wrote out a `DatiDDT` with no  `NumeroDDT`, and the SDI throws the whole invoice back.
 
  The delivery slips into `ddt_dict` because `_get_ddt_values` gathers every linked picking, with or without a number.
  
### After this PR

 No error on export because the ddt without number are not exported in XML

### Steps to reproduce

1. Go to the Delivery operation type (Inventory -> Configuration  -> Operations Types  -> your `WH/OUT`) and remove the "DDT Sequence" (`l10n_it_ddt_sequence_id`). Any outbound process having the picking type without DDT sequence will replicate the bug (e.g., a Dropship type without DDT sequence).
2. Create a Sale Order for a client, put a storable/consumable product invoiced on delivery and validate it.
3. Validate the Delivery. As the picking type does not have any DDT sequence, `_action_done` does not assign any DDT Number, so the picking has an empty "DDT Number".
5. Create an invoice from the Sale Order and validate it.
6. Export FatturaPA XML (Send & Print / e-invoice).

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

#e-invoice#FatturaPA#IT#delivery