Using the enterprise feature Vendor Bill Scan, When the partner doesn't exists in the database the following traceback:
```py
  File "/home/odoo/odoo18/community/odoo/api.py", line 496, in _model_create_multi
    return create(self, arg)
  File "/home/odoo/odoo18/community/addons/mail/models/mail_thread.py", line 268, in create
    threads = super(MailThread, self).create(vals_list)
  File "<decorator-gen-31>", line 2, in create
  File "/home/odoo/odoo18/community/odoo/api.py", line 496, in _model_create_multi
    return create(self, arg)
  File "/home/odoo/odoo18/community/odoo/models.py", line 4968, in create
    new_vals_list = self._prepare_create_values(vals_list)
  File "/home/odoo/odoo18/community/odoo/models.py", line 5125, in _prepare_create_values
    self._add_precomputed_values(result_vals_list)
  File "/home/odoo/odoo18/community/odoo/models.py", line 5153, in _add_precomputed_values
    records = self.browse().concat(*(self.new(vals) for vals in vals_list_todo))
  File "/home/odoo/odoo18/community/odoo/models.py", line 5153, in <genexpr>
    records = self.browse().concat(*(self.new(vals) for vals in vals_list_todo))
  File "/home/odoo/odoo18/community/odoo/models.py", line 6861, in new
    record._update_cache(values, validate=False)
  File "/home/odoo/odoo18/community/odoo/models.py", line 6411, in _update_cache
    raise ValueError("Invalid field %r on model %r" % (e.args[0], self._name))
ValueError: Invalid field 'duns' on model 'res.partner'
```

In this commit-
We fix the above traceback and the feature works as expected




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

### Steps to reproduce:
	- Create a recurring service (product) with invoicing policy set as 'Based on Timesheets'
	- Create a subscription using the created product
	- Create a task and link it to this subscription order
	- Timesheet 3 line in the task one in the past one on the same date of creation and one in the future.
	- Create an invoice for this order
	- Notice the quantity has been invoiced is the present timesheet line only
	- Notice that the 3 timesheet lines have all been validated

### Cause:
This is happening because when trying to link the lines to the invoice we consider the timesheets within the date range that the user might have set in the create invoice wizard.
https://github.com/odoo/odoo/blob/9a4ec08b9a6b07470747923d09adcf51f7e4cd6a/addons/sale_timesheet/wizard/sale_make_invoice_advance.py#L33-L51 https://github.com/odoo/odoo/blob/9a4ec08b9a6b07470747923d09adcf51f7e4cd6a/addons/sale_timesheet/models/sale_order.py#L153

### Fix:
In subscription we can use the last and next invoice dates if the user hasn't set a period for the invoice.

opw-4523727

**Steps to reproduce:**
- Install Accounting
- Go to Settings and configure document layout
- Select Folder as layout
- Create an invoice with lot of products (~20) that would be printed on 2 pages
- Duplicate the created invoice
- From the list view, select both invoices
- Click on "Send" button
- Go to "Settings / Technical / Automation / Scheduled Actions"
- Open "Send invoices automatically" action
- Click on "Run Manually"

**Issue:**
A KeyError is raised in "_prepare_invoice_pdf_report" method from the following line:
`'raw': content_by_id[invoice.id]`
If the invoices have already been sent before clicking on "Run Manually", the traceback can be checked in the logs.

**Cause:**
Since this commit
https://github.com/odoo/odoo/commit/0e73d3f1751495786eb2b18384ea39f4da18e3fb a unique call to "wkhtmltopdf" is made to generate one PDF for all the invoices.
This PDF is then split in a dict having an entry for each invoice. When there is more pages than the number of invoices, we check the "outlines" generated by "wkhtmltopdf" to determine which pages are associated to which invoice.
"wkhtmltopdf" generates an "outline" for each heading tag (i.e. h1, h2,...).
As each layout is only using a heading tag (i.e. h2) for the document title, we can assume that each page between 2 heading tags and therefore outlines belongs to the same invoice.
The issue with the Folder layout is that the document title is defined in the header of the layout and not in the body as it is done for the other layouts.
But "wkhtmltopdf" only generates "outines" for heading tags in the body, ignoring those defined in the header.
In that case, the PDF cannot be split due to the lack of outlines and the dict only contains one element (the whole PDF) with False as key, which raises the error when executing this code `content_by_id[invoice.id]`.

**Solution:**
1) Instead of the KeyError, a UserError with a more useful message is raised instead.

2) A heading tag (h3) is added in the body of the Folder layout to allow "wkhtmltopdf" to generate the "outlines" from it.
This heading also contains the document title.
But in order to prevent having the document title displayed twice, these styles are applied to it:
- "opacity: 0" to hide the tag. "display: none" and "visibility: hidden" don't work. No "outline" is generated if there are used.
- "height: 0" to remove the space allocated to the hidden tag.
This is a very hacky solution but without it, it is not possible to send multiple documents that have more than one page.

opw-4592851
opw-4562932




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

