This fix allows Brazilian Pix QR codes to be generated even when no payment amount is set. It supports offline point-of-sale use cases where the final amount may not be available when the QR code is created.

Since this commit we support the QR code without amount To be used in the POS when the POS is offline.

Introduced by: https://github.com/odoo/odoo/pull/148803/commits/f286e2c0473c568991171ef8c0b2dbb9871d2f2e

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

Description of the issue/feature this PR addresses: For method `_get_product_for_ui` in pos_self_order's product.product extension, check fields `product_tmpl_id.image_128` and/or `image_variant_128` for the existance of an image on the product (`has_image` key). Previously, the field `image_1920` was used which has two issues: 1.) The 128 sized image should be preferred because it is 15x smaller than 1920. The whole image is loaded at this point, so the smallest-sized one should be use

Description of the issue/feature this PR addresses:

For method `_get_product_for_ui` in pos_self_order's product.product extension, check fields `product_tmpl_id.image_128` and/or `image_variant_128` for the existance of an image on the product (`has_image` key).

Previously, the field `image_1920` was used which has two issues:

1.) The 128 sized image should be preferred because it is 15x smaller than 1920. The whole image is loaded at this point, so the smallest-sized one should be used.

2.) `image_1920` is a computed, non-stored, field. This has the implication that the image will be processed, thus consuming more memory (even leading to a MemoryError on the customer's DB). This happens like so:
	a.) `_compute_image_1920` is called, which sets a value into `record.image_1920`. https://github.com/odoo/odoo/blob/38f37edad3da4a4547b73d971e053b0634067fa1/addons/product/models/product_product.py#L157
	b.) Eventually `_image_process` is called, which performs memory intensive computations on the image. https://github.com/odoo/odoo/blob/38f37edad3da4a4547b73d971e053b0634067fa1/odoo/fields.py#L2550

So this can be avoided by implementing this commit, which will check the stored, non-computed fields instead.

Memory benchmarks for allocations by `_get_self_order_data`:

Done on customer DB with 1340 product.products, with a total of 776 images between them.

Before commit: 1638.4 MiB + server memory limit reached

After commit: 29.7 MiB total

Total improvement of 55x less memory usage


Current behavior before PR:

Server memory limit reached when loading pos kiosk with many product images in filestore

Desired behavior after PR is merged:

Use much less memory.

opw-3809503

Forward-Port-Of: odoo/odoo#157900

### [FIX] account_peppol: handle participant not ready error If the participant is not active on the IAP server, the server sends back a Participant not ready error in response without raising an error. On the client side a user sees a traceback, because we're trying to retrieve a message uuid of a non-existent peppol message: `response['messages'][i]['message_uuid']`. That's because we treat that error in the try block and then proceed to the else block because technically there was no excep

### [FIX] account_peppol: handle participant not ready error

If the participant is not active on the IAP server, the server sends back a Participant not ready error in response without raising an error. On the client side a user sees a traceback, because we're trying to retrieve a message uuid of a non-existent peppol message: `response['messages'][i]['message_uuid']`. That's because we treat that error in the try block and then proceed to the else block because technically there was no exception. This commit moves that error handling to `else` block so that such invoices get the proper error messages.

### [FIX] account_peppol: mock external request

Now that we check whether a participant exists on Peppol network first when they register, we should also mock that request. Currently, since that request is not mocked, all peppol tests are skipped.


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

Forward-Port-Of: odoo/odoo#158546
Forward-Port-Of: odoo/odoo#154926

Imagine the following situation: an automated action A is triggered when some stored computed field F has a certain value. When a record is created and no value is given for field F, then the automated action A may be run twice: once when evaluating A's domain forces the computation of F, and once again because A's domain is satisfied. The implementation already uses context flags to reflect which automated actions have already been run, in order to avoid automated actions to be run re

Imagine the following situation: an automated action A is triggered when
some stored computed field F has a certain value.  When a record is
created and no value is given for field F, then the automated action A
may be run twice: once when evaluating A's domain forces the computation
of F, and once again because A's domain is satisfied.

The implementation already uses context flags to reflect which automated
actions have already been run, in order to avoid automated actions to be
run recursively.  The fix consists in enabling those context flags to be
shared among the evaluation of the domain and processing of the
automated actions.

