Invoice creation from bank reconciliation now includes the missing tax rounding details during tax calculations. This helps ensure invoice unit prices and tax amounts are computed consistently, reducing accounting discrepancies.

Invoice creation through reconciliation models was implemented in #59555, but the call to function _eval_taxes_computation_prepare_context had missing paramenters.

When calculating the price unit for invoice creation, the function _get_invoice_price_unit_from_price_total prepares the context for tax calculation with _eval_taxes_computation_prepare_context. In the latter function call, the parameters rounding_method and precision_rounding were not being passed. This commit fixes that.

This update simplifies internal spreadsheet edition code by removing unnecessary waiting logic around single background operations. It does not change what users see, but it keeps the code easier to maintain and less prone to avoidable complexity.

both `Promise.all` are useless here since there is only one promise.

Several Odoo business apps were updated to work with the newer content editor used for emails, appointments, appraisals, approvals, payroll, and Knowledge. This keeps existing editing features working while simplifying email formatting behind the scenes and preparing the platform for removal of the older editor.

Steps to reproduce ================== - Install web_studio,calendar - Go to calendar - Open studio => In the sidebar, Quick Create is disabled but should be enabled Toggling it does nothing Cause of the issue ================== The value was incorrectly read from `archInfo.hasQuickCreate` Solution ======== `hasQuickCreate` -> `quickCreate` This shows a second issue: Now that it's enabled, we can't disable it. This is because we remove the attribute instead of se

Steps to reproduce
==================

- Install web_studio,calendar
- Go to calendar
- Open studio

=> In the sidebar, Quick Create is disabled but should be enabled
   Toggling it does nothing

Cause of the issue
==================

The value was incorrectly read from `archInfo.hasQuickCreate`

Solution
========

`hasQuickCreate` -> `quickCreate`

This shows a second issue:

Now that it's enabled, we can't disable it.
This is because we remove the attribute instead of setting it to false

If we don't pass the attribute, it will keep it's default value (true)

https://github.com/odoo/odoo/blob/2afce223268c4ee1ac3c98a6108b1390be82716b/addons/web/static/src/views/calendar/calendar_arch_parser.js#L34

opw-4023026

Forward-Port-Of: odoo/enterprise#66253

Belgium now asks the pro rata deduction for the VAT export. Mandatory if the business is concerned. Added new module to be able to add fields to the wizard. task-3916995 Forward-Port-Of: odoo/enterprise#66515 Forward-Port-Of: odoo/enterprise#65442

Belgium now asks the pro rata deduction for the VAT export. 
Mandatory if the business is concerned.
Added new module to be able to add fields to the wizard.

task-3916995

Forward-Port-Of: odoo/enterprise#66515
Forward-Port-Of: odoo/enterprise#65442

Before this commit, if one of the product's categories was not included in the preparation display, it would lead to an error. opw-4012616 Forward-Port-Of: odoo/enterprise#66534 Forward-Port-Of: odoo/enterprise#66479

Before this commit, if one of the product's categories was not included in the preparation display, it would lead to an error.

opw-4012616

Forward-Port-Of: odoo/enterprise#66534
Forward-Port-Of: odoo/enterprise#66479

The Company Identification field was incorrectly formatted as a numeric field. It is specified as numeric by some banks [^1], but the official specification is alphanumeric [^2]. On top of that the alphanumeric Company Discretionary Data field was right-justified. A minority of banks don't handle this correctly. There's no official specification on how to align alphanumeric fields [^1]. The decision to left-justify is based on the following: - Chase specifies to left-justify them [^3]

The Company Identification field was incorrectly formatted as a numeric field. It is specified as numeric by some banks [^1], but the official specification is alphanumeric [^2].

On top of that the alphanumeric Company Discretionary Data field was right-justified. A minority of banks don't handle this correctly.

There's no official specification on how to align alphanumeric fields [^1]. The decision to left-justify is based on the following:

- Chase specifies to left-justify them [^3]
- The most extensive open-source ACH library left-justifies them [^4]
- Another Python ACH library left-justifies them too [^5]
- Online images of ACH files seem to left-justify them as well

The only two remaining fields that are right-justified with spaces ({:>...}) are Immediate Destination and Immediate Origin. This is on purpose. Although they are numeric fields and thus right aligned, they are specified to start with a blank space, not a leading 0 [^2].