### Steps to reproduce:
*Happening in all LATAM localizations*
- Install 'l10n_pe' and switch to a Peruvian company
- In Accounting > Configuration > Journals duplicate "Customer Invoices"
- In the new journal tick the option "Secure Posted Entries with Hash"
- Create a new invoice with this journal, confirm
- Duplicate this invoice and try to confirm
- Cannot confirm

### Cause:
When confirming an invoice with LATAM localization, the fields "sequence_number" and "sequence_prefix" are no longer populated. These fields are necessary with the hash option.

During a previous series of commits, a call to `_compute_split_sequence` was removed:
- [1st commit](https://github.com/odoo/odoo/commit/10565c6968a5d0f285f93c4bdc610350999a88e3) 
- [2nd commit](https://github.com/odoo/odoo/commit/658542e17dfe421b83bf610564042c8b643b3b78) 
- [3rd commit](https://github.com/odoo/odoo/commit/7f08a7ebbcc8fc856f961d7ca6f001ce69e8771c) 

This for some reason does not compute the fields for invoices in LATAM.

### Solution:
Add the call to `_compute_split_sequence`.

opw-4685796

A little guide to this PR:

**[FIX] html_editor: toolbar shown on collapsed selection in uneditable**
- removes normalization around non-editables on `makeActiveSelection`, but leaves `setSelection` untouched.
- fixes a bug reported in the html_builder (see https://pad.odoo.com/p/mysterious-egg-builder-editor-bug)
- to test this, one should cherry-pick this commit into `odoo-dev/master-mysterious-egg`. Here it is, as of 13/03/2025: `odoo-dev/master-mysterious-egg-rcdl-3` ([runbot bundle](https://runbot.odoo.com/runbot/bundle/master-mysterious-egg-rcdl-3-348950), or try directly [this](https://76547856-master.runbot251.odoo.com/odoo/action-205)).
- it will only take effect on htm_builder once this is fw-ported to master and odoo-dev/master-mysterious-egg rebased to odoo/master 

**[FIX] html_editor: selection preservation around moved nodes**
- prerequisite for the following commit

**[FIX] html_editor: delete in uneditable zone**
- what the task 4242213 is originally about
- 3 "todo" tests now passing! :partying_face: 

================
So far, so good, no spec changes, no breaking tests.
Now it gets a little wild (possibly better for master?). Either way, no API changes, thus suitable for stable.

**[FIX] html_editor: asymmetric range adjustment around non-editables**
- prerequisite for the next one

**[FIX] html_editor: normalization around non-editables on setSelection**
- finishes the job started by the first commit and removes the normalization step also from `setSelection`. A dream come true???

task-4242213

### Steps to reproduce:
	- Create a recurring service (product) with invoicing policy
	set as 'Based on Timesheets'
	- Create a subscription using the created product
	- Create a task and link it to this subscription order
	- Timesheet 3 line in the task one in the past one on the same
	date of creation and one in the future.
	- Create an invoice for this order
	- Notice the quantity has been invoiced is the present timesheet line only
	- Notice that the 3 timesheet lines have all been validated

### Cause:
This is happening because when trying to link the lines to 
the invoice we consider the timesheets within the date range that the user
might have set in the create invoice wizard.
https://github.com/odoo/odoo/blob/9a4ec08b9a6b07470747923d09adcf51f7e4cd6a/addons/sale_timesheet/wizard/sale_make_invoice_advance.py#L33-L51
https://github.com/odoo/odoo/blob/9a4ec08b9a6b07470747923d09adcf51f7e4cd6a/addons/sale_timesheet/models/sale_order.py#L153

### Fix:
In subscription we can use the last and next invoice dates
if the user hasn't set a period for the invoice.

opw-4523727

Some website appointment pages are showing the wrong price, always using the price of the first variant it finds, not the current one.
The issue was introduced in Odoo 18.0 with commit [1].

- Create a product.template, add it some variants and for each variants have a different price (eg through the variant extra price).
- That product should be a service one
- Create an appointment, enable "Up-front payment" in the "Options" tab and add it one of the variant product. Note that it's a variant product that you set there, not a template.
- You should see next to the variant product you just selected a price per booking being displayed. It is correctly showing the product variant price and not the product template price.
- Repeat those 2 steps with the other product variants: create a new appointment and select another variant, you can see the price is correct in the form view.
- Now, go to the website appointment page `/appointment`, you will see that all those appointments will show the same price which is the one from the first variant.
- The same price error will appear once you click on an appointment (you should land on something like `/appointment/4?`)
- Note that if you go further in the appointment booking and land on the shop cart page, the price will be correct there, using the correct variant one. (You'll need to assign a user on the appointment in the backend to be able to book a slot)

Side note: Commit [1] seems to have broken commit [2] too.

[1]: https://github.com/odoo/enterprise/commit/26fb20ace27b7b522a1105c221e4a52cf224a508#diff-5ffc6d13c61e692b22e4c2fec9218cf96c0c86201aeac951ef36e53e7baa7620R4-R9
[2]: https://github.com/odoo/enterprise/commit/5068b0ae7d38cb03318ad1e97124021121fd66cb

opw-4678998