Reproduce the issue: - have an employee with one accrual allocation valid today - the allocation ends at a certain date - on his dashboard with the date picker, select a date after the allocation end - the date picker disappears Expected behaviour: - The date picker should stay on the view task-3984127 Forward-Port-Of: odoo/odoo#172400 Forward-Port-Of: odoo/odoo#169021

Reproduce the issue:
- have an employee with one accrual allocation valid today
- the allocation ends at a certain date
- on his dashboard with the date picker, select a date after the allocation end
- the date picker disappears

Expected behaviour:
- The date picker should stay on the view

task-3984127

Forward-Port-Of: odoo/odoo#172400
Forward-Port-Of: odoo/odoo#169021

stdnum library incorrectly sets zeep Transport timeout, resulting in some requests hanging for 15 minutes. With this monkeypatch the timeout will be set correctly. Zeep github issue: mvantellingen/python-zeep#140 opw-3980718 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172080 Forward-Por

stdnum library incorrectly sets zeep Transport timeout, resulting in some requests hanging for 15 minutes. With this monkeypatch the timeout will be set correctly.
Zeep github issue: mvantellingen/python-zeep#140

opw-3980718

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#172080
Forward-Port-Of: odoo/odoo#171722

Trying to edit custom javascript: - Outside of developer mode, doesn't highlight the code - In developer mode, fails with a props validation error Steps to reproduce: - Stay in normal mode / Switch to developer mode - Go to Website > Homepage - Click on the "Site" menu - Click on "HTML / CSS Editor" - Click on "Edit HTML anyway" - In the file type dropdown (top left of the code editor right panel), select "JS" Old behavior: Code is not highlighted / CodeEditor props validation

Trying to edit custom javascript:
- Outside of developer mode, doesn't highlight the code
- In developer mode, fails with a props validation error

Steps to reproduce:
- Stay in normal mode / Switch to developer mode
- Go to Website > Homepage
- Click on the "Site" menu
- Click on "HTML / CSS Editor"
- Click on "Edit HTML anyway"
- In the file type dropdown (top left of the code editor right panel),
  select "JS"

Old behavior: Code is not highlighted / CodeEditor props validation
error (invalid mode)
New behavior: Code is properly highlighted, no error

This issue is happening since commit [1] because the ace CodeEditor
mode "js" was renamed to "javascript".

This commit fixes this by mapping the `ResourceEditor` type `js` to the
`CodeEditor` mode `javascript`.

This commit adds a class to the CodeEditor component usable by tests to
detect when the ace editor has changed mode.

[1]: 3e6a6d34702b2145ff998abcdf0a60ff9fbcd873

opw-3963421

Forward-Port-Of: odoo/odoo#172347
Forward-Port-Of: odoo/odoo#169413

Since 17.0 activity view now has a pager, which is not working at all. Actually there are two problems fixed in this commit - Frontend problem fixed in activity_controller.js - Backend problem fixed in mail_activity.py # First problem: Steps: - Install a module with activity view (`sale_management` for example) - Open activity view Let's say we have 4 records, at the loading of the view a request to `get_activity_data` with the following domain in the payload ``

Since 17.0 activity view now has a pager, which is not working at all.

Actually there are two problems fixed in this commit
    - Frontend problem fixed in activity_controller.js
    - Backend problem fixed in mail_activity.py

# First problem:

Steps:
    - Install a module with activity view (`sale_management` for example)
    - Open activity view

Let's say we have 4 records, at the loading of the view a request to
`get_activity_data` with the following domain in the payload
```json
{
   "domain": [
      ["user_id", "=", 2],
      ["activity_ids.active", "in", [true, false]]
   ]
}
```
the response contains for example
```json
{
    "activity_res_ids": [
        3,
        19,
        4,
        7
    ]
}
```
This is correct, the problem comes if we try to "refresh" the view
with the pager, by clicking in the pager's input and press enter
(without changing anything).
Normally it will be exactly the same request as the one above.
But the domain is not the same this time
```json
{
    "domain": [["user_id", "=", 2]]
}
```
Because of this `get_activity_data` returns incorrect data.

