This traceback arises when the user tries to create a new journal from the payment.

To reproduce this issue:

1) Install `accounting`
2) Create a new payment from `Accounting/vendors/payments` 
3) save the record and now remove the `journal` or make the `journal` field empty
5) A traceback arises.

Error:- 
```
KeyError: ('res.company', <function Company.__accessible_branches at 0x7fabdfc69c60>, (1,), False, 2)
  File "odoo/tools/cache.py", line 99, in lookup
    r = d[key]
  File "<decorator-gen-8>", line 2, in __getitem__
  File "odoo/tools/func.py", line 87, in locked
    return func(inst, *args, **kwargs)
  File "odoo/tools/lru.py", line 34, in __getitem__
    a = self.d[obj]
ValueError: not enough values to unpack (expected 1, got 0)
  File "odoo/models.py", line 5941, in ensure_one
    _id, = self._ids
ValueError: Expected singleton: res.company()
  File "odoo/http.py", line 2251, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1826, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1847, 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 1824, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1832, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2057, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 740, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 34, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 30, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "addons/web/models/models.py", line 1074, in onchange
    todo = [
  File "addons/web/models/models.py", line 1077, in <listcomp>
    if field_name not in done and snapshot0.has_changed(field_name)
  File "addons/web/models/models.py", line 1190, in has_changed
    return self[field_name] != self.record[field_name]
  File "odoo/models.py", line 6664, in __getitem__
    return self._fields[key].__get__(self, self.env.registry[self._name])
  File "odoo/fields.py", line 1138, in __get__
    self.recompute(record)
  File "odoo/fields.py", line 1353, in recompute
    apply_except_missing(self.compute_value, recs)
  File "odoo/fields.py", line 1326, in apply_except_missing
    func(records)
  File "odoo/fields.py", line 1375, in compute_value
    records._compute_field_value(self)
  File "addons/mail/models/mail_thread.py", line 416, in _compute_field_value
    return super()._compute_field_value(field)
  File "odoo/models.py", line 4982, in _compute_field_value
    fields.determine(field.compute, self)
  File "odoo/fields.py", line 102, in determine
    return needle(*args)
  File "addons/account/models/account_payment.py", line 369, in _compute_reconciliation_status
    liquidity_lines, counterpart_lines, writeoff_lines = pay._seek_for_lines()
  File "addons/account/models/account_payment.py", line 192, in _seek_for_lines
    if line.account_id in self._get_valid_liquidity_accounts():
  File "addons/account/models/account_payment.py", line 211, in _get_valid_liquidity_accounts
    accessible_branches = journal_comp.with_company(journal_comp)._accessible_branches()
  File "odoo/addons/base/models/res_company.py", line 420, in _accessible_branches
    return self.browse(self.__accessible_branches())
  File "<decorator-gen-107>", line 2, in __accessible_branches
  File "odoo/tools/cache.py", line 104, in lookup
    value = d[key] = self.method(*args, **kwargs)
  File "odoo/addons/base/models/res_company.py", line 402, in __accessible_branches
    self.ensure_one()
  File "odoo/models.py", line 5944, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
```
When the user removes the journal, the company ID is taken from the journal, which leads to a traceback  from the line below.

https://github.com/odoo/odoo/blob/53d6d795ddf6cc9e470bfeb48bb31bc728acedbe/addons/account/models/account_payment.py#L207-L208

After applying this commit, resolve this issue by taking the default company, 
when there is no journal.

sentry-5054332731

Forward-Port-Of: odoo/odoo#157337

Issue:

- when we have a shipping method that has a discount the shipping and the delivery prices are not displayed correctly (see attached screenshot).

Steps To Reproduce:

- configure the sale app to have the discount&loyalty and free shipping options enabled.
- create a product that cost 100$.
- create a new discount/loyalty where type is promotions and set rule to if minimum 300$ spent the reward is free shipping max to 75$.
- create a shipping method based on rules where the delivery product is a service that costs 100$.
- in your shipping mehtod pricing add a line with if quantity >= 3.0 then fixed price 100.0 and publish it.
- in your website shop select 3 items from the product you created. and select your delivery method.
- notice the prices not updating correctly.

Solution:
- Before the fix we always assumed that free_shipping_lines are
equal to 0.

- free_shipping_lines might be shipping discounts not actual free
shipping.so I adjusted update_eshop_carrier method to make it handle the
 case of discounted shipping.

opw-3718885


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

Forward-Port-Of: odoo/odoo#167794
Forward-Port-Of: odoo/odoo#154487

### Steps to reproduce:
- Install **POS** app.
- Go to **POS** > **Products** > **Discount & Loyalty**
- Create a New program with: 
    - **Program Type:** Loyalty Cards 
    - Conditional rules: 
        - **Minimum Quantity:** 2 
        - **Grant:** 1 Loyalty Points per unit paid
    - Rewards: 
        - **Reward Type:** Discount 
        - **Discount:** 100 % one Cheapest Product 
        - **In exchange of:** 2 Loyalty Points
- Start a new POS session
- Select a Customer
- Add two different products.
- Notice the Loyalty Points of **+2** shown. This is _Correct_
- Click on the **Reward** button
- Notice how the Loyalty Points are now **+3** which is obviously _wrong_ given we only have two products. Basically it's as if the reward line (100% discount) is taken into consideration as the cheapest product.

### Investigation:
- Inside `_updatePrograms`, `pointsForPrograms()` are calculated.
- we sum the lines quantities regardless of whether it's a reward line or not https://github.com/odoo/odoo/blob/e5c3ba58964f47cfd41d337e39e1bf25eaa25379/addons/pos_loyalty/static/src/js/Loyalty.js#L906
- By doing so, the reward lines are taken into consideration and the rule is triggerd by skipping this if clause https://github.com/odoo/odoo/blob/e5c3ba58964f47cfd41d337e39e1bf25eaa25379/addons/pos_loyalty/static/src/js/Loyalty.js#L917-L921

opw-3855323

Forward-Port-Of: odoo/odoo#165833
Forward-Port-Of: odoo/odoo#161503

This traceback arises when the user tries to remove the Batch Limit value and test the imported file.

To reproduce this issue:

1) Import a file with large data in any module
2) You see the Batch limit at the left side pannel
3) Remove the default "Batch Limit" value
4) Test the file
5) A traceback will encountered

Error:- 
```
TypeError: '<' not supported between instances of 'int' and 'str'
```

when the user removes  the default batch limit its value will be an empty string.

You can see in [1] that parseFloat('') is "NaN"  so it directly assigns the limit as the value which is an empty string.

[1]
https://github.com/odoo/odoo/blob/2c40a55232fb501dd70b64f7ddbdc4244f365139/addons/base_import/static/src/import_data_sidepanel/import_data_sidepanel.js#L34-L36

which leads to a traceback when a comparison is done between int and str.

https://github.com/odoo/odoo/blob/106c343027e3bab1c94c414f30e914cf673cceec/odoo/models.py#L1318-L1319

After applying this commit will resolve the issue of getting an int value instead of a str.

sentry-5298904064

Forward-Port-Of: odoo/odoo#167323

**Steps to reproduce:**
- Install Sales & Accounting
- Create a second company with a different currency (e.g. AED) than the first one (e.g. USD)
- Configure the rounding factor of the currency of the second company to 1.000000
- Configure the default company of the current user to the second company
- Switch to the second company
- In Accounting settings, set "Rounding Method" to "Round Globally"
- Switch to the first company
- Create a SO:
  * Customer: [any]
  * Order Lines: [any line with a tax]
- Save the SO
- Edit the SO by changing the price unit of the product !!! Make sure that the tax amount has a decimal part
- Save the SO

**Issue:**
In the chatter, the note about the new value of the tracked field Total is different from the Total value shown in the SO. Also, in Customer Preview, the total to pay shown on the upper-left of the page is different than the total shown in the SO details.

**Cause:**
After save, the taxes are recomputed on the SO lines after a "flush_all" triggered by "call_kw" method.
The computed values are rounded depending on the rounding factor of the currency of the current company (i.e. self.env.company).
However, "allowed_company_ids" being absent in the context, the current company cannot be computed correctly and a fallback is made on the default company of the current user.
Unfortunately, the default company of the current user is different than the real current company, leading to a different currency having a different rounding factor.
In this case, the tax values are rounded to the unity, which is not correct.

**Solution:**
Specify the company configured on the SO line when computing its taxes.

opw-3814058



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

Forward-Port-Of: odoo/odoo#168811
Forward-Port-Of: odoo/odoo#168723

## Issue:
When configuring an employee before sending the salary configurator, if we set up children and disabled children for the employee, the option to enable/disable them in the salary configurator does not appear.

## Steps To Reproduce:
- on the runbot change the company to "my Belgian company".
- In Laurie Poiret's employee profile, on the "personal information" tab, change the value for children to 2 and set 1 as disabled.
- Go to Laurie Poiret's contract (stat button) and generate an offer.
- From the offer, navigate to the salary configurator.
- In the salary configurator, proceed until you reach the family status section.
- Notice that the "Disabled children" Toggle does not appear unless you change the value of the children input.
## Solution:
- The `onchangeChildren` method is being invoked in the `start` method without an `event` argument (`event` is `undefined`). This results in `event.currentTarget` being `undefined`, causing the `childCount` variable to be `NaN` and `disabledChildrenNumber` to get disabled at the end of the method.
- to fix the problem, we added a check for `event` argument in the event handler, if it is not present, we fallback to getting the children input value using JQuery and it solves the issue.

**opw-3925640**

Forward-Port-Of: odoo/enterprise#64347
Forward-Port-Of: odoo/enterprise#63535

### Steps to reproduce the issue:

1. Go to _Settings > Technical > Email > Email Templates_
2. Select a template that applies to a Contact
3. Add a mail address in the Cc field
4. Go to _Accounting > Customers > Follow-up Reports_ select one of the reports
5. Click on "Follow up"
6. Select the template with the Cc in the Content Template field
7. The Cc address is not added to the Email Recipients field
8. Click on Send Message in the chatter
9. Open the full view and add the template with the Cc in the Load template field
10. The Cc address is added to the Recipients field

### Explanation:

The field `email_recipient_ids` is not a computed field. Because of it, there is no change called when `template_id` is assigned a new value.

### Suggested fix:

We need to change `email_recipients_ids` according to `template_id` while keeping its current properties (stored, writable).

The method is adapted from `mail.compose.message._compute_partner_ids`.
https://github.com/odoo/odoo/blob/1849b709f1acf0f5546582bf7551129a870e3113/addons/mail/wizard/mail_compose_message.py#L482-L496

opw-3878125

Forward-Port-Of: odoo/enterprise#63918
Forward-Port-Of: odoo/enterprise#61861

With an MX company setup
Create a product with:
- UNSPSC Category: 12352106 Ácidos orgánicos o sus sustitutos
- Hazardous Material Designation Code (MX):
- Hazardous Packaging (MX):
- Tariff Fraction: 2917190800 Ácido fumárico.
- UMT Aduana: kg
- Weight: 1.00

Create a Sale Order with the product
Confirm
Go to Delivery
Set:
- Tansport Type: Federal Highways
- In MX Tab add 'Vehicle Setup' and 'Gross Vehicle Weight'

Validate and Generate Delivery Guide

Error:
Code : CP155 Message : El valor registrado en el atributo "Mercancia:MaterialPeligroso"
no es válido o el valor registrado en el atributo “Mercancias:Mercancia:BienesTransp”
contiene el valor "0" (cero) en la columna "Material peligroso" del catálogo catCartaPorte:c_ClaveProdServCP.

This occurs because the MarierialPeligroso element is not filled
In the ClaveProdServ tab of the CatalogoCartaPorte30 it is specified
if a product or service is (1), not is (0) or may be (0,1) considered hazardous
When having to deal with "may be" hazardous products it is required to set
the 'MaterialPeligroso' element.
Currently, the system does not allow to specify if the "may be" product is
actually hazardous, but if the 'Hazardous Material Designation Code
(MX)' field is not set the MaterialPeligroso element will not be filled,
failing the validation

The proposed workaround is to use the value '0' as flag to indicate
that the maybe hazardous product should not be considered hazardous and
'MaterialPeligroso' will be set to 'No'

opw-3955361
task-3668225

Forward-Port-Of: odoo/enterprise#64153
Forward-Port-Of: odoo/enterprise#63832