[^1]: https://web.archive.org/web/20230624090124/https://files.nc.gov/ncosc/documents/eCommerce/bank_of_america_nacha_file_specs.pdf
[^2]: https://achdevguide.nacha.org/ach-file-overview
[^3]: https://www.chase.com/content/dam/chaseonline/en/demos/cbo/pdfs/cbo_nacha_filespecs.pdf
[^4]: https://github.com/moov-io/ach/blob/073d011f811605e1b6051792163159a55feca533/converters.go#L81-L94
[^5]: https://github.com/travishathaway/python-ach/blob/cc8b6448d75f3815c91d3b8a5dadd6731aa96e71/ach/data_types.py#L57-L76

opw-4033830

Forward-Port-Of: odoo/enterprise#66286

Forward-Port-Of: odoo/enterprise#66556

Forward-Port-Of: odoo/enterprise#66556

### Steps to reproduce the issue: 1. Create a Product with "Service" as Product Type and "Based on Timesheets" as Invoicing Policy 2. Go to _Field Service > Configuration > Projects_ and choose a Project 3. In the _Invoicing_ section, add a line with an Employee and the Service Product you created 4. Create a Task for the Project 5. Add in the _Timesheets_ section a line with the Employee and a duration of one hour 6. Click on "Mark as done", then "Sales Order" 7. The Delivered Quantiti

### Steps to reproduce the issue:

1. Create a Product with "Service" as Product Type and "Based on Timesheets" as Invoicing Policy
2. Go to _Field Service > Configuration > Projects_ and choose a Project
3. In the _Invoicing_ section, add a line with an Employee and the Service Product you created
4. Create a Task for the Project
5. Add in the _Timesheets_ section a line with the Employee and a duration of one hour
6. Click on "Mark as done", then "Sales Order"
7. The Delivered Quantities have a correct value but the Ordered Quantities do not

### Explanation:

An uom conversion is performed in `_get_delivered_quantity_by_analytic` to compute `qty_delivered` but is missing in `_fsm_create_sale_order_line` for `product_uom_qty`.
https://github.com/odoo/odoo/blob/18e03c73691d9efa82cbf82b5e084172fe74665e/addons/sale/models/sale_order_line.py#L386-L392

### Suggested Fix:

To prevent unintended behaviours, any product that is currently used in a Field Service Project will have `invoice_policy`, `service_type` and `detailed_type` locked to match the domain of `timesheet_product_id` for every model using it.

opw-3858530

Forward-Port-Of: odoo/enterprise#66252
Forward-Port-Of: odoo/enterprise#63337

Steps to reproduce: 1. Create an event with an appointment-type set. 2. In the Calendar module, open the event you created for the appointment. 3. Navigate to the 'Appointment Details' page. Before This Commit: The 'Appointment Details' page is displayed even if no resources have been set. After This Commit: Appointment resource records will only be shown if resources are set. Task:3918574 Forward-Port-Of: odoo/enterprise#66415 Forward-Port-Of: odoo/enterprise#63885

Steps to reproduce:
1. Create an event with an appointment-type set.
2. In the Calendar module, open the event you created for the appointment.
3. Navigate to the 'Appointment Details' page.

Before This Commit:
The 'Appointment Details' page is displayed even if no resources have been set.

After This Commit:
Appointment resource records will only be shown if resources are set.

Task:3918574

Forward-Port-Of: odoo/enterprise#66415
Forward-Port-Of: odoo/enterprise#63885

## [FIX] account_disallowed_expenses_fleet: query is mixing apple and pear The aim of this commit is to make the report behaves correctly when facing a DB with a lot of vehicles and a lot of accounts by making the query `group by` and `order by` more robust. Context: - 1 account and 1 vehicle share the same number for the id - the account is tagged with disallowed expense tag - 1 `account.move.line` without vehicle in that account - 1 `account.move.line` with a vehicle (with a dna ra

## [FIX] account_disallowed_expenses_fleet: query is mixing apple and pear

The aim of this commit is to make the report behaves correctly when
facing a DB with a lot of vehicles and a lot of accounts by making the
query `group by` and `order by` more robust.

Context:
- 1 account and 1 vehicle share the same number for the id
- the account is tagged with disallowed expense tag
- 1 `account.move.line` without vehicle in that account
- 1 `account.move.line` with a vehicle (with a dna rate) in the same
  account