To fix this issue we have to do the same thing as here in the pager onUpdate()

https://github.com/odoo/odoo/blob/e11e3ca447fa2997b51a39cefc3457ae411ccb3c/addons/mail/static/src/views/web/activity/activity_model.js#L12

# Second problem:

When the model contains a different order than 'id' `get_activity_data`
can returns incorrect data since we don't specify `order` in `_search`

opw-[3862389](https://www.odoo.com/web#id=3862389&view_type=form&model=project.task)

Forward-Port-Of: odoo/odoo#172294
Forward-Port-Of: odoo/odoo#164713

### Steps to reproduce the issue: 1. Create a Tax Based On Payment with a Cash Basis Transition Account 2. Create an Expense Paid By Company and add previously created Tax 3. Create the report, submit it, approve it then Post Journal Entries 4. Go to the Journal Entry (until you see the Journal Items) 5. The Journal Item of the Tax is recorded on the Cash Basis Transition Account but no Caba Entry is created ### Explanation: When using the company to pay the expense, the payment is

### Steps to reproduce the issue:

1. Create a Tax Based On Payment with a Cash Basis Transition Account
2. Create an Expense Paid By Company and add previously created Tax
3. Create the report, submit it, approve it then Post Journal Entries
4. Go to the Journal Entry (until you see the Journal Items)
5. The Journal Item of the Tax is recorded on the Cash Basis Transition Account but no Caba Entry is created

### Explanation:

When using the company to pay the expense, the payment is immediate. When the employee took care of the payment, a Bill and a Caba Entry are created because the company still needs to reimburse the employee.

### Suggested fix:

Adding a Caba Entry is not necessary since there is no need to record the transaction in a transitional account, sending the transaction in the final Account would also match the use case when using Taxes Based On Invoice.
`account_id` is selected between the `cash_basis_transition_account_id` of the tax and the `account_id` of the repartition line depending on the values of `tax_exigibility` and `caba_no_transition_account`.
https://github.com/odoo/odoo/blob/0c0f0b58aa49cff1efafcc1d4c5a9091e99f2ff4/addons/account/models/account_tax.py#L640-L642 The latter is a context key and is only used in this check, meaning it is most likely harmless to add it in the context of the method.

opw-3946362

Forward-Port-Of: odoo/odoo#172307
Forward-Port-Of: odoo/odoo#169255

Multiple fixes related to Audit Trail: * track more fields: * <account.move.line>.balance * <account.move.line>.tax_tag_ids * <account.tax>.l10n_de_datev_code * <res.company>.l10n_de_widnr * Track newly created lines once the move has been posted * Prevent deleting tracking messages/values linked to the audit trail [task-4018800](https://www.odoo.com/odoo/project.task/4018800?cids=1) Forward-Port-Of: odoo/odoo#172209 Forward-Port-Of: odoo/odoo#171244

Multiple fixes related to Audit Trail:
* track more fields:
  * <account.move.line>.balance
  * <account.move.line>.tax_tag_ids
  * <account.tax>.l10n_de_datev_code
  * <res.company>.l10n_de_widnr
* Track newly created lines once the move has been posted
* Prevent deleting tracking messages/values linked to the audit trail

[task-4018800](https://www.odoo.com/odoo/project.task/4018800?cids=1)

Forward-Port-Of: odoo/odoo#172209
Forward-Port-Of: odoo/odoo#171244

An indeterministic error was present in the pos_loyalty module. This was due to the fact that when the user changed the partner a request to retrieve the loyaltyCards already existing for this partner was made by a different series of function calls. In fine, the call was not awaited, so when another method wanted to retrieve the loyaltyCards for the same partner, a new card was created and then overridden to null by the result of the call to the server. To correct this error, the cal

An indeterministic error was present in the pos_loyalty module. This was
due to the fact that when the user changed the partner a request to
retrieve the loyaltyCards already existing for this partner was made by
a different series of function calls.

In fine, the call was not awaited, so when another method wanted to
retrieve the loyaltyCards for the same partner, a new card was created
and then overridden to null by the result of the call to the server.

To correct this error, the call to the server to retrieve the cards
is made when the partner is changed. At this point the request is
awaited.

Runbot Error: [57047](https://runbot.odoo.com/web/#id=57047&view_type=form&model=runbot.build.error&menu_id=405&cids=1)

Forward-Port-Of: odoo/odoo#171226

This commit adds a check to prevent errors when a reward product is archived. opw-4012282 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172484 Forward-Port-Of: odoo/odoo#171175

This commit adds a check to prevent errors when a reward product is archived.

opw-4012282

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

Forward-Port-Of: odoo/odoo#172484
Forward-Port-Of: odoo/odoo#171175

Before this commit the recipients list displayed when sending a message on the chatter missed spacing between the recipients and conjunctions. This happens because the container has display flex which removes whitespace from child elements. This commit fixes the issue by wrapping the list in a div tag so to preserve the whitespace. task-4032550 Before:  After: ![image](https://github.com/o

Before this commit the recipients list displayed when sending a message on the chatter missed spacing between the recipients and conjunctions.

This happens because the container has display flex which removes whitespace from child elements.

This commit fixes the issue by wrapping the list in a div tag so to preserve the whitespace.

task-4032550

Before:
![image](https://github.com/odoo/odoo/assets/32620115/81b878f3-17a6-44a4-b392-333c11452ea6)

After:
![image](https://github.com/odoo/odoo/assets/32620115/c9cb7e10-bdfa-4714-a73a-acb2af376c98)

Forward-Port-Of: odoo/odoo#171899

- customer display hidden in mobile view. task - 4016199 Forward-Port-Of: odoo/odoo#171364

- customer display hidden in mobile view.

task - 4016199

Forward-Port-Of: odoo/odoo#171364

Uninstall l10n_ar_withholding Install again l10n_ar_withholding Issue: Reinstall will fail with error odoo.exceptions.ValidationError: Invoice and credit note distribution should each contain exactly one line for the base. This occurs because the system attempt to create a tax repartition line in existing tax instead of updating the data opw-3946193 Forward-Port-Of: odoo/odoo#172093

Uninstall l10n_ar_withholding
Install again l10n_ar_withholding

Issue:
 Reinstall will fail with error
 odoo.exceptions.ValidationError: Invoice and credit note distribution should each contain exactly one line for the base.

This occurs because the system attempt to create a tax repartition line in
existing tax instead of updating the data

opw-3946193

Forward-Port-Of: odoo/odoo#172093

An error occurs when the system tries to retrieve 'session_id' at [1] from 'MerchantTrns' but it is not available. Because of failed transactions (Ref: https://developer.viva.com/webhooks-for-payments/transaction-failed/#response-example) link [1]: https://github.com/odoo/odoo/blob/319cf81da8f16df21900f26bd6d8b4fc686e72eb/addons/pos_viva_wallet/models/pos_payment_method.py#L113 To resolve this issue, add a condition to check if 'MerchantTrns' is not available in 'data_webhook' then raise a

An error occurs when the system tries to retrieve 'session_id' at [1] from 'MerchantTrns' but it is not available. Because of failed transactions (Ref: https://developer.viva.com/webhooks-for-payments/transaction-failed/#response-example)

link [1]: https://github.com/odoo/odoo/blob/319cf81da8f16df21900f26bd6d8b4fc686e72eb/addons/pos_viva_wallet/models/pos_payment_method.py#L113

To resolve this issue, add a condition to check if 'MerchantTrns' is not available in 'data_webhook' then raise an error as send notification.

Sentry - 5466498742

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

Forward-Port-Of: odoo/odoo#171764

When customer pay using viva wallet, a traceback will appear. First, the method was called from the public controller at line [1]. From the public controller, the method from model was called at [2], where access right was checked by the code. But since the method was called from the controller, we do not have any users in the environment, so the below error will occur. Traceback: ``` ValueError: not enough values to unpack (expected 1, got 0) File "odoo/models.py", line 5851, in

When customer pay using viva wallet, a traceback will appear.

First, the method was called from the public controller at line [1].
From the public controller, the method from model was called at [2],
where access right was checked by the code.
But since the method was called from the controller,
we do not have any users in the environment,
so the below error will occur.

Traceback:
```
ValueError: not enough values to unpack (expected 1, got 0)
  File "odoo/models.py", line 5851, in ensure_one
    _id, = self._ids
ValueError: Expected singleton: res.users()
  File "odoo/http.py", line 2248, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1823, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1843, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1821, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1828, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1966, in dispatch
    return self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 756, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/pos_viva_wallet/controllers/main.py", line 24, in notification
    payment_method_sudo._retrieve_session_id(data_webhook)
  File "addons/pos_viva_wallet/models/pos_payment_method.py", line 115, in _retrieve_session_id
    data = self._call_viva_wallet(endpoint, 'get')
  File "addons/pos_viva_wallet/models/pos_payment_method.py", line 99, in _call_viva_wallet
    session.headers.update(self._bearer_token(session))
  File "addons/pos_viva_wallet/models/pos_payment_method.py", line 58, in _bearer_token
    if not self.env.user.has_group('point_of_sale.group_pos_user'):
  File "odoo/addons/base/models/res_users.py", line 1120, in has_group
    self.ensure_one()
  File "odoo/models.py", line 5854, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
```

[1] https://github.com/odoo/odoo/blob/5d065006005a18836b83e7309193864ac6e303f7/addons/pos_viva_wallet/controllers/main.py#L24

[2]- https://github.com/odoo/odoo/blob/5d065006005a18836b83e7309193864ac6e303f7/addons/pos_viva_wallet/models/pos_payment_method.py#L58-L59

sentry-5563172568

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

Forward-Port-Of: odoo/odoo#171874

Before this commit, searching for internal references or barcodes with less than 6 characters would result in a fuzzy search, even when an exact match was available. This behavior was based on the assumption that barcodes and internal references are at least 6 characters long. opw-4029891 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171774

Before this commit, searching for internal references or barcodes with less than 6 characters would result in a fuzzy search, even when an exact match was available. This behavior was based on the assumption that barcodes and internal references are at least 6 characters long.

opw-4029891

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

Forward-Port-Of: odoo/odoo#171774

In a receipt picking, you can automatically set the Serial/Lots with 3 actions: 'Generate Serial/Lots' / 'Import Serial/Lots' / 'Assign Serial Numbers'. However, if 'use_existing_lots' is True on the picking type, the resulting move lines will appear without lots on the frontend. This is because these actions only set the lot_name, not the lot_id. After this commit, these 3 actions will use lot_id instead of lot_name if 'use_existing_lots' is True. They will either assign an existing 'stoc

In a receipt picking, you can automatically set the Serial/Lots with 3 actions: 'Generate Serial/Lots' / 'Import Serial/Lots' / 'Assign Serial Numbers'. However, if 'use_existing_lots' is True on the picking type, the resulting move lines will appear without lots on the frontend.

This is because these actions only set the lot_name, not the lot_id.

After this commit, these 3 actions will use lot_id instead of lot_name if 'use_existing_lots' is True. They will either assign an existing 'stock.lot' or create a new one in the correct company.

---

## BEFORE


https://github.com/odoo/odoo/assets/29302288/f571d68d-86cb-42bf-bf8b-5e918c2ca2c2


## AFTER


https://github.com/odoo/odoo/assets/29302288/325c7870-a24a-4094-b0c0-5ff8274712d8


---

OPW-3983532

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

Forward-Port-Of: odoo/odoo#171926
Forward-Port-Of: odoo/odoo#171388

Added tax report, taxes, tax groups, fiscal positions, and translated accounts. The czech l10n package was not properly setup. The tax report was missing, and wrong taxes and tax groups were used. Moreover, COA was added in czech only. task-3127683 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172506 Forward-Port-Of: odoo/odoo#158828

Added tax report, taxes, tax groups, fiscal positions, and translated accounts.

The czech l10n package was not properly setup. The tax report was missing, and wrong taxes and tax groups were used.
Moreover, COA was added in czech only.

task-3127683

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

Forward-Port-Of: odoo/odoo#172506
Forward-Port-Of: odoo/odoo#158828

We were removing the `res_id` in SQL to avoid raising when the audit trail is activated (because we cannot modify an attachment anymore) But it still failed when the value was still in cache. [opw-4040187](https://www.odoo.com/odoo/project/49/tasks/4040187) Forward-Port-Of: odoo/odoo#172355

We were removing the `res_id` in SQL to avoid raising when the audit trail is activated (because we cannot modify an attachment anymore) But it still failed when the value was still in cache.

[opw-4040187](https://www.odoo.com/odoo/project/49/tasks/4040187)

Forward-Port-Of: odoo/odoo#172355

Since unlinking `ir.attachment` is done after removing the record from the database, and the cache is already invalidated, we cannot browse `res_id` anymore. Also improve the prefetching for all messages being unlinked at the same time if related to different moves. Forward-Port-Of: odoo/odoo#172228

Since unlinking `ir.attachment` is done after removing the record from the database, and the cache is already invalidated, we cannot browse `res_id` anymore.

Also improve the prefetching for all messages being unlinked at the same time if related to different moves.

Forward-Port-Of: odoo/odoo#172228

[FIX] l10n_tr: Fix migration script's execution phase This is a follow up to https://github.com/odoo/odoo/pull/167258 When we trigger the upgrade button of the package, We get an error that 'create_asset' field is null even that field has a default value The issue is not specified yet, Reaching the upgrade team to get their input changing the phase from 'post-' to 'end-' task-id#3924220 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forwa

[FIX] l10n_tr: Fix migration script's execution phase

This is a follow up to https://github.com/odoo/odoo/pull/167258
When we trigger the upgrade button of the package, We get an error that 'create_asset' field is null even that field has a default value
The issue is not specified yet, Reaching the upgrade team to get their input

changing the phase from 'post-' to 'end-'

task-id#3924220

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

Forward-Port-Of: odoo/odoo#172478

Related ticket: 4000939 Forward-Port-Of: odoo/enterprise#66407

Related ticket: 4000939

Forward-Port-Of: odoo/enterprise#66407

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

Steps to reproduce: ------------------- - Install 'Documents' and 'Accounting' modules - Go to document settings > Activate Accounting + go to "Journal" smart link then create a synchronized with Vendor Bills journal - Go to accounting setting > Activate "Document Digitization" and select "Digitize automatically" for bills - Send a PDF to the Vendor bill mail alias - Open the created bill Issue: ------ Error in the chatter. Cause: ------ We try to set on the document an att

Steps to reproduce:
-------------------

- Install 'Documents' and 'Accounting' modules
- Go to document settings > Activate Accounting + go to "Journal" smart link then create a synchronized with Vendor Bills journal
- Go to accounting setting > Activate "Document Digitization" and select "Digitize automatically" for bills
- Send a PDF to the Vendor bill mail alias
- Open the created bill

Issue:
------

Error in the chatter.

Cause:
------

We try to set on the document an attachment already linked to it, and because it goes through the versioning code, it will first link the new attachment to the record (who was already the case), and then link the old attachment (who is the same attachment as the new) to the document.

Solution:
---------

If trying to set the same attachment already linked to the document, we skip the versioning code.

opw-4034699

Forward-Port-Of: odoo/enterprise#66361

The test `Selecting the cell with a unsolved thread does not open the thread popover` is wrong. The thread popover should open for unsolded threads, it's for resolved threads that it should not open. Running the test in debug make it clear that the threads popoved is opened. I'm not sure how the test was somehow passing. Task: [4042515](https://www.odoo.com/web#id=4042515&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#66297

The test `Selecting the cell with a unsolved thread does not open the thread popover` is wrong. The thread popover should open for unsolded threads, it's for resolved threads that it should not open. Running the test in debug make it clear that the threads popoved is opened. I'm not sure how the test was somehow passing.

Task: [4042515](https://www.odoo.com/web#id=4042515&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)

Forward-Port-Of: odoo/enterprise#66297

Before this commit: When the user chooses a pickup point, the res.partner of the sale order is replaced with data from the pickup point, while the previously set customer's data is set as the partner's parent. And Sendcloud relies on a service_point_id field in its API rather than a raw address. Which causes double printing of the service point address on the label. Moreover, Sendcloud explicitly requires the customer's (and not the pickup point) address in its API. After this commit:

Before this commit:

When the user chooses a pickup point, the res.partner of the sale order is replaced with data from the pickup point, while the previously set customer's data is set as the partner's parent. And Sendcloud relies on a service_point_id field in its API rather than a raw address.

Which causes double printing of the service point address on the label.
Moreover, Sendcloud explicitly requires the customer's (and not the pickup point) address in its API.

After this commit:

Both the service_point_id and the customer's delivery address are sent to Sendcloud. Both addresses are printed on the label correctly.

opw-3977565

Forward-Port-Of: odoo/enterprise#65354

Forward-Port-Of: odoo/enterprise#66315

Forward-Port-Of: odoo/enterprise#66315

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#66244
Forward-Port-Of: odoo/enterprise#65073

*l10n_account_customer_statements,l10n_my_reports,l10n_us_reports Currently some reports add buttons on their lines to perform some action on them. However, when prefix groups are used, the buttons are also shown on these lines, but refer to nothing and will thus either cause an error when clicked or lead to a new record. This commit fixes that by providing a generic hook in the `line_name` template to inject buttons. This generic hook checks whether the line is a prefix group line and doe

*l10n_account_customer_statements,l10n_my_reports,l10n_us_reports

Currently some reports add buttons on their lines to perform some action on them. However, when prefix groups are used, the buttons are also shown on these lines, but refer to nothing and will thus either cause an error when clicked or lead to a new record.

This commit fixes that by providing a generic hook in the `line_name` template to inject buttons. This generic hook checks whether the line is a prefix group line and doesn't render the buttons if it is.

All other reports were adapted to use this hook now.

task-3932945

Forward-Port-Of: odoo/enterprise#65270

before this commit: Insurance amount was sent in rating request but not in shipping request. Resulting in no insurance amount being printed on label. After this commit: If the insurance amount is sent, it is added to the shipping request and gets printed on label. opw-3845693 Forward-Port-Of: odoo/enterprise#66036

before this commit:
Insurance amount was sent in rating request but not in shipping request. Resulting in no insurance amount being printed on label.

After this commit:
If the insurance amount is sent, it is added to the shipping request and gets printed on label.

opw-3845693

Forward-Port-Of: odoo/enterprise#66036

Added XML export options of the czech tax report. Most of the work in here was copied from the previous xml export implemented in this commit: https://github.com/odoo-dev/enterprise/commit/32c9a215a74123a2bf7f984421c729c89318e300 task-3127683 Forward-Port-Of: odoo/enterprise#66363 Forward-Port-Of: odoo/enterprise#61200

Added XML export options of the czech tax report.
Most of the work in here was copied from the previous xml export implemented in this commit: https://github.com/odoo-dev/enterprise/commit/32c9a215a74123a2bf7f984421c729c89318e300

task-3127683

Forward-Port-Of: odoo/enterprise#66363
Forward-Port-Of: odoo/enterprise#61200

Since the audit trail is mandatory in Germany, we cannot remove moves or any documents related. We only need to remove the moves linked to the company of the tour. Forward-Port-Of: odoo/enterprise#66226

Since the audit trail is mandatory in Germany, we cannot remove moves or any documents related.
We only need to remove the moves linked to the company of the tour.

Forward-Port-Of: odoo/enterprise#66226