This update fixes how accounting reports are formatted when exported to Excel files. The changes improve the layout by moving account codes to a more logical position in the spreadsheet and fixing indentation issues that previously limited reports to three levels. Users will now see cleaner, better-organized Excel exports with proper indentation support for complex report structures.

### [FIX] account_report: fix indentation in xlsx export
Currently the indentation of XLSX export of reports was sometimes broken. The current implementation only supported up to three levels of indentation in the export as well.

This fix supports a virtually infinite number of indentation levels and fixes the indentation in the XLSX exports.

### [I18N] account_reports: update terms

### [IMP] account_reports: move account code column to the right in xlsx
Currently, when exporting an accounting report as XLSX file, we add a column for the account codes on the very left of the sheet. This looks a bit weird and is not the most important information to have as a first column.

In this commit, we move the column to the right so the name of the line will be first, followed by the account code (if applicable). We also add a column name for the account codes.

task-3986483

The demo data for Argentina's reporting module has been updated to remove real partner information and replace it with fictional data. This improvement protects actual customer privacy while maintaining the ability to test and demonstrate the system's functionality.

This task was created to modify the demo data for Argentina, to avoid using real partner information.

latam-task-1239
adhoc-task-41734

Forward-Port-Of: odoo/enterprise#71230

The system now correctly identifies late bills in GST Return-2B reports by comparing the bill date against the return period start date, rather than using an inaccurate comparison method. This ensures businesses get accurate reporting of late vendor invoices, which is important for GST compliance and financial accuracy.

Previous behavior:
- Late bills were determined by comparing `supprd` with the `return period`, which led to inaccuracies.

New behavior:
- Late bills are now identified by checking if the `bill date` is earlier than the `return period start date`, ensuring more precise classification of late bills.

OPW: 4210068

Forward-Port-Of: odoo/enterprise#70225

This fix corrects how revenue and margin are calculated in project planning reports when products are sold by units other than hours (such as days). Previously, the system incorrectly assumed all pricing was hourly, leading to significantly inaccurate financial reporting. Now the system properly accounts for the actual unit of measure specified on the sales order, ensuring accurate revenue and margin analysis.

Steps to reproduce:
- Create a product with the following settings: -- Product Type: Service; Invoicing Policy: Based on Timesheets -- Create on Order: Project & Task; Unit of Measure: Days -- Sales Price: 120 (Use != 100 when using Mitchel Admin)
- Create a quotation for this product and confirm it
- Created Task > Timesheets tab > Record 4 hours
- Go to Planning > New > Create a 1 day shift for Mitchel Admin
- Link that shift to the project created by your SO
- Enable 'Project Planning' in Settings > Planning
- Go to Project > : Menu > 'Timesheet and planning analysis'
- Under the Measures dropdown, add all columns

You will notice that the measures for revenue and margin are computed as though the unit price corresponds to 1h even though our product uom is Days. This makes the computations for revenues and margins completely wrong. This happens because the module converts all values into hours without accounting for the fact that the SOL unit price is not necessarily by the hour. This happens regardless of the 'Encoding Method' setting of Timesheet.

opw-3918082

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 fix resolves a user experience issue where the vendor dropdown menu would not close immediately when selecting an option to create a new vendor. Previously, users had to click twice to close the dropdown. Now it closes automatically on the first interaction, making the invoice extraction process smoother and more intuitive.

The vendor dropdown does not close when a extract box is clicked and a creation dialog opens. It would only close after the first click. In this commit the dropdown is closed straight away.

Forward-Port-Of: odoo/enterprise#71039

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