opw-[3731182]

Forward-Port-Of: odoo/odoo#157272

## Issue: - When adding tasks to a contact using Studio and attempting to set a task's project to a project linked to a Sales Order (SO), we encounter the following error: "TypeError: 'NewId' object is not iterable." ## Steps To Reproduce: - In a contact form open Studio and add a O2M field Customer (Task) - Create a new task in the O2M and set the Project to a project related to a SO. - Notice Traceback Error "TypeError: 'NewId' object is not iterable" ## Solution: - The issue arises

## Issue:
- When adding tasks to a contact using Studio and attempting to set a task's project to a project linked to a Sales Order (SO), we encounter the following error: "TypeError: 'NewId' object is not iterable."

## Steps To Reproduce:
- In a contact form open Studio and add a O2M field Customer (Task)
- Create a new task in the O2M and set the Project to a project related to a SO.
- Notice Traceback Error "TypeError: 'NewId' object is not iterable"

## Solution:
- The issue arises in the search domain of [_get_last_sol_of_customer](https://github.com/odoo/odoo/blob/2209021a3b77109824b572bb38c6c5d05554d753/addons/sale_timesheet/models/project.py#L603), where the domain is ('order_partner_id', 'child_of', self.partner_id.commercial_partner_id.id), and the type of `self.partner_id.commercial_partner_id.id` is `NewId` since the partner is being edited to add a task.
- This action triggers the [parse](https://github.com/odoo/odoo/blob/2209021a3b77109824b572bb38c6c5d05554d753/odoo/osv/expression.py#L805)  and [to_ids](https://github.com/odoo/odoo/blob/2209021a3b77109824b572bb38c6c5d05554d753/odoo/osv/expression.py#L847) methods with a value type of `NewId`. thus the error.
- The operator child_of deals with a list of ids, and the ids property refer to the record's origin ids. to resolve this, replace `commercial_partner_id.id` with `commercial_partner_id.ids`.

opw-3760372

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

Forward-Port-Of: odoo/odoo#157318

Point of sale receipt data is now prepared without relying on the broader POS session object. This makes receipt printing easier to maintain and more consistent across country-specific POS modules, with no expected change for cashiers or customers.

The method export_for_printing is used to export the order data to be printed in the receipt. This method was using the pos object to get information about the company, the cashier, the currency, etc.

This commit removes the use of the pos object from the export_for_printing

Corrects planning demo records so their start and end dates are always in the right order. This prevents demo data from failing validation on certain calendar days, making setup and testing more reliable.

In the demo data, we have two records with expressions like
```py
start_date = datetime.today() - relativedelta(weeks=2, weekday=4)
end_date = datetime.today() - relativedelta(weeks=2, weekday=5)
```
On 2024-03-23 (Saturday), these expressions give the values
```py
start_date = datetime.date(2024, 3, 15)
end_date = datetime.date(2024, 3, 9)
```
which makes a constraint checking `start_date < end_date` fail.

In order to make the computation correct, the solution is to compute end_date like start_date and add an extra day, like in
```py
start_date = datetime.today() - relativedelta(weeks=2, weekday=4)
end_date = start_date + relativedelta(days=1)
```

Uses `product_category_name` instead of `categ_id` when deciding how to sort SMLs in the barcode picking view. Previously, `categ_id` was used for sorting, however there are two issues with that: 1.) This would sort by the ID, not the name, which is probably not expected behavior. 2.) `categ_id` is actually always undefined in the `_sortingMethod` call because it is never passed into the front end in the first place. This fix adds `product_category_name` as a field to be read from the `s

Uses `product_category_name` instead of `categ_id` when deciding how to sort SMLs in the barcode picking view.

Previously, `categ_id` was used for sorting, however there are two issues with that:
1.) This would sort by the ID, not the name, which is probably not expected behavior.
2.) `categ_id` is actually always undefined in the `_sortingMethod` call because it is never passed into the front end in the first place.

This fix adds `product_category_name` as a field to be read from the `stock.move.line` within the `_get_stock_barcode_data` method of `stock_barcode/models/stock_picking.py`. It also changes `categ_id` to `product_category_name` with the `_sortingMethod` method of `stock_barcode/static/src/models/barcode_model.js`

As a final note, I am unsure if `categ_id` should be removed from the [`_get_fields_stock_barcode` method in `stock_barcode/models/product_product.py`](https://github.com/odoo/enterprise/blob/5b2fb8d0f3baf4fdc13e9399061110e06e3c76da/stock_barcode/models/product_product.py#L19). In this context it should be removed, however I'm unsure if other code may use it, and for compatibility sake it would be best  to leave it there.

opw-3693232

Forward-Port-Of: odoo/enterprise#59169
Forward-Port-Of: odoo/enterprise#56633

### Commit 1 [FIX] l10n_us_1099: clear lines when start or end date is changed Before this, setting the date fields to 2023 would show all 2023 lines in the wizard. Changing the date range to 2022 would add 2022 lines while keeping the 2023 lines. After this commit only 2022 lines remain in the wizard. opw-3774654 ### Commit 2 [FIX] l10n_us_1099: filter on date by default when adding new lines Typically a user clicks "Add a new line" on the lines_to_export o2m when they want to a

### Commit 1
[FIX] l10n_us_1099: clear lines when start or end date is changed

Before this, setting the date fields to 2023 would show all 2023 lines
in the wizard. Changing the date range to 2022 would add 2022 lines
while keeping the 2023 lines. After this commit only 2022 lines remain
in the wizard.

opw-3774654
### Commit 2
[FIX] l10n_us_1099: filter on date by default when adding new lines

Typically a user clicks "Add a new line" on the lines_to_export o2m
when they want to add lines in the selected date range from other
accounts. Currently the user is presented with all journal items and
will have to manually filter on the right date. Improve usability by
filtering on the right date range by default.

opw-3774654

Forward-Port-Of: odoo/enterprise#59180

In such a hierarchy: Clara -> Maxime -> Gregory Before this revision: Maxime and Gregory can validate Clara's timesheets, but only Maxime can edit fields of Clara's validated timesheets thanks to the fact he is the direct manager of Clara. Gregory is the manager of Clara by recursivity, and the recursivity was correctly handled in the validation check, but not in the edition of validated timesheets. After this revision: Maxime and Gregory can validate Clara's timesheets, Max

In such a hierarchy:

Clara -> Maxime -> Gregory

Before this revision:

Maxime and Gregory can validate Clara's timesheets,
but only Maxime can edit fields of Clara's validated timesheets thanks to the fact he is the direct manager of Clara.

Gregory is the manager of Clara by recursivity,
and the recursivity was correctly handled in the validation check, but not in the edition of validated timesheets.

After this revision:

Maxime and Gregory can validate Clara's timesheets,
Maxime and Gregory can edit fields of Clara's validated timesheets.

opw-3613473

Forward-Port-Of: odoo/enterprise#59088
Forward-Port-Of: odoo/enterprise#58782

This commit fixes the way we filter fields to show in the kanban editor sidebar, under the 'Add' tab. Since this view don't render what's included before the <templates> node from the xmlDoc. In other types of view, we can easily toggle the 'Show invisible' elements to display items that are considered being present in the view, but not in Kanban when they add items before the kanban card template. A test has been added too. task-3647045 Forward-Port-Of: odoo/enterprise#58911 Forward-P

This commit fixes the way we filter fields to show in the kanban editor sidebar, under the 'Add' tab. Since this view don't render what's included before the <templates> node from the xmlDoc.

In other types of view, we can easily toggle the 'Show invisible' elements to display items that are considered being present in the view, but not in Kanban when they add items before the kanban card template.

A test has been added too.

task-3647045

Forward-Port-Of: odoo/enterprise#58911
Forward-Port-Of: odoo/enterprise#57322

The purpose of this PR is to fix the broken links on the homepage of the barcode app in addition to the print links in the settings of Inventory and Manufacturing apps related to barcodes. Before, clicking on these links led to an error of `The action ... does not exist`. As dictated by odoo/enterprise#58078, urls now have to start with a "/" in order to work properly. Task-3821539 Forward-Port-Of: odoo/enterprise#59181

The purpose of this PR is to fix the broken links on the homepage of the barcode app in addition to the print links in the settings of Inventory and Manufacturing apps related to barcodes. Before, clicking on these links led to an error of `The action ... does not exist`. As dictated by odoo/enterprise#58078, urls now have to start with a "/" in order to work properly.

Task-3821539

Forward-Port-Of: odoo/enterprise#59181

- In PR #54687, a currency tag label "moneda" was added for all electronic documents and in the wrong position. - Fix the position to add the "moneda" tag for invoices, liquidations, credit notes and fix the tests for this electronic documents. Forward-Port-Of: odoo/enterprise#59087 Forward-Port-Of: odoo/enterprise#58932

- In PR #54687, a currency tag label "moneda" was added for all electronic documents and in the wrong position.
- Fix the position to add the "moneda" tag for invoices, liquidations, credit notes and fix the tests for this electronic documents.

Forward-Port-Of: odoo/enterprise#59087
Forward-Port-Of: odoo/enterprise#58932

The ir.rule in documents_spreadsheet opens too many doors. With the condition `'|', ('document_id', '=', False)`, the rule result is always `True` for comment threads which are not linked to a document (but linked to a dashboard or a spreadsheet template). Since all rules are OR-ed together, every operation is therefore allowed on threads on dashboards and templates, regardless of the user's rights on the underlying dashboard or template record.. Task: 3822402 Forward-Port-Of: odoo/e

The ir.rule in documents_spreadsheet opens too many doors.

With the condition `'|', ('document_id', '=', False)`, the rule result is always `True` for comment threads which are not linked to a document (but linked to a dashboard or a spreadsheet template).

Since all rules are OR-ed together, every operation is therefore allowed
on threads on dashboards and templates, regardless of the user's rights
on the underlying dashboard or template record..

Task: 3822402

Forward-Port-Of: odoo/enterprise#59200

The aim of this commit is to allow the user to make xslx export with custom composite report. Context: The customer made a custom report in which he is calling some other reports. Before this commit: Exporting the report would results in a traceback. This happenned because a keyError is raise when trying to access the `companies` key which isn't present in the dictionnary. The initializers for the `companies` key weren't consistent with each other. In some initializer, the `currenc