Before the commit:
- The computation is giving wrong result in the report: 2 `account.move.line`
  were aggregated together under the hierarchy of the account without vehicle
  and the vehicle doesn't appear in the report at all.
  cause: the `CASE WHEN` could return, for example `92` as a `vehicle_id` and
  then `92` as an `account_id` and thus have them regrouped together.

- 2 lines of the report were sharing the same "line_id" (the id given by
  report framework id, see method `_build_line_id`) which are used in a
  t-key property in an OWL loop resulting in a crash for the front-end.

After the commit:
- The 2 lines are aggregated seperatly: The line without `vehicle_id` is under
  the hierarchy of the account and the line with `vehicle_id` is under the
  hierachy of the concerned vehicle.
- The line doesn't share any line_id anymore

task-id: None (issue discovered in our own prod)

## [IMP] account_reports: ensure line_id is uniq in tests

Moved to https://github.com/odoo/enterprise/pull/66216

Forward-Port-Of: odoo/enterprise#66462
Forward-Port-Of: odoo/enterprise#64166

The config parameter `stock_barcode.mute_sound_notifications`, who allows to mute all sounds in the Barcode app, is not used on the MainMenu, which means scanning a barcode on the main menu will always play a sound regardless the configuration. This commit fixes that. Forward-Port-Of: odoo/enterprise#66227

The config parameter `stock_barcode.mute_sound_notifications`, who allows to mute all sounds in the Barcode app, is not used on the MainMenu, which means scanning a barcode on the main menu will always play a sound regardless the configuration.
This commit fixes that.

Forward-Port-Of: odoo/enterprise#66227

Steps to reproduce ------------------- - create a commission plan with: product category: "All" rate: R capped: True max commission: >>> - create a partner level with the created commission plan - create a partner with the created partner level - create a product in the correct category with price P - create a quotation template with the created product - create a sale order with the partner as referrer - add the quotation template (the product is added automatically)

Steps to reproduce
-------------------
- create a commission plan with:
    product category: "All"
    rate: R capped: True
    max commission: >>>
- create a partner level with the created commission plan
- create a partner with the created partner level

- create a product in the correct category with price P
- create a quotation template with the created product

- create a sale order with the partner as referrer
- add the quotation template (the product is added automatically)
- confirm
- create the invoice, confirm it and register the payment

At this moment, a purchase order is created (the commission) If we repeat these steps with a new sale order,
the amount of the purchase order will increase as expected.

- add a quotation template on the commission plan (in the rules)
- repeat the creation of a sale order.

No commission is added (purchase order line).

Cause:
------
We have no template when calling `_match_rules`.
However, our plan has a default template.
The result is that no rules are found.

Solution:
---------
Fallback on the sale order's template
if it is not a subscription.

opw-3933323

Forward-Port-Of: odoo/enterprise#64884

Issue ===== When a GS1 barcode contains both a packaging and a weight, the quantity is wrong because we use the weight as the quantity and multiply it by the packaging quantity. How to reproduce ================ - Enable "Product Packagings" and "Units of Measure"; - Select GS1 nomenclature as the Barcode Nomenclature; - Create a product with a packaging for multiple quantity (e.g.: 4 Units) and with a valid GTIN (e.g.: 12345600012349); - In the Barcode app, create a new receipt;

Issue
=====

When a GS1 barcode contains both a packaging and a weight, the quantity is wrong because we use the weight as the quantity and multiply it by the packaging quantity.

How to reproduce
================

- Enable "Product Packagings" and "Units of Measure";
- Select GS1 nomenclature as the Barcode Nomenclature;
- Create a product with a packaging for multiple quantity (e.g.: 4 Units) and with a valid GTIN (e.g.: 12345600012349);
- In the Barcode app, create a new receipt;
- Scan a GS1 barcode containing both the packaging barcode and a weight (e.g.: 10123456000123493103001500) => The scanned weight is used as the quantity and is multiplied by the packaging quantity (in this example, the quantity will be 6, because 4 units x 1.5 kg = 6 units)

Expected Behavior
=================

Since the associated product uses Units as UoM, the scanned weight can't be converted into quantity (we can't convert g or kg into units), so this information should be ignored and the packaging quantity should be used alone instead.

