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

### 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 reproduce:
-------------------
1. Enable cash rounding, only for cash payment method
   - Rounding method doesn't matter, I tested with 0.05 nearest rounding
2. In PoS, make an order with the customer account, such that the total amount is not divisible by 0.05, i.e. when rounded, it's not the same amount. For instance, $5.27.
3. Close the session and reopen it, then select that customer, and click settle due
4. Select the Bank payment method, so a NON-Cash payment method.

Notice that the amount is being rounded, even though we have only enable rounding for cash methods. If we take my example of step 2, the amount became $5.25 instead of $5.27.

That is understandable when we settle with Cash, however, for Bank (non-cash), we should not round.

The fix
-------
Now when choosing a payment method to settle due, we also round the amount if needed, in `getTotalDueOfPartner`. Before, we always set the exact amount, regardless of the payment method and the rounding settings.

We now also apply rounding on the payment screen based on the selected payment method. Previously, the change was always rounded whenever rounding was enabled, ignoring whether rounding was restricted to cash methods. This behavior made sense for normal orders—where change is typically given in cash—but not when settling a due amount, since the customer can pay using any method. During due settlement, the change represents the amount the customer must pay, so rounding must follow the rules of the chosen payment method.

opw-5222985

Forward-Port-Of: odoo/enterprise#104632
Forward-Port-Of: odoo/enterprise#100278

**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.

**Root cause:**
The calculation of `amount_currency` in `_create_tax_cash_basis_moves` used `line.amount_residual_currency` directly. This ignored the actual payment percentage, leading to incorrect full tax amounts.

**Solution:**
Adjust the calculation to apply the payment percentage when deriving the tax amount. This ensures that cash basis entries correctly reflect the proportion of the payment instead of always using the full tax.

opw-5061136

**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

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#104673
Forward-Port-Of: odoo/enterprise#102557

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

**Steps to reproduce:**
- Go to Appointment app
- Edit an appointment type
- Ensure its availability is on resources
- Set duration to 1 hour
- Add a schedule slot ending in 00:00
- Save and go to the website page of the appointment
- Last slot is not showing (23:00-00:00)

**Issue:**
When computing the appointment slots of a resource using time range,
the end of day is considered as an unavaibility resource slot with this interval
in `_get_unavailable_intervals`:
`i_start = 23:59:59.999999` `i_stop = 00:00`
this conflicts with the given range (23:00-00:00)
in `self._slot_availability_is_resource_available`

It comes from `_attendance_intervals_batch`, as `float_to_time(24.0)`
is converted to `time.max` (23:59:59.999999) by:
`day_to = datetime.combine(day, float_to_time(attendance.hour_to))`
This introduces the microsecond unavaibility at the end of the day, which
blocks the booking.

(it's working properly for availability on users appointments)

**Fix:**
Changed the condition so that 23:59:59.999999 is considered as equal to 00:00.

opw-5163892

Forward-Port-Of: odoo/enterprise#100853