The aim of this commit is to allow the user to make xslx export with custom composite report.

Context:
The customer made a custom report in which he is calling some other reports.

Before this commit:
Exporting the report would results in a traceback.

This happenned because a keyError is raise when trying to access the `companies` key which isn't present in the dictionnary.

The initializers for the `companies` key weren't consistent with each other. In some initializer, the `currency_id` key was set. In other, it wasn't.
In method `_add_options_xlsx_sheet` only the exact same options were kept before pursuing the operations.
As the `currency_id` wasn't set for all the options, it was ignored.

After this commit:
The file can be exported with success.

To solve the `currency_id` key difference issue and prevent it to happen again, we centralize the place where the dictionnaries are created to be sure the exact same keys are set for the `companies` options regardless of how those companies are chosen.

opw-3802602

Forward-Port-Of: odoo/enterprise#58777

Sugar tax groups were not present in saas-16.2+ fw-port, due to the new way Chart Templates are handled. https://github.com/odoo/enterprise/pull/50366/files Adding them back now. Old PR for saas-16.2: odoo/enterprise#53209 Task link: http://www.odoo.com/web#id=3569752&model=project.task task-3569752 Forward-Port-Of: odoo/enterprise#59192 Forward-Port-Of: odoo/enterprise#58802

Sugar tax groups were not present in saas-16.2+ fw-port, due to the new way Chart Templates are handled.
https://github.com/odoo/enterprise/pull/50366/files