Note that the packaging quantity will still multiply the scanned quantity if the share the same UoM category. This behavior is still supported to be able to scan multiple packagings at once. That said, this use case make sense for products using Units only.

[OPW-3988826](https://www.odoo.com/odoo/11258/tasks/3988826?cids=1)

Forward-Port-Of: odoo/enterprise#66375
Forward-Port-Of: odoo/enterprise#65073

Steps to reproduce: - create a spreadsheet document - insert an image in the spreadsheet - hit the Share button - open the link in an incognito window => the image is not displayed Task: 4037385 opw-4035835 Forward-Port-Of: odoo/enterprise#66427 Forward-Port-Of: odoo/enterprise#66152

Steps to reproduce:
- create a spreadsheet document
- insert an image in the spreadsheet
- hit the Share button
- open the link in an incognito window

=> the image is not displayed

Task: 4037385
opw-4035835

Forward-Port-Of: odoo/enterprise#66427
Forward-Port-Of: odoo/enterprise#66152

After this commit: Traceback will not occur when searching for tickets on the portal task-3959379 Forward-Port-Of: odoo/enterprise#63556

After this commit:
Traceback will not occur when searching for tickets on the portal

task-3959379

Forward-Port-Of: odoo/enterprise#63556

The aim of this commit is to fix an issue in the sql query generated by the `account_disallowed_expenses` module that was covered by the `account_disallowed_expenses_fleet` during the runbot testing. runbot-71011 Forward-Port-Of: odoo/enterprise#66567

The aim of this commit is to fix an issue in the sql query generated by the `account_disallowed_expenses` module that was covered by the `account_disallowed_expenses_fleet` during the runbot testing.

runbot-71011

Forward-Port-Of: odoo/enterprise#66567

Accounting users without admin access can now successfully export SAT (XML) files from the Trial Balance report in Mexico-based companies. Previously, an access error would prevent the export from completing. This fix ensures that accounting staff can perform their required reporting duties without needing elevated system permissions.

With an MX company
Access as accounting user with no admin/Settings
Go to Accounting > Reports > Trial Balance.
Click "SAT (XML)" to export the file.

Issue: Access Error will raise

opw-4044467

This fix resolves an issue where barcode scanning for back and skip commands in the shop floor assembly steps was not functioning. Workers can now use barcode scanning to navigate through manufacturing work orders as intended, improving efficiency on the production floor.

**Steps to reproduce**:
- Create an MO for Stool
- In the shop floor, open the "assembly" step of the created WO

**Currently**: scanning barcode for back/skip does not do anything.
**After this commit**: scanning the barcode executes the expected command.

task-4047193

This update resolves a technical error that occurred when generating GST return reports (GSTR-1) in specific POS scenarios. The fix ensures the system can safely handle cases where invoices are created across multiple POS sessions, preventing the report generation from failing and allowing users to successfully complete their GST compliance reporting.

In this PR:

Steps to reproduce:
1. Create a POS session.
2. Make two orders: one with an invoice and one without. Close the session.
3. Create another session, make an order, and create an invoice for an order from the previous session. Close the session.
4. Create a GST return period and generate the GSTR-1 spreadsheet.

Changes made:
- Fixed the retrieval of POS line details by move ID.
- Added a safe access method using get to prevent key errors during HSN summary generation.

Task ID: 3935317

This fix resolves an issue where users couldn't resize signature items after moving them between pages in a document. The problem occurred because the resize function was still referencing the old item location. Now users can seamlessly resize signature items on any page without encountering errors.

Before this commit, when you drag and drop a resizeable sign item from one page to another, it was not possible to resize the item: it was buggy because the updated sign item changed the page and the resize function had the old object binded to it.

After this commit, it is possible resizing the sign items when clicking the border without any problems, from any page. This was obtained by re-binding the updated sign item to the resize function.

task-4032512

A visual bug in the sign template has been fixed where users were seeing duplicate scroll bars. The issue was caused by the toolbar on the left side taking up too much space. The fix adjusts how the toolbar's height is calculated to prevent the content from overflowing, resulting in a cleaner, more professional appearance.

Issue:
--------------------
When you open a sign template you can see there are double scroll bars on the iframe

Cause:
----------------------
The sign item toolbar placed on the left side is given 100% height and  1px border which is causing the iframe body to overflow

Solution:
-----------------------------
The 100% height given to the toolbar is changed with -webkit-fill-available

task-4014519