Issue before this commit:
=========================

The high-priority maintenance request count (todo_request_count_high_priority) 
was not calculated correctly.

Steps to Reproduce:
=========================
- Install the maintenance module.
- Create a maintenance request and set the Priority to High (3-starred) in the form view.
- Open the dashboard.
- Observe that the high-priority request count is not displayed.
- The count always remains 0, even when high-priority requests exist.

Cause of the issue:
=========================
In this [PR](https://github.com/odoo/odoo/pull/94866), the logic was mistakenly changed. 
The priority field is defined as a Selection field, but while computing the count, the comparison 
was done against an integer(3, not '3') instead of the actual string value. Since the stored 
value is '3' (string), the condition is always evaluated to False, resulting in a count of 0.

With This Commit:
=========================
Ensure that high-priority maintenance requests are correctly counted and displayed on 
the dashboard when they exist. This provides better visibility of critical requests and
helps users prioritise maintenance work effectively.

Forward-Port-Of: odoo/odoo#244987

**Description of the issue/feature this PR addresses:**
In the `triggering_answer_ids` searchable dropdown, when no value is entered, the `_search_display_name` method of `chatbot_script_answer` is not called. Instead, the ORM falls back to the field’s default domain and returns all `chatbot.script.answer` records, including those from other scripts. When a value is entered, `_search_display_name` is triggered and the results are filtered correctly.

This behavior changed after PR #201587, where the `operator_optimization` step started executing before `determine_domain`. Since `determine_domain` is the step that triggers `_search_display_name`, it no longer gets called when the domain `('name', 'ilike', '')` is stripped by `operator_optimization`. Therefore, filtering only works when a non-empty filter value is provided.

**Current behavior before PR:**
All `chatbot.script.answer` records are shown in the `triggering_answer_ids` dropdown when no search value is entered, even if they don’t belong to the current chatbot script.

**Desired behavior after PR is merged:**
The `triggering_answer_ids` dropdown only shows answers belonging to the current chatbot script, regardless of whether a search value is entered.

task-[4968490](https://www.odoo.com/odoo/project/1519/tasks/4968490)

Forward-Port-Of: odoo/odoo#228192

### Issue:
The payment method `99 – Por Definir` was used as the default value for invoices, sale orders, and POS orders
This leads to fiscal inconsistencies, especially when invoices use the `PUE` payment policy, where this payment method is invalid

### Cause:
In the `_compute_l10n_mx_edi_payment_method_id` methods, the default value was always set to `Por Definir`

### Fix:
After discussion with the PO (MIAL), the chosen solution is to archive the payment method `99 – Por Definir`and remove it as a default value
All valid cases should already be handled explicitly, making it clear to the user that something is missing when the data is blank

### Steps to reproduce:
- Install `l10n_mx_edi` and switch to the MX company
- Create an invoice with today’s invoice date
- The payment policy is set to PUE
- Before the fix, the payment method is set to `Por Definir`

For Sale Order and POS Order tests, it's the default value as soon as you create an order

opw-5406038

Forward-Port-Of: odoo/enterprise#105058
Forward-Port-Of: odoo/enterprise#104164

In the appointment calendar, the "Month Year" (e.g. January 2026) is displayed at the top of the calendar selector as is standard for calendars. Unfortunately in some languages, the word month word used depends on grammatical situation.

Steps to reproduce:
- activate Ukrainian (or Polish) language
- Preview (i.e. the website view) of any appointment
- Change the preview into Ukrainian (or Polish)

Expected result:
Calendar month at top of calendar is shown in the nominative case:
e.g. January 2026 = січень 2026 (in Ukrainian)

Actual result:
Calendar month is shown in the genitive case (e.g. "of January", as in "the 12th of January):
e.g. January 2026 = січня 2026 (in Ukrainian)

Fix is to switch from the "MMMM Y" format (i.e. month based on grammar context) to "LLLL Y" (i.e. stand alone month) which will use the correct month case. Ref: https://www.unicode.org/reports/tr35/tr35-dates.html#dfst-month

Note that for most languages this won't make a difference since there is usually only 1 way of writing a month.

opw-5474705

picture diff (for January 2026):

before fix:
<img width="1168" height="468" alt="image" src="https://github.com/user-attachments/assets/36754439-e664-40f3-9c5b-7c9c76cd7cca" />


after fix:
<img width="1215" height="492" alt="image" src="https://github.com/user-attachments/assets/82f0665e-fe70-4b9f-b1d4-f420b52db38f" />

Forward-Port-Of: odoo/enterprise#104942

**Steps to produce:**
- Install the `Accounting` module.
- Enable analytic accounting in settings.
- Create an analytic account (e.g., "test").
- Create a journal entry and assign the analytic account in the analytic
  distribution.
- Post the entry and export it(Make sure `journal items/account` and
  `journal items/analytic distribution` are also included).
- `Archive` the analytic account.
- Import the exported entry `OR` Duplicate the previous created entry.
- Try to post the imported entry.

**Issue:**
- The entry is posted even if the analytic account used in the analytic distribution is inactive.

**Root cause:**
- The `analytic_distribution` field is stored as JSON.
- At [1], the `_str_to_json` method only attempts `json.loads(value)`, and if parsing fails, it raises an error.

**Solution:**
- Add a validation when posting journal entries to ensure that all analytic accounts referenced in the analytic distribution are active.

[1]: https://github.com/odoo/odoo/blob/13e8b462e74f144e085492857bfaa7b0d1f88f93/odoo/addons/base/models/ir_fields.py#L196-L202

opw-5350980

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

Forward-Port-Of: odoo/odoo#243534
Forward-Port-Of: odoo/odoo#239988

Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end of the list.

Suppose the order was arbitrary and we are generating combinations for two lines (the order here is important):
    - Line (A) -> [] (multi checkbox type)
    - Line (B) -> [attr_1, attr_2] 
    - The possible combinations are {(attr_1), (attr_2)}.
  
  After generating the second combination the following 2 procedures happen.
    - The value_index_per_line[1] will be resetted to -1,
    - The line_index will decrement from 1 to 0. 


Now, since the first line doesn't have any values, it will be skipped and the line_index will be incremented to 1.
This results in the redundant generation of the same combination, triggering an infinite loop.

Since this method yields a recordset of `product.template.attribute.value` model and the **multi-checkbox** attribute doesn't have a value being passed to the method anyways, we can exclude the lines that doesn't have values for the algorthim not to be stuck in an infinite loop.


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

Forward-Port-Of: odoo/odoo#241557

### Issue:
The stripe payments are failing to due setting currency decimals.

#### Steps to reproduce:
1- In USD currency form in developer mode, set the rounding factor
   to `0.001000`, so we have 3 decimal places.
2- From `Decimal Accuracy` set Price Unit to 4 digits.
3- Refresh the page.
4- Create a SO and add a line. Set the price to `200.7647`.
5- Refresh the page again and generate a payment link.
6- Pay through stripe. As you see payments fail.

### Cause:
This is due to rounding the amount before sending to stripe:
https://github.com/odoo/odoo/blob/824e0c42c62de7f570f106860e7dcbf1f7344c14/addons/payment_stripe/models/payment_transaction.py#L160-L165

We are rounding the amount to the minor currency unit.

However, we make a compare between `tx_amount` and the amount paid through stripe:
https://github.com/odoo/odoo/blob/824e0c42c62de7f570f106860e7dcbf1f7344c14/addons/payment/models/payment_transaction.py#L726-L732

Which are not equal. We should use minor current unit as `precision_digits` to fix this issue.

opw-5496825

**Steps to reproduce:**
1. Install the `Accounting` module.
2. Enable cash basis taxes in
   `Accounting → Configuration → Settings → Taxes → Cash Basis`.
3. Create a tax, set `Tax Exigibility` to `Based on Payment`, and assign a
   `Cash Basis Transition Account`.
4. Create an invoice with the cash basis tax and a payment term such as
   `30% now, balance in 60 days`.
5. Record a full payment on the invoice instead of just the first installment.
6. Review the generated cash basis journal entries.

**Observed behavior:**
* Cash basis entries are created for the full tax amount, not proportionally.
* Paying the full invoice with payment terms causes duplicated tax entries.

This came from the fact that we didn't consider a move would be fully paid by
several lines at the same time, like with installments.

We now only put the leftover amount when the move is fully paid and we're on
the last partial.


Also fix the fact that paying 2 invoices at the same time in full does not benefit from the batches

opw-5061136




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

Forward-Port-Of: odoo/odoo#236536

The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request [83499](https://github.com/odoo/enterprise/pull/83499) added rounding precision for these PACs.

Now, the remaining PAC (Solution Factible) appears to the same requirement. This commit ensures that the previous bug fix is applied to all PACs.

[opw-5165200](https://www.odoo.com/odoo/project.task/5165200)

## Steps to reproduce:

[Setup](https://drive.google.com/file/d/1BUkNG-Ezk-I47yvbNolOmlj0ne1iqDto/view?usp=sharing)
1. Navigate to Apps and install l10n_mx_edi.
2. Switch to any of the Mexican companies that appear.
3. Navigate to Accounting > Configuration > Currencies.
4. Click into the USD currency.
5. Change the current rate to be 20.101796407186 MXN per USD. (inverse_company_rate field).
6. Navigate to Accounting > Configuration > Settings, and set the PAC to Solution Factible.

[Workflow](https://drive.google.com/file/d/11TFZ78QGDYdnD9R3CoJDAuFI-1_0dNyG/view?usp=sharing)
1. Navigate to Accounting > Customers > Invoices.
2. Select New to create a new invoice.
3. Add a mexican customer (such as XENON INDUSTRIAL ARTICLES).
4. Add the 45 day Payment terms. This should change the payment policy to PPD.
5. Change the currency to USD.
6. Add the product FURN_8220 (or any with the unspsc_code_id set).
7. Set the unit price of the product to 58968.29.
8. Confirm the invoice.
9. Select Send & Print, then ensure that the CFDI option is selected before clicking Send & Print again.
10. Select Register Payment, then Confirm Payment.
11. Select the Update Payments smart button.
12. Navigate to the CFDI tab; there will be a "Payment Send in Error" line.

Forward-Port-Of: odoo/enterprise#105102
Forward-Port-Of: odoo/enterprise#102557