Adding them back now.

Old PR for saas-16.2: odoo/enterprise#53209
Task link: http://www.odoo.com/web#id=3569752&model=project.task
task-3569752

Forward-Port-Of: odoo/enterprise#59192
Forward-Port-Of: odoo/enterprise#58802

In studio, click on the "Automation" menu item. Create, or edit, one base.automation record, and modify some fields. Hit the button "Close" to get out of Studio. Before this commit, the base automation record was not saved. This was because the studio's action service did not receive the clear uncommitted changes from the main one. After this commit, the record is saved when we leave studio. Note that the ViewEditor mode should not be affected as we operate under a clean owl environmen

In studio, click on the "Automation" menu item.
Create, or edit, one base.automation record, and modify some fields. Hit the button "Close" to get out of Studio.

Before this commit, the base automation record was not saved. This was because the studio's action service did not receive the clear uncommitted changes from the main one.

After this commit, the record is saved when we leave studio.

Note that the ViewEditor mode should not be affected as we operate under a clean owl environment in StudioView.

Forward-Port-Of: odoo/enterprise#59086
Forward-Port-Of: odoo/enterprise#58862

Since this pr: https://github.com/odoo/enterprise/pull/51954, multiples test from test_company_branch were failing due to access rights. The reason is that in l10n_ma_report, we used a function called _get_reconciled_payments, that is a helper to retrieve the reconciled payments on a journal entry. This method will call _get_reconciled_amls (to retrieve the reconciled move lines on a journal entry) and then return the payment_id from the move. When being in the branch environment with an i

