Before this patch, if a billing user (without any administration settings level) tried to cancel a posted invoice and clicked on the "Process now" button, they got an exception.

In particular, it happened because those users shouldn't have access to stuff such as the certificate, its password or the contents of the sent EDI attachment.

However, they should be able to post the documents using whatever configuration the sysadmin saved. Thus, I use some `sudo()` calls and add a test to assert it won't break anymore.

**How to test functionally:**
1. Configure a Spanish company.
2. Install `l10n_es_edi_tbai` and configure it.
3. Switch to a user that only has "Invoicing / Billing" permissions.
4. Post an invoice.
5. Send it to tbai.
6. Request EDI cancellation.
7. Send it to tbai.
8. It should work now.

@moduon MT-8894 OPW-4535149


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

Forward-Port-Of: odoo/odoo#196086
Forward-Port-Of: odoo/odoo#195981

Steps to reproduce the bug:
- Create a cash or bank account journal
- Archive it (you will have an error, because it is associated with a payment method)
- Delete it (it will be deleted normally)

Problem:
The problem is because of added constraint on the archival of account journal, that wasn't added to the deletion as well. The constraint on the archival was too strict after discussion with accounting team, it should be reverted and a new constraint will be added from the pos side.
Now, the journal can't be archived nor deleted if it has at least one payment with payment method for that journal in an active session, because the journal items are written when the session is closed only. So, if the journal is archived with some active payments before closing the session, the journal entries are lost because it fails to write them in archived journal.
The constraint is added to both archival and deletion to prevent the possibility of deletion while we can't archive.

Testing:
A performance testing was held on the new constraint, and based on the profiling the execution time was 0.00 seconds, and the pos.payments test passed successfully.

Commits that added the constraint:
d430231
5722d52

Tickets that required that constraint:
opw-4070620

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

opw-4554961
opw-4438601

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#199454
Forward-Port-Of: odoo/odoo#199009

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

When computing l10n_in's `res_partner.l10n_in_gst_state_warning` field, we [search](https://github.com/odoo/odoo/blob/f1fb0527f1b29e4b464e13718d6d0edb3b32a114/addons/l10n_in/models/res_partner.py#L45) for a res_country_state whose `l10n_in_tin` is the same as the one encoded in the partner's `vat`; if none is found we warn the user.

Since the res_country_state's [`l10n_in_tin`](https://github.com/odoo/odoo/blob/f1fb0527f1b29e4b464e13718d6d0edb3b32a114/addons/l10n_in/models/res_country_state.py#L10) is not unique though, it is legal for the customer to have multiple res.country.state entries with the same l10n_in_tin (typically one standard plus one custom state):
```sql
> SELECT ARRAY_AGG(id),ARRAY_AGG(country_id),ARRAY_AGG(name),ARRAY_AGG(code),l10n_in_tin FROM res_country_state WHERE l10n_in_tin IS NOT NULL GROUP BY l10n_in_tin HAVING COUNT(*)>1
+-------------+------------+------------------------+--------------+-------------+
| array_agg   | array_agg  | array_agg              | array_agg    | l10n_in_tin |
|-------------+------------+------------------------+--------------+-------------|
| [1741, 589] | [104, 104] | ['HARYANA', 'Haryana'] | ['06', 'HR'] | 06          |
+-------------+------------+------------------------+--------------+-------------+
```

