This fix resolves a system error that occurred when invoice consolidation was enabled and multiple users were assigned to subscription invoices simultaneously. The issue caused the billing process to crash with a technical error. By disabling the automatic user assignment notification during consolidation, the system now handles these scenarios correctly without interruption.

Before this commit, when the invoice consolidation option was activated and several user_id were set on subscription invoicing at the same time, a traceback was observed:

``py
  File "/home/arj/PycharmProjects/worktree/17.0/odoo/addons/mail/models/mail_thread.py", line 276, in create
    thread._message_auto_subscribe(create_values, followers_existing_policy='update')
  File "/home/arj/PycharmProjects/worktree/17.0/odoo/addons/mail/models/mail_thread.py", line 4138, in _message_auto_subscribe
    res = self._message_auto_subscribe_followers(updated_values, def_ids)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/arj/PycharmProjects/worktree/17.0/enterprise/sale_subscription/models/account_move.py", line 76, in _message_auto_subscribe_followers
    if salesperson and user_id == salesperson.id and user_id != self.env.user.id:
                                  ^^^^^^^^^^^^^^
  File "/home/arj/PycharmProjects/worktree/17.0/odoo/odoo/fields.py", line 5154, in __get__
    raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: res.users(56, 60)
```

This update corrects how quarterly tax declaration fields are submitted to Spanish tax authorities (AEAT). Previously, new fields introduced for Q4 2024 and later were left empty, but the tax authority's submission system now requires these fields to be filled with zero values instead. This ensures tax reports are properly accepted by the AEAT system.

According to the documentation of the new Modelo 303 BOE export, the new fields that will be used for the declarations starting in 10/2024 or Q4/2024 "can only be completed from periods 10 and 4Q of 2024 and subsequent years". As such, we left the fields "empty" using the space character (like in other places).

However, now that the new AEAT submission page is ready, it seems they expect us to fill the new fields with zeroes instead of leaving them empty. This commit fixes that.

[opw-4222842](https://www.odoo.com/odoo/all-tasks/4222842)

Forward-Port-Of: odoo/enterprise#71379

This fix corrects how product demand quantities are displayed in the Master Production Schedule (MPS). Previously, when products used different units of measurement (like dozens), the system was not properly converting the quantities, causing demand to appear incorrectly (showing 1 unit instead of 12). This fix ensures quantities are always shown in the product's correct unit of measurement.

Steps to reproduce the bug:
- Create a storable product “P1”:
   - UoM: Unit

- Create a transfer for one dozen of P1:
   - Mark it as "To Do"

- Go to the MPS:
   - Add the product “P1”
   - In the filter, add “Actual Demand”

Problem:
The demand is shown as one unit instead of 12 units. The quantity of the move is not being converted into the UoM of product P1.

opw-4199710

Forward-Port-Of: odoo/enterprise#71216

This update improves how product information appears in Ecuador electronic invoices by prioritizing the line item name in the description field. Companies that include detailed product information in invoice line labels will now see this information properly displayed in the XML format used for electronic document submission, providing better clarity and detail in official invoices.

- In order to have more detail of the product used in the invoice, many companies place information in the label of the invoice line, we prioritize the name field to be displayed in the description tag of the xml.

This fix corrects an issue where Amazon orders containing multiple items were incorrectly creating separate shipping lines for each item, even when no per-item shipping cost was defined. Now shipping is properly consolidated, preventing duplicate and incorrect charges on customer orders.

If an Amazon order has more than one item it was creating for each item an own shipping line even if it had not even a shipping price defined per item line.

Info: @wt-io-it