Since this pr: https://github.com/odoo/enterprise/pull/51954, multiples test from test_company_branch were failing due to access rights.

The reason is that in l10n_ma_report, we used a function called _get_reconciled_payments, that is a helper to retrieve the reconciled payments on a journal entry. This method will call _get_reconciled_amls (to retrieve the reconciled move lines on a journal entry) and then return the payment_id from the move.

When being in the branch environment with an invoice from the branch and a refund from the root company, doing the reconciliation between the two will cause an access right error.

The way we solved this, is to add a sudo so that we can access the move without having an error.

Task: 3802369

Forward-Port-Of: odoo/enterprise#59105

Impacted Version: - 17.0 and above This commit improve below features: - Create statement of account reports in follow-up reports task-3610441 Forward-Port-Of: odoo/enterprise#52098

Impacted Version:

- 17.0 and above

This commit improve below features:

- Create statement of account reports in follow-up reports

task-3610441

Forward-Port-Of: odoo/enterprise#52098

Link the brand new documentation in the settings. PR note: starting in saas-16.1 we can use `documentation=` instead.  Forward-Port-Of: odoo/enterprise#48340 Forward-Port-Of: odoo/enterprise#48040

Link the brand new documentation in the settings.

PR note: starting in saas-16.1 we can use `documentation=` instead.

![image](https://github.com/odoo/enterprise/assets/10252581/39200b10-98c1-44fc-9239-d7edf13976a1)

Forward-Port-Of: odoo/enterprise#48340
Forward-Port-Of: odoo/enterprise#48040

This fix corrects how withholding taxes are calculated on Colombian electronic invoices. Previously, the system used an inaccurate workaround that could cause invoices to be rejected by tax authorities. The update improves the calculation method to directly compute the VAT amount subject to withholding, ensuring accurate tax reporting and reducing document rejection issues.

### Context

In Colombia, a withholding tax is applied to the VAT, calculated as a percentage of the VAT amount. A typical scenario involves a VAT at 19% and a withholding tax at 15% of the VAT's 19%. The existing system constraints prevent directly using the value of one tax as the base for another, leading to a workaround by setting it to -2.85 (representing 15% of 19%).

### Problem

The electronic invoice requirements mandate the submission of base amounts and taxed values for each tax and invoice line. Due to our system's limitation in directly calculating the base for the withholding tax, our approach has been to reverse calculate the base using the tax amount divided by its rate. This method introduces inaccuracies because the tax amount is rounded, and those inaccuracies can in turn result in the electronic document being rejected.

### Solution

There's currently no way to properly fix this, so we have to rely on some dodgy programming. This commit changes the calculation method to focus on directly determining and computing the VAT amount subject to withholding. 


opw-3744872

Forward-Port-Of: odoo/enterprise#58894
Forward-Port-Of: odoo/enterprise#58377

This fix corrects an error in shipping cost calculations when using weight multiplied by volume as the pricing variable. Previously, shipping costs were incorrectly inflating with the square of order quantities because both weight and volume were being multiplied by quantity separately before being multiplied together. The fix ensures accurate pricing by introducing the weight*volume variable at the correct point in the calculation process.

Before this commit, when using a shipping method with the variable weight*volume for price computation, the price was growing with the square of the ordered quantities. This is because both volume and weight were multiplied by the quantity, before being multiplied with each other in the next step.

This commit fixes the issue by introducing the variable weight*volume at the beginning of the computation.

In order not to break anything in stable, the new variable is added as a kwarg to the useful methods.

OPW-3802315

Forward-Port-Of: odoo/odoo#158899
Forward-Port-Of: odoo/odoo#158767