If our search passes more than one results to `state_id.name` though, Odoo fails with a ValueError:
```
 Traceback (most recent call last):
   File "/tmp/tmpdugmps2c/migrations/base/tests/test_mock_crawl.py", line 256, in crawl_menu
    self.mock_action(action_vals)
   File "/tmp/tmpdugmps2c/migrations/base/tests/test_mock_crawl.py", line 269, in mock_action
    return self.mock_act_window(action)
   File "/tmp/tmpdugmps2c/migrations/base/tests/test_mock_crawl.py", line 429, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
   File "/tmp/tmpdugmps2c/migrations/base/tests/test_mock_crawl.py", line 457, in mock_view_form
    [data] = record.read(fields_list)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3801, in read
    return self._read_format(fnames=fields, load=load)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4032, in _read_format
    vals[name] = convert(record[name], record, use_display_name)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6999, in __getitem__
    return self._fields[key].__get__(self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1291, in __get__
    self.compute_value(recs)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1473, in compute_value
    records._compute_field_value(self)
   File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 429, in _compute_field_value
    return super()._compute_field_value(field)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5238, in _compute_field_value
    fields.determine(field.compute, self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 113, in determine
    return needle(records, *args)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 710, in _compute_related
    record[self.name] = self._process_related(value[self.related_field.name], record.env)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6999, in __getitem__
    return self._fields[key].__get__(self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1291, in __get__
    self.compute_value(recs)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1473, in compute_value
    records._compute_field_value(self)
   File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 429, in _compute_field_value
    return super()._compute_field_value(field)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5238, in _compute_field_value
    fields.determine(field.compute, self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
    return needle(*args)
   File "/home/odoo/src/odoo/18.0/addons/l10n_in/models/res_partner.py", line 48, in _compute_l10n_in_gst_state_warning
    "As per GSTN the state should be %s, so it's recommended to", state_id.name
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1232, in __get__
    record.ensure_one()
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6212, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
 ValueError: Expected singleton: res.country.state(1741, 589)
```


**Desired behavior after PR is merged:**
We can avoid this by explicitly limiting the search to a single result.

TBG: https://upgrade.odoo.com/web#cids=1&menu_id=107&action=178&model=upgrade.request.traceback.group&view_type=form&id=1804


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

Forward-Port-Of: odoo/odoo#198388

**Description of the issue/feature this PR addresses**:
If "Product Price" Decimal Accuracy has more than 2 digits, then the unit price on the printed report has only 2 digits when Argentinean invoice report is printed and this causes that quantity * price on each invoice line does not result the amount shown on the "Amount" column.

**Steps to reproduce**:
1) Log ing with admin user on runbot odoo enterprise 16 instance, activate developer mode and install l10n_ar module.

2) Take position on company "Responsable Inscripto", go to menu "Setting / Technical / Database Structure / Decimal Accuracy" and set 4 digits for "Product Price".
![image](https://github.com/odoo/odoo/assets/89547436/ecb124fc-826c-4225-a1ff-c777b0d26037)

3) Create customer invoice to partner "Consumidor Final Anónimo" (if the partner is "Consumidor Final Anónimo" then taxes are not discriminated on the printed invoice report --> document type = "FACTURAS B"). The invoice must have an invoice line with product price with 4 digits, for example: quantity 3000, price 65.3057 and tax "IVA 21%".
![image](https://github.com/odoo/odoo/assets/89547436/ce6de3ad-e827-4056-96bf-df66964878c7)

4) Confirm and print the invoice
![image](https://github.com/odoo/odoo/assets/89547436/1297e96a-851a-402a-90d3-503a74479592)
The result of quantity * price is not the amount shown on the printed invoice (3000 * 79.03 != 237059.69)

**Current behavior before PR**:
If "Product Price" Decimal Accuracy has more than 2 digits, then the unit price on the printed report has only 2 digits when Argentinean invoice report is printed and this causes that quantity * price on each invoice line does not result the amount shown on the amount column.

**Desired behavior after PR is merged**:
If "Product Price" Decimal Accuracy has more than 2 digits, then the unit price on the printed report has the same quantity of digits set on "Product Price" Decimal Accuracy when Argentinean invoice report is printed.

Ticket Adhoc side: 77471
Task latam: 1226


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

Forward-Port-Of: odoo/odoo#196256
Forward-Port-Of: odoo/odoo#171131

### Issue: 

MO with a tracked finished product are actually splited at validation. However, the qties of the MO are usually set by default to fulfill the maximal demand. As such, component registrations performed form the shopfloor might be completely override by the MO split.

### Steps to reproduce:

- Create 2 storable products tracked by SN: FP and COMP
- Create a BOM for you final product FP:
    - 1 x COMP
    - 1 operation with an instruction of type "Register Consumed Materials" for COMP
- Put 2 serial numbers in WH/Stock for COMP: SN01, SN02
- Create and confirm an MO for 2 units of FP using that BOM
> SN01 and SN02 should be reserved on the move raw
- Go to the shopfloor to the MO
- Click on Register component SN02 > Validate
- Click on the [+] button of the register Production
- Mark the MO as Done > Close Production
> You trigger a consumption warning dialog telling you that you registered more consumed quantity than expected (2 instead of 1) This dialog should not appear in the first place as you registered only 1 unit but suppose it is ok and continue
- Click on "Set quantities and validate"
- Go back to your MO in the back end
#### > It was closed using SN01 rather than the SN you registered.

### Cause of the issue:

Confirming the MO confirmed the move raw and a reservation was made for 2 units as the MO is not splitted yet. However, since the final product is tracked this MO will end up splitted. When you register consumption, the serial number of one of the move line related to the raw move will be updated and the line will be picked:
https://github.com/odoo/enterprise/blob/d4ff42fbcfa3dd297c6cb838b5b03955f12f02a4/mrp_workorder/models/quality.py#L519-L525 However, since at least one of the move line of hte move raw is picked the move its self will become picked:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/stock/models/stock_move.py#L208-L212 This is problematic as picked picked move by pass the set_qty_producing so from now if you were to adapt the qty producing of the MO you would not affect the quantity of the raw move (which is currently at 2: one unpicked move line with SN01 and one picked with SN02): https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1218-L1228 Finally, when you click on the Close production, a `_split_productions` process will be started and adpat the demand of the move raw to 1: https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1831-L1832 Since the quantity set on the move exceeds this new demand the consumption warning. Note that at this point the backorders of the initial MO were already created and confirm without you dialog to be resolved so that the reservations of these splitted MO could not reserve the SN01 that is still used by your move. Finally, when you "Set quantities and validate" it will adpat the quantity and unreserve the picked move line as this decrease process does not prioritise to unlink unpicked move lines first:

### Fix:

Since registration process through shopfloor and barcode are expected to create picked move lines which will adpat the picked state of the move and since picking the move will automatically pick all the move line, a move line that is not picked in a picked move is a move line that is not expected to be kept. We therefore unlik these move_lines before adapting the demand of the move_raws in the split production.

### Note:

We also tried 2 other fixes of the issue but aborted these other ideas: 
1) try to keep only picked move line at the Validation of the registration component process but this change of behavior was aborted since if instead of clicking on validate you click on "Continue consumption and then on the top right cross button", you would technically have registered only the first SN but you would fall in the situation as above and trigger the same issue.
2) Adapt the condition of that makes a move raw by pass the _set_qty_producing:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1219-L1221 Since the move is picked for the wrong reason we would instead use: `all(ml.pikced for ml in move.move_line_ids)`
However, this would also require to change the process decrease to unreserve picked move last here:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/stock/models/stock_move.py#L361-L365 Changing the loop to
`reversed(move.move_line_ids.sorted(lambda ml: (not ml.picked, ml.id))` And this would not solve the issue starting post 17.0 since we would still bypass the set_qty producing on the next lines:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1223-L1225

Community: https://github.com/odoo/odoo/pull/198175

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

Forward-Port-Of: odoo/enterprise#79591

There is no reason to not reset the payment exception state if an invoice is in draft and the subscription has not to be paid before the invoice.

Also reset the next payment date on reset of the order/subscription and also make it eligible to be invoiced via cron.

**Reproduction/Rationale**:

- Have a scenario where the invoice of a subscription is proposed to be posted manually instead of automatically posting it
- The order might be to be signed but not marked to be paid for acceptance
- Therefore the signature will confirm the order and the subscription will be invoiced via cron later
- The draft is, as stated, not a failure but the wanted behavior in this scenario and no payment exception is possible because there is no payment related and created on confirmation.

As the approach is to automatically put the order into a payment exception it is very important to catch ALL the scenarios where it needs to be removed. (this approach should be reconsidered in master IMO as it is a trap and rabbit hole)

Info: @wt-io-it

Forward-Port-Of: odoo/enterprise#79391