When we import bills from KSeF, the vendor (`Podmiot1`) XML tag must include a Polish `NIP` number XML tag.
The `NIP` is the base number composing a polish `vat` number, but without the prefix `PL`.
This is true even if the vendor is from another country like Luxembourg: if they have a stable organization in Poland and sells in Poland - then they have to use a polish `NIP` to use the KSeF and issue their invoices.

Two issues:
- We search the vendor by `NIP` as it was a `vat` number, but we add the `vendor_country` code as prefix instead of `PL`. I.e. we search for `LU012345678` instead of `PL012345678`.
- When we don't find the vendor in the database, we create one using the `NIP` number coming straight from the tag, as it was a `vat` number. I.e. for a partner in Luxembourg, `vat` will become `LU012345678` instead of `PL012345678`

ref: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf

Ticket [link](https://www.odoo.com/odoo/project.task/6148039)
opw-6148039

Forward-Port-Of: odoo/odoo#261964

Step to reproduce:
- install "purchase_stock" and "point_of_sale"
- Create a product attribute -> Display Type: Radio Button
-> Variant Creation Mode: Never create variants
-> Add two attribute values, ensuring that one includes a 'is_custom' field.
- Create a product and assign this attribute to it.
- Enable the MTO (Make To Order) route.
- Add a vendor to the product.
- Create and confirm a POS order for this product. (add text for custom attr)
- Observe that a Purchase Order is generated automatically.

Observation:
- the PO does not have that text in description

Cause:
- After commit [1], `description_picking` became a computed field.
- Previously, its value (`product_description_variants`) was set in `_prepare_procurement_values`.
- That key is no longer used for this purpose, so the information is not propagated and the data is lost.

https://github.com/odoo/odoo/blob/71b1267e54fd53fb283c41b579756c72e393cbfa/addons/stock/models/stock_rule.py#L341-L343

above code is removed following that commit

Fix:
- The description is computed for pos orders

[1] https://github.com/odoo/odoo/commit/6b2d3af64a076654e04494972acc4c42d7c54bd8

opw-5969378


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

**problem:**
On timesheets, the overtime indication next to an employee's name is incorrect when using flexible work schedules. for example: a "Flexible 20h" schedule (4h a day) shows 1h of negative overtime even when the employee has logged exactly 20h for the week.

**steps to reproduce:**
1. Create a new working schedule with flexible hours enabled for example (20h/week, 4h/day average)
2. Assign this schedule to an employee
3. Go to Timesheets, search for the employee
4. Navigate to a past week
5. Enter 4h on each working day
6. Observe the overtime indication shows incorrect value (-01:00)

**cause:**
In `resource/models/resource_calendar.py`, the flexible hours algorithm that determines the date range by converts UTC boundaries to the employee's timezone. When the employee's timezone has a positive UTC offset (UTC+1, like in brussels time zone), `Sun 23:59:59 UTC` becomes `Mon 00:59:59 CET`, pushing `end_date` to the next Monday. This creates an 8 day range instead of 7. The algorithm then starts a new weekly budget for the spillover day and allocates 1 extra hour, making `allocated_hours` 20.9999998 instead of 20.

**fix:**
- Use the UTC date before conversion to the employee's timezone when determining the flexible date range.


**note:**
Updating the test (test_no_carried_over_leaves_for_flexible_resource) in hr_holidays/tests/test_expiring_leaves.py expected duration logic, is to match the corrected inclusive day range and prevent asserting the
previous spillover behavior.

link to the enterprise PR: odoo/enterprise#112879

opw-5970511

---

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

Forward-Port-Of: odoo/odoo#261733
Forward-Port-Of: odoo/odoo#257269

# Setup
Have 2 companies : A & B

# How to reproduce
- Set your website's company to Company B
- Create product X :
	- Company : Company A
	- Published
	- Name : xyz
- Go to Users > Any User > Acces Rights > Allowed Companies => leave only Company A
- Connect as that user on the website
- Go to the Shop tab and search xyz

# The problem
The product X is displayed, even though we currently use the company B's website and the product is limited to company A. 
This causes problem later when Sales Order are created using that product.

If you set the Allowed Companies of the user to both Company A and Company B, then the product is correctly hidden

# Why
When you search something in the search bar, the server does a `_search_with_fuzzy()` that ends up calling a simple `model.search()`.
In our case, this search should not return product X because there is an `ir.rule` that hides product not in the current company :
https://github.com/odoo/odoo/blob/0bb5ac6c1a87367c1ebb343ad6e6e6e56188cf13/addons/product/security/product_security.xml#L34-L38

But the `website` module has some particular rule about setting the current company :
https://github.com/odoo/odoo/blob/0bb5ac6c1a87367c1ebb343ad6e6e6e56188cf13/addons/website/models/ir_http.py#L249-L261

So, in our case, since the user does not have company B in its allowed companies, then
`allowed_company_ids` = Company A. So `('company_id', 'parent_of', company_ids)` is trucy and the product is displayed

# Proposed solution
Doing the search with `with_company` raise an AccessError because the company is not present in the allowed_companies. Chaging the allowed companies logic seems risky because it
may lead to unintended side effects.

We instead enforce the website's company in the search's domain

opw-6115647

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

Forward-Port-Of: odoo/odoo#260138

Steps to reproduce
1. Install l10n_ar (or any LATAM localization).
2. Go to Accounting > Configuration > Journals and open a Purchase journal
   that has "Use Documents?" enabled.
3. Enable "Secure Posted Entries with Hash".
4. Create and post a vendor bill with a high document number (e.g. 00001-00009999).
5. Create another vendor bill with a lower document number (e.g. 00001-00000100)
   and try to post it.

Issue
Posting the second vendor bill fails with:
"This move could not be locked either because some move with the same sequence
prefix has a higher number. You may need to resequence it."

The hashing logic in account_journal.py enforces a strict continuous sequential
chain per journal:
https://github.com/odoo/odoo/blob/89993885823f7309b921145eacc7bbe2c3c1e427/addons/account/models/account_journal.py#L671-L678

In LATAM countries, vendor bill document numbers are assigned by the vendor, not
by Odoo. A bill with a lower number can legitimately be entered after one with a
higher number, which breaks the sequential assumption the hash chain relies on.
Allowing it would produce a hash that no longer represents a proper chain, giving
users a false sense of security. Sales journals are unaffected because Odoo
controls their sequence.

Solution
Hide the "Secure Posted Entries with Hash" field on purchase journals that have
"Use Documents?" enabled, preventing users from enabling an option that cannot
work correctly for vendor-assigned document numbers. Sales journals keep the
option available since Odoo controls their sequence.

opw-6076673

Forward-Port-Of: odoo/odoo#259206

**problem:**
On timesheets, the overtime indication next to an employee's name is incorrect when using flexible work schedules. for example: a "Flexible 20h" schedule (4h a day) shows 1h of negative overtime even when the employee has logged exactly 20h for the week.

**steps to reproduce:**
1. Create a new working schedule with flexible hours enabled for example (20h/week, 4h/day average)
2. Assign this schedule to an employee
3. Go to Timesheets, search for the employee
4. Navigate to a past week
5. Enter 4h on each working day
6. Observe the overtime indication shows incorrect value (-01:00)

**cause:**
In `resource/models/resource_calendar.py`, the flexible hours algorithm that determines the date range by converts UTC boundaries to the employee's timezone. When the employee's timezone has a positive UTC offset (UTC+1, like in brussels time zone), `Sun 23:59:59 UTC` becomes `Mon 00:59:59 CET`, pushing `end_date` to the next Monday. This creates an 8 day range instead of 7. The algorithm then starts a new weekly budget for the spillover day and allocates 1 extra hour, making `allocated_hours` 20.9999998 instead of 20.

**fix:**
- Use the UTC date before conversion to the employee's timezone when determining the flexible date range.
- prefer `self` when it is the flexible calendar being queried, so hr_contract's `_get_calendar_at()` override cannot substitute the contract's calendar parameters (full_time_required_hours, hours_per_day) for the flexible ones.

**note**
Updating the test (`test_no_carried_over_leaves_for_flexible_resource`) in `hr_holidays/tests/test_expiring_leaves.py` expected duration logic, is to match the corrected inclusive day range and prevent asserting the previous spillover behavior.
link to the enterprise PR: https://github.com/odoo/enterprise/pull/112879

link to the community PR: https://github.com/odoo/odoo/pull/257269

opw-5970511

---

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

Forward-Port-Of: odoo/enterprise#115435
Forward-Port-Of: odoo/enterprise#112879