Commit 1
========

Steps to reproduce the issue:
- add comment to a Facebook/youtube post.
- keeping the `Comments` dialog box open, try replying the same comment.
- we get a traceback.

Reason:
- due to the missing comments data structure, we get an error when trying to add the new comment.
- LOC responsible for the traceback: https://github.com/odoo/enterprise/blob/16.0/social/static/src/xml/social_templates.xml#L311

Fix:
- since the comments data structure is not returned from the post request made to post the commnet, we manually ensure it exists.

Commit 2
========

[FIX] social: fix various issues
1. social_instagram:

ISSUES:
- create a post on the instagram platform with commenting turned off.
- try commenting on it from Odoo. We get a traceback.
- also, if we delete the post from the platform and then try to comment from Odoo,
  we get a traceback.

REASON:
- there is no existing implementation to check if commenting is enabled/disabled
  on the post.

FIX:
- we now check if commenting is enabled or not while trying to add comment on the post

TECHNICAL NOTE:
- the correct way to check if commenting on a post is enabled or not is to request
  a field named `is_comment_enabled`.
- more details --- https://developers.facebook.com/docs/instagram-platform/instagram-graph-api/reference/ig-media
- but to save us from making an extra request, we simply catch the error received to
  when trying to add a comment.

================================================================================

2. social_linkedin

ISSUE:
- delete an existing post from the linkedIn platform.
- now try commenting on it from Odoo. We get a traceback.

REASON:
- The response received from the request to fetch the comments is not validated.

FIX:
- validating the response before further execution.

Task-3759530

Forward-Port-Of: odoo/enterprise#71750
Forward-Port-Of: odoo/enterprise#67079

### Steps to reproduce the issue:

1. Activate Mexican localization
2. Create multiple Invoices in USD with different amounts (add the Invoice Date)
3. Send and Print them for the CFDI
4. Register a grouped Payment in MXN for those invoices
5. Go to one of the Invoices and click on Update Payments
6. Go to the CFDI tab and, on the Payment line, click on Force CFDI
7. On the Payment line, you should now be able to Download an XML document
8. In the document, the EquivalenciaDR attributes should have the same values, which is not the case

### Explanation:

When calculating the rate (which then is used in EquivalenciaDR) in `_l10n_mx_edi_add_payment_cfdi_values`, we are using amounts that have been rounded out, leading to rates that differ when aiming for certain decimal precisions.

### Fix reasoning:

While `_get_conversion_rate` can be used to avoid the inconsistencies of the rounded amounts, it should not be used if the values do not match once they are converted, since the rate would then be wrong.

opw-4090269

Forward-Port-Of: odoo/enterprise#71767
Forward-Port-Of: odoo/enterprise#70083

### Steps to reproduce:
- Create a Helpdesk team with the options "Return" and "Repairs"
- Create a product, sell 1 unit and deliver it.
- Create a ticket for the Helpdesk Team, select the customer who bought the product > create and validate a return of the product to your warehouse through the ticket.
- Create an associated repair order and add a line for an other product in the part tabs
- Go back to the return picking

#### > the product added to the repair was also added to the return picking

### Cause of the issue:

A `default_picking_id` is added to the context of the form view of the repair order by the `_prepare_repairs_default_value` of the `action_repair_order_form` so that it prefils the form of the repair: https://github.com/odoo/enterprise/blob/e74b05fa7a777053fd0e2cd5a265de365e1e434a/helpdesk_repair/models/helpdesk_ticket.py#L36-L40 https://github.com/odoo/enterprise/blob/e74b05fa7a777053fd0e2cd5a265de365e1e434a/helpdesk_repair/models/helpdesk_ticket.py#L55-L56 However, this values stays in the context and will be added as a default value for each of the move that will be creted from this view.

### Fix:

Thanks to commit odoo/odoo@3898d61046cc0338082fdcbe0df282241372361a, we now have a default getter that can be used to associate a default picking id to the repair order when necessary without the need to put a `default_picking_id` in the context.

opw-4159779

Forward-Port-Of: odoo/enterprise#71704
Forward-Port-Of: odoo/enterprise#71337

**Steps to reproduce:**
- Install Accounting and l10n_cl_edi_boletas
- Switch to a Chilean company (e.g. CL Company)
- Create a branch company for it
- Create a product with a tax from "ILA" group
- Switch to the branch company
- Create an invoice with the created product
- Confirm it

**Issue:**
A traceback is raised while trying to fetch some tax groups:
- self.env.ref(f'account.{cid}_tax_group_ila')
- self.env.ref(f'account.{cid}_tax_group_retenciones') where {cid} is the id of the branch company.

**Cause:**
There is no tax group defined in the branch company. The taxes and the tax groups are defined in the parent company.

**Solution:**
Do not raise an error if the XMLID cannot be found and also check tax groups from parent companies as the taxes could come from them.
Use the "ref" method defined in "account.chart.template" model that is doing it.

opw-4227241


Related comminity PR: https://github.com/odoo/odoo/pull/182798

Forward-Port-Of: odoo/enterprise#71708
Forward-Port-Of: odoo/enterprise#71476

**Steps to reproduce:**
- Install Accounting and l10n_de_reports
- Switch to a German company
- Create a 19% included tax
- Create an invoice with the following line:
  * Product: [any]
  * Quantity: 1.00
  * Price: 19.95
  * Taxes: [the 19% included tax]
- Confirm the invoice
- Go to "Accounting / Reporting / Audit Reports / General Ledger"
- Download "DATEV DATA (ZIP)" and check "EXTF_accounting_entries.csv"

**Issue:**
The line for the created invoice has an amount of 19.94 instead of 19.95.

**Cause:**
As the tax is included, the balance on the line is computed and rounded. When the report is generated, "compute_all" is executed with the rounded balance to retrieve the total price with the taxes. Because the balance used in "compute_all" has been rounded and therefore is not exactly the same than the original computed value, there can be a 0.01 difference.

**Solution:**
Use directly "price_total" field when available.

opw-4191876

Forward-Port-Of: odoo/enterprise#71787
Forward-Port-Of: odoo/enterprise#70801

**Current behavior:**
Using 2 step delivery and modifying the route so the pick action's src location is a child of lot_stock will result in the move not being found by the Procurement mechanism, which can lead to inaccurate quantity being encoded on transfers created from rental orders.

**Expected behavior:**
Transfer quantity should match sale order line quantity.

**Steps to reproduce:**
1. Enable 2-step delivery in the warehouse

2. In the 2-step delivery route, change the src location of the pick action (pull rule) to be a sub-location of WH/STOCK

3. Enable rental transfers in settings

4. Create a new rental order, add a product, confirm the order

5. Add some quantity to the order line and save

6. Look at the generated out-going picking's moves -> the demand is wrong

**Cause of the issue:**
The original move created when confirming the order, before editing the order line quantity, is not found when the additional move is created for the modified quantity.

Existing outgoing moves are expected to have a location_id (source location) of WH/STOCK (warehouse.lot_stock_id), ours will have a location_id of some sub-location.

**Fix:**
Check all child locations of lot_stock (which includes lot_stock itself) when aggregating outgoing moves.

opw-4178446

Forward-Port-Of: odoo/enterprise#71559