[IMP] l10n_{bf,bj,cd,ci,cm,ga,km,ml,ne,sn,tg}: make report definition more consistent
    
    - Doing if_above using EUR as the currency made no sense in those countries. We instead use the domestic currency (the result is equivalent, since 0 EUR = 0 in any other currency ; it's just clearer)
    
    - specifying rounding=2 on editable monetary value had no effect (on monetary values, the rounding is always made with the decimal places of the domestic currency), and was hence misleading.

----------------------------------------------------------

[IMP] account_reports: Enforce constraint on carryover target
    
    We need to add constraints on the expression label and the carryover_target from account report so that we ensure that it is used correctly.

    Currently, it may have happened that when we used the carryover mechanism, we were using the wrong label.
    That could create some issues where the carryover would simply not work or partially.

----------------------------------------------------------

[FIX] l10n_bf: tax report: fix line name and formulas
    
    - The report contained two lines numbered 26, while one of them had 27 in its code
    - Line "Net VAT amount to pay"'s formula contained BF_OTHER_DEDUCTION twice
    - Line "Credit VAT to report"'s formula contained BF_OTHER_DEDUCTION twice, and BF_CANCELLED (grid 25) was missing
    
    We fix all those problems, and rewrite the formula of "Net VAT amount to pay" in order for it to better match the expression provided in the line name (for clarity).

-----------------------------------------------------------

[FIX] l10n_{bf, bj, cd, ci, cm, ga, km, ml, ne, sn, tg}: Fix Carryover for syscohada countries
    
    For some syscohada countries some tax report where using carryover.
    The carryover on the tax reports from these countries were not working.
    The cause was one, the label of the expression used to target the applied carryover was not prefixed with _carryover_.
    And two, is that it had no expression dedicated for carryover with label _applied_carryover and this was causing the report to miss the info tag on the line for the carryover.
    
    task-4110461

Forward-Port-Of: odoo/odoo#176489

Steps to reproduce:

- Go to website (in "Edit" mode) > Drop a "Title" block > Add a
highlight effect to the title text.

- Select a word in the title text > Transform it to a link, and save.

- Try to translate the title into another language in the editor > You
cannot update the text or remove it.

The highlight effects have an auto-updated DOM structure handled by JS.
Having an element that is not inline translated (the `<a/>` tag in this
case) inside a highlight structure will wrap the link content in
`<span data-oe-translation-initial-sha="...">` elements that are
considered "UNREMOVABLE" and, as a consequence, cannot be adapted as
normal content inside the highlight DOM.

Also, we cannot translate `<a>` elements inline to fix this issue, since
there is a reason why this was prevented (see more details in the commit
message from [1]).

The goal of this commit is to fix this behaviour by forcing the
highlight content to always be translated as a whole. This should wrap
all the text highlight DOM in one global `<span>` so it can be
translated correctly.

[1]: https://github.com/odoo/odoo/commit/9bd60ca93510e410a0136b8b433f596330900593

opw-3980975

Forward-Port-Of: odoo/odoo#170895

Current behavior:
When a cashier enter a payment value with more precision than the rounding precision (eg. rounding=0.10 and payment value=1.25), he just cannot proceed to the payment.

Steps to reproduce:
- Install "Point of Sale" app
- Go to the settings and enable the cash rounding
- Go the shop settings and enable the cash rounding and create a down rounding method with a precision of 0.10
- Start a shop session, select a product and go to the payment screen
- Select a payment method and write a number on the numpad so that the value goes up to the cent (eg. 1.25)
- Select another payment method to pay the rest

Solution:
With this commit, an error popup will be displayed explaining why the cashier cannot proceed the payment and what he could change to authorize the payment. This popup should appear when selecting another payment method and when validating the payment.

opw-3992018


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

Forward-Port-Of: odoo/odoo#175667
Forward-Port-Of: odoo/odoo#174145

**Description of the issue/feature this PR addresses:**

  steps to reproduce error:-
        1.create db with 'point_of_sale' module
        2.duplicate the record of pos_payement_method with journal type cash
        3. install 'pos_restaurant' module this traceback will raise the **OR** start pos session validation error will come
       

```
Traceback (most recent call last):
  File "/home/odoo/odoo/odoo/17.0/odoo/http.py", line 1764, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
  File "/home/odoo/odoo/odoo/17.0/odoo/service/model.py", line 133, in retrying
    result = func()
  File "/home/odoo/odoo/odoo/17.0/odoo/http.py", line 1791, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "/home/odoo/odoo/odoo/17.0/odoo/http.py", line 1995, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "/home/odoo/odoo/odoo/17.0/odoo/addons/base/models/ir_http.py", line 222, in _dispatch
    result = endpoint(**request.params)
  File "/home/odoo/odoo/odoo/17.0/odoo/http.py", line 741, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/odoo/odoo/17.0/addons/web/controllers/dataset.py", line 28, in call_button
    action = self._call_kw(model, method, args, kwargs)
  File "/home/odoo/odoo/odoo/17.0/addons/web/controllers/dataset.py", line 20, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "/home/odoo/odoo/odoo/17.0/odoo/api.py", line 468, in call_kw
    result = _call_kw_multi(method, model, args, kwargs)
  File "/home/odoo/odoo/odoo/17.0/odoo/api.py", line 453, in _call_kw_multi
    result = method(recs, *args, **kwargs)
  File "<decorator-gen-77>", line 2, in button_immediate_install
  File "/home/odoo/odoo/odoo/17.0/odoo/addons/base/models/ir_module.py", line 75, in check_and_log
    return method(self, *args, **kwargs)
  File "/home/odoo/odoo/odoo/17.0/odoo/addons/base/models/ir_module.py", line 466, in button_immediate_install
    return self._button_immediate_function(self.env.registry[self._name].button_install)
  File "/home/odoo/odoo/odoo/17.0/odoo/addons/base/models/ir_module.py", line 590, in _button_immediate_function
    registry = modules.registry.Registry.new(self._cr.dbname, update_module=True)
  File "<decorator-gen-16>", line 2, in new
  File "/home/odoo/odoo/odoo/17.0/odoo/tools/func.py", line 87, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/odoo/odoo/17.0/odoo/modules/registry.py", line 113, in new
    odoo.modules.load_modules(registry, force_demo, status, update_module)
  File "/home/odoo/odoo/odoo/17.0/odoo/modules/loading.py", line 480, in load_modules
    processed_modules += load_marked_modules(env, graph,
  File "/home/odoo/odoo/odoo/17.0/odoo/modules/loading.py", line 364, in load_marked_modules
    loaded, processed = load_module_graph(
  File "/home/odoo/odoo/odoo/17.0/odoo/modules/loading.py", line 227, in load_module_graph
    load_data(env, idref, mode, kind='data', package=package)
  File "/home/odoo/odoo/odoo/17.0/odoo/modules/loading.py", line 71, in load_data
    tools.convert_file(env, package.name, filename, idref, mode, noupdate, kind)
  File "/home/odoo/odoo/odoo/17.0/odoo/tools/convert.py", line 627, in convert_file
    convert_xml_import(env, module, fp, idref, mode, noupdate)
  File "/home/odoo/odoo/odoo/17.0/odoo/tools/convert.py", line 693, in convert_xml_import
    obj.parse(doc.getroot())
  File "/home/odoo/odoo/odoo/17.0/odoo/tools/convert.py", line 613, in parse
    self._tag_root(de)
  File "/home/odoo/odoo/odoo/17.0/odoo/tools/convert.py", line 556, in _tag_root
    f(rec)
  File "/home/odoo/odoo/odoo/17.0/odoo/tools/convert.py", line 567, in _tag_root
    raise ParseError(msg) from None  # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
odoo.tools.convert.ParseError: while parsing /home/odoo/odoo/odoo/17.0/addons/pos_restaurant/data/pos_restaurant_data.xml:4
You cannot use the same journal on multiples cash payment methods.

View error context:
'-no context-'
```

- Here is the reason why  above mentioned traceback is raised:
-> [here](https://github.com/odoo/odoo/blob/b64a507697381fd7bb205f4a2b2217322d31811a/addons/pos_restaurant/data/pos_restaurant_data.xml#L4) new record of pos.config is creating which trigger the check of pos.config model due to that traceback is raised due to this [validation](https://github.com/odoo/odoo/blob/c72b25969715ab8331acd45d7fea8bfc2d9ab541/addons/point_of_sale/models/pos_config.py#L354)
 
- **Current behavior before PR:**
if we create ``new`` record of pos.payment.method journal_id  field domain not let create another record of journal with type cash if its already present
but if we  ``duplicate`` record we can do which is not corrrect as per this [validation](https://github.com/odoo/odoo/blob/c72b25969715ab8331acd45d7fea8bfc2d9ab541/addons/point_of_sale/models/pos_config.py#L354)

- **Desired behavior after PR is merged:**

  for resolving this not let duplicate journal_id with type cash. After, this patch user will not able select journal_id with type cash   due to [domain](https://github.com/odoo/odoo/blob/b64a507697381fd7bb205f4a2b2217322d31811a/addons/point_of_sale/models/pos_payment_method.py#L29) on journal_id  and  records never will create. From ui .



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

Forward-Port-Of: odoo/odoo#175530

### **Description:**
* **Steps to Reproduce:-**
        1. Install the Inventory module and create a new warehouse, other than the standard one.
        2. Archive the standard warehouse.
        3. Attempt to install the Point_of_Sale module.

* After this commit: https://github.com/odoo/odoo/commit/0ddd04a34d85386d4ffc59aab07f68b365619b0a, archived warehouses are now also considered when defaulting the `pos_type_id`. Initially, if a warehouse was archived, no `pos_type_id` would be created for it. Later on, if any new `pos_config` record is created for `self.env.company` where the warehouse is archived, it will throw the following error:

```py
File "/home/odoo/src/odoo/17.0/odoo/sql_db.py", line 332, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.NotNullViolation: null value in column "picking_type_id" of relation "pos_config" violates not-null constraint
DETAIL:  Failing row contains (1, null, null, 1, null, 221, 222, null, 1, 170, 169, 289, null, null, 7, null, 1, 1, Shop, total, null, 17c45bf9-4ffa-45ce-b637-53249b394421, direct, null, null, null, null, null, null, null, null, null, null, f, t, null, f, null, t, null, null, null, f, null, null, null, null, null, null, null, null, null, null, t, null, t, 2024-08-06 04:46:54.504337, 2024-08-06 04:46:54.504337, null).
```

While parsing this...

```py
 File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 569, in _tag_root
    raise ParseError('while parsing %s:%s, somewhere inside\n%s' % (
odoo.tools.convert.ParseError: while parsing /home/odoo/src/odoo/17.0/addons/point_of_sale/data/point_of_sale_data.xml:35, somewhere inside
<record model="pos.config" id="pos_config_main" forcecreate="0">
            <field name="name">Shop</field>
        </record>
```

OPW - 4094096

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#175838

Steps to reproduce the bug:
- Create a storable product “P1” with BoM: - Component: C1

- Create a quality point: - Product: P1 - Operation: Manufacturing - Control per: Quantity - Control Frequency: All

- Create a manufacturing order: - Product: P1 - Quantity: 20

- Confirm the MO
- Set the qty producing 12
- click on the quality check: - Button Fail - Quantity: 5

- Valide the Mo and create a backorder
- click on the quality check: - Button Fail - Quantity: 1

Problem:
A traceback is triggered:
```
  File "/home/odoo/odoo V16/enterprise/quality_control/models/quality.py", line 370, in _move_line_to_failure_location
    if not check._can_move_line_to_failure_location():
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo V16/enterprise/quality_mrp/models/quality.py", line 49, in _can_move_line_to_failure_location
    self.move_line_id = self.production_id.finished_move_line_ids.filtered(
    ^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 1321, in __set__
    write_value = self.convert_to_write(value, records)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 3118, in convert_to_write
    return value.id
           ^^^^^^^^
  File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 5154, in __get__
    raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: stock.move.line(96, 98)
```

When we validate the MO to create the backorder, the `_split_productions`
function is called. This results in two move lines:
https://github.com/odoo/odoo/blob/4be8cac644c9471f98bf16e82825af0e9439e697/addons/mrp/models/mrp_production.py#L1837
The first one has a quantity of 15, which is the remaining quantity
to be processed, and the second line has a quantity of 5, which is the
quantity that has definitely failed. However, these two move lines are
supposed to be ordered first by the failed ones and then by the others.
Because, in the current situation, we take the move line with the
quantity of 15, reduce it by the 12 units processed in this MO,
leaving 3. As a result, we will have two remaining move lines:
3 + 5 (already failed), and both will be used in the backorder.
But if they were ordered by the failed ones first, we would subtract
12 from 5, resulting in -7, and then reduce the line with 15 - 7 = 8
in the move line that will be used in the backorder."
https://github.com/odoo/odoo/blob/4be8cac644c9471f98bf16e82825af0e9439e697/addons/mrp/models/mrp_production.py#L1848-L1858
opw-4064656

Forward-Port-Of: odoo/odoo#175355

Issue: When we have multiple companies and we create different folders for each other, if we are working in a folder from let's say company A and then we switch to Company B, we will run the same link to this folder but from the Company B rights point of view, and since this folder is not accesible from this company it will throw a traceback and break the page until refresh to another url.

Steps to reproduce:

1. Install Documents.
2. Have atleast 2 companies.
3. Create a new folder that belongs to the current company.
4. While having this folder selected, change to the 2nd company.

Solution:

The issue is triggered within the load funcion for the DocumentsSearchModel, since we get the folderId that's in the url, and we also get the list of the folder we have access to, we could filter out if the current folder we are trying to access is within this list before calling toggleCategoryValue, and If it's not we could just call it on `folderId = false;` as default (which is the "All" section of folders). This way we avoid calling `category.values.get(...)` later on for undefined (we don't have access to this folder).

opw-3971935

Forward-Port-Of: odoo/enterprise#64513

Steps to reproduce the bug:
- Create a storable product “P1” with BoM:
    - Component: C1

- Create a quality point:
    - Product: P1
    - Operation: Manufacturing
    - Control per: Quantity
    - Control Frequency: All

- Create a manufacturing order:
    - Product: P1
    - Quantity: 20

- Confirm the MO
- Set the qty producing 12
- click on the quality check:
    - Button Fail
    - Quantity: 5

- Valide the Mo and create a backorder
- click on the quality check:
    - Button Fail
    - Quantity: 1

Problem:
A traceback is triggered:
```
  File "/home/odoo/odoo V16/enterprise/quality_control/models/quality.py", line 370, in _move_line_to_failure_location
    if not check._can_move_line_to_failure_location():
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo V16/enterprise/quality_mrp/models/quality.py", line 49, in _can_move_line_to_failure_location
    self.move_line_id = self.production_id.finished_move_line_ids.filtered(
    ^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 1321, in __set__
    write_value = self.convert_to_write(value, records)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 3118, in convert_to_write
    return value.id
           ^^^^^^^^
  File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 5154, in __get__
    raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: stock.move.line(96, 98)
```

When we validate the MO to create the backorder, the `_split_productions`
function is called. This results in two move lines:
https://github.com/odoo/odoo/blob/4be8cac644c9471f98bf16e82825af0e9439e697/addons/mrp/models/mrp_production.py#L1837
The first one has a quantity of 15, which is the remaining quantity
to be processed, and the second line has a quantity of 5, which is the
quantity that has definitely failed. However, these two move lines are
supposed to be ordered first by the failed ones and then by the others.
Because, in the current situation, we take the move line with the
quantity of 15, reduce it by the 12 units processed in this MO,
leaving 3. As a result, we will have two remaining move lines:
3 + 5 (already failed), and both will be used in the backorder.
But if they were ordered by the failed ones first, we would subtract
12 from 5, resulting in -7, and then reduce the line with 15 - 7 = 8
in the move line that will be used in the backorder."
https://github.com/odoo/odoo/blob/4be8cac644c9471f98bf16e82825af0e9439e697/addons/mrp/models/mrp_production.py#L1848-L1858

opw-4064656

Forward-Port-Of: odoo/enterprise#67474

**Description**

A [recent](https://github.com/odoo/enterprise/commit/76d9188767e26c4ae1f815334af5ca3ac6c5fcdf) change in the l10n_fr_reports **IMB - Intermediate management balances** created a new child and parent hierarchy between report lines that never existed before. This causes a traceback when opening the report on migrated databases. 
The report lines must be loaded in an order where parent lines come before their children. The sorting of `account.report.line` model is by `sequence, id`, where `sequence` column (if unchanged) remains null, causing lines to be sorted by `id`. The change caused larger id records to be assigned as the parent of smaller id records, violating the required hierarchy and raising a traceback.


**Traceback :** 

  ```py
  File "/home/odoo/src/enterprise/17.0/account_reports/models/account_report.py", line 4386, in get_report_information
    'lines': self._get_lines(options, all_column_groups_expression_totals=all_column_groups_expression_totals, warnings=warnings),
  File "/home/odoo/src/enterprise/17.0/account_reports/models/account_report.py", line 2123, in _get_lines
    parent_generic_id = line_cache[line.parent_id]['id'] if line.parent_id else None # The parent line has necessarily been treated in a previous iteration
KeyError: account.report.line(338,)
```


**steps to reproduce**
1. install 'l10n_fr' and 'account_accountant' in a demo database of version 16
2. migrate it to version 17.
3. go to Reporting->Profit and Loss (Fr company should be selected)
4. Change Report to "IMB - Intermediate management balances"

Note:  This PR is created by this [suggestion](https://github.com/odoo/upgrade/pull/6267#issuecomment-2244373973).

Forward-Port-Of: odoo/enterprise#67147