*: stock_barcode_mrp, stock_barcode_picking_batch

## Issue Before This PR:
When navigating from the Barcode client action
(e.g. picking, inventory, etc.) to related form views
(such as lot, product, or company), the breadcrumb
would sometimes display an unnamed entry instead
of the originating document name.
This caused confusion for users, as they could not
easily identify which document they were coming from
when navigating to related records from the Barcode interface.

## Steps to Reproduce:
- Install the Barcode module.
- Open the Barcode app and navigate to:
     - Delivery Orders.
     - Manufacturing Orders
     - Batch Pickings
     - Inventory Count
- From any of these open a record
  (e.g. picking, MO, batch, inventory line)
- Click on document name or edit button on the line.
- Click on an external link (e.g. product, lot, company).
- Observe that the breadcrumb shows an unnamed entry.

## Cause of the Issue:
- When switching views inside the Barcode client action,
  the FormController calls `setDisplayName(this.displayName())`.
  In some cases, this returns an empty string, overwriting the
  previously set breadcrumb name.
- In several form views, the `display_name` field was not present,
  preventing the controller from retrieving a proper name.

## With This PR:
The Barcode views now display the correct document names in the
breadcrumb when navigating to external links, allowing users to easily
identify the originating document when opening related records from
the Barcode app.

TaskID: 4978997

Forward-Port-Of: odoo/enterprise#99165

### Issue:
When setting Vendor Bills to Digitize on demand, it is no longer possible in 19.0 to trigger digitization manually if the Bill Date is not set 
A missing required fields error is raised

### Cause:
This PR: https://github.com/odoo/odoo/pull/238911
introduced a required field to prevent an error modal from appearing 
While this works as intended, it also blocks the `Digitize Document` action, which is supposed to populate the Bill Date automatically

### Fix:
A condition similar to the one used for the Digitize Document button is applied to allow triggering digitization without a Bill Date

The validation modal is still enforced afterward to ensure data consistency in case of manual edits

### Steps to reproduce:
- Install `account`
- In Settings, set `Document Digitization` for `Vendor Bills` to `Digitize on demand only`
- Create and print an invoice (any data) or use an existing one
- Import it into Vendor Bills
- Click Digitize Document

### Before the fix:
A missing required fields notification is raised, preventing digitization

opw-5886012

### Issue before this commit:
Before this commit, validating an Italian withholding tax return could incorrectly include taxes that are not related to withholding. In particular, pension fund taxes such as 4% INPS were included in the computed total amount to pay, even though they should not be part of the withholding tax return. As a result, the final amount shown in the return was incorrect.

### Steps to reproduce the issue:
1. Download Accounting and l10n_it and switch to italian company
2. Create an invoice and a bill with a witholding tax (ex. 20% RIT PF)
3. Mark them as paid and reconcile them
4. Open a tax return and validate it
5. See that the total amount calculated includes also other taxes than only witholding taxes

### Cause of the issue:
The issue was caused by a missing domain restriction when computing the tax closing entries. The method _get_vat_closing_entry_additional_domain did not properly apply a filter on tax tags for the withholding tax return type l10n_it_reports.it_withh_tax_return_type. Because of this, the query used to compute tax balances included all taxes matching the generic conditions (date, company, posted state, etc.), without restricting them to the relevant withholding tax tags. Consequently, unrelated taxes were included in the computation.

### Reason to introduce the fix:
To restore the correctness of the tax return totals.

opw-5905355