This update fixes a display issue in the appointment calendar for Ukrainian and Polish users. Previously, month names were shown in the genitive case, which is incorrect. The fix ensures month names are displayed in the nominative case, aligning with standard calendar conventions and improving user experience.

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

This update fixes an issue where the system was creating duplicate vendor bills when receiving the same e-invoice XML twice from an incoming mail server. The fix prevents duplicate bills from being generated, ensuring accurate financial records and avoiding potential errors. This resolves a previous reported problem (opw-5362664, opw-5409700).

Steps to reproduce:
- With a CL Company setup
- Configure an incoming mail server with DTE server option enabled
- In Vendor Bills journal, enable 'Use Documents?'
- Receive the same XML twice via the incoming mail server
- Check created vendor bills

Issue:

There will be duplicated bills. Each duplicate will show the message 'E-invoice already exist: nnnnn'
However, the system should avoid duplicates from being created.

opw-5362664
opw-5409700

This update fixes a potential issue where minor cash differences in Point of Sale reports were incorrectly flagged due to currency rounding. The change ensures that even small discrepancies, caused by rounding, are accurately reflected, preventing the removal of legitimate cash transactions. This improves the reliability of financial reporting within Point of Sale.

Before this commit, when calculating the cash difference in the report, the code did not account for currency rounding. This could lead to situations where a very small cash difference, due to rounding errors, was not recognized as zero, resulting in the unintended removal of cash moves.

opw-5489958

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

Forward-Port-Of: odoo/odoo#245251

This update addresses a technical issue preventing Odoo from correctly importing a key exception class within the Requests library. The change, made by updating Requests to version 2.25.1, resolves a removal of this exception from the Requests package, ensuring Odoo continues to function smoothly. This fix impacts several Odoo modules.

Installing `requests==2.25.1` and using the following line of code:

    from requests.exceptions import JSONDecodeError

It raises the following error:

    ImportError: cannot import name 'JSONDecodeError' from 'requests.exceptions' (python3.10/site-packages/requests/exceptions.py)

It was removed from the following commit in the `requests` package:

    https://github.com/psf/requests/commit/db575eeedcfdb03bf31285afd3033e301df8b685

This change fixes this error importing the original exception from `json` package

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

This update resolves an issue where internal users without sales permissions would encounter errors when accessing their sales orders through the /my page. The change mirrors a previous fix and ensures a smoother experience for all users, regardless of their access level. This improves stability and prevents potential disruptions to sales workflows.

Avoid error when internal user (no sale permissions) see Orders at /my

Similar to https://github.com/odoo/odoo/commit/5ebab949a06ec338cc28e912317a74bbfb3fe6ac

@Tecnativa TT60025

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

Forward-Port-Of: odoo/odoo#245039

This update ensures that when a new partner is created during a shared sign request, the partner's name is automatically set to the signer's name, rather than using their email address. This improves data accuracy and consistency for shared agreements, simplifying record-keeping.

Version:
- saas-18.2

Steps to reproduce:
- Create a shared sign request.
- Open the shared signing link and complete the signature process.
- During signing, a new partner gets created for the signer if not already exists.

Before:
- When the user signs the shared sign request and a new partner is created, the partner name is not set and email is used as name.

After:
- Now, when a user signs a shared sign request and a new partner is created, the system automatically sets the partner name using the signer name.

task-5776339

Forward-Port-Of: odoo/enterprise#105232
Forward-Port-Of: odoo/enterprise#104869

This update resolves an issue where the system was unnecessarily creating duplicate snapshots during the transmission of ELM data for Swiss payroll. The change ensures that a snapshot is only created if one doesn't already exist, streamlining the process and preventing potential data inconsistencies. This improves the reliability of payroll reporting in Switzerland.

Forward-Port-Of: odoo/enterprise#105135

This update corrects a technical issue related to how payments are processed in the HR payroll system. The fix ensures that multiple payment moves are handled correctly during registration, improving the reliability of payment processing. This change enhances the overall stability of the system.

There was an error where we weren't batching when
we were selecting several moves at the same time
when registering a payment.
We fixed that and this test needs to be adapted.

Forward-Port-Of: odoo/enterprise#104727

This update removes a restriction that previously limited the ability to use certain journal accounts for reconciliation. This change provides greater flexibility for users to configure their accounting processes, addressing a previous limitation that could restrict account usage. It’s a minor improvement to the system’s flexibility.

Previously, a constraint prevented accounts from being non-reconcilable if they were used as default debit/credit accounts involved in journals. This behavior is too restrictive.

This commit removes the constraint.

task-5254202

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

Forward-Port-Of: odoo/odoo#244398

This update resolves a potential infinite loop issue that could occur when generating combinations of product attributes, specifically with multi-checkbox attributes. The fix ensures that lines without attribute values are excluded from the combination process, preventing redundant calculations and maintaining system stability. This change improves the reliability of product configuration.

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

This update corrects a technical inconsistency where certain fields in payroll modules (l10n_au, l10n_eg, l10n_lu) were incorrectly marked as editable. Removing this setting ensures that fields designated as 'readonly' remain protected, maintaining data integrity and compliance within these payroll calculations.

There was an inconsistency on readonly for fields between version and employee. This removes "readonly=False" on employee for fields that are readonly on the version.

Runbot error: 230983

This update corrects a problem with the tax report tour that prevented it from running correctly in certain scenarios. The fix addresses an incompatibility between the tour's assumptions about date calculations and the Odoo system's configuration, particularly when using the US tax report localization. This ensures the tour functions reliably across different Odoo setups.

- The tour shouldn't run if a localization with 'Tax Report' for the country is not installed (i.e. l10n_us_account)
- Dynamic Javascript dates calculation don't mix well with Python's freeze_time running in the "No future" 2026 preparation build, so I froze the time in the Python test but resorted to hardcode the Javascript dates.
- No need to check the position of the column "Column 1". In debug mode for the tour, there will be the "Debug" column where the info about the computations are shown, so it won't be the last. We just need to see that it shows, after all.

Runbot error [link](https://runbot.odoo.com/odoo/error/234624)
runbot-234624

This update resolves an issue preventing grouping within the planning module's slot templates. The fix ensures that parameters are passed to the underlying method in the correct order, enabling proper data aggregation. This improves the functionality of the planning system.

Before this commit, it was impossible to group by on any field in `planning.slot.template` model, because the parameters given to the parent method of `formatted_read_group` method were not given into the right order.

This commit makes sure the order is respected.

Forward-Port-Of: odoo/enterprise#105211

This update fixes a technical detail related to the translation of Odoo's Greek language support. The incorrect language code ('gr') was replaced with the correct code ('el') in several configuration files. This ensures accurate translations and proper functionality for Greek-speaking users.

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

Forward-Port-Of: odoo/odoo#245352
Forward-Port-Of: odoo/odoo#244684

This update corrects a technical issue where newly added modules to the Odoo Enterprise platform were not correctly identified for translation. This fix ensures that the Greek language (el) is properly supported and translatable within the system, preventing errors and improving localization for users in Greece. It resolves a previous oversight related to .weblate.json configuration.

Modules added into stable without being properly added to .weblate.json file = never translatable.

Forward-Port-Of: odoo/enterprise#105243
Forward-Port-Of: odoo/enterprise#104890