## Issue:
When a Purchase Order is created for a quantity of 2 and only 1 unit is received, importing a vendor bill with quantity 2 and the same unit price incorrectly results in a full match

The PO is linked, but the bill line quantity is overwritten to 1 (the received quantity), leading to an inconsistency between the imported bill and the original document

## Cause:
In `_match_purchase_orders()`, a match is performed based on `partner_id` and `amount_total`:
https://github.com/odoo/odoo/blob/92a3fe87c711f18d955ddf454ce1f4194dfcda20/addons/purchase/models/account_invoice.py#L429-L439

However, the previous safeguard logic
related to `total_match` is missing:
https://github.com/odoo/odoo/blob/92a3fe87c711f18d955ddf454ce1f4194dfcda20/addons/purchase/models/account_invoice.py#L388-L400

This check is not only meant to compare total amounts; it should also ensure that the `amount_to_invoice` is consistent

When the purchase method is based on received quantities, the full ordered quantity should not be considered a full match if part of it has not yet been delivered

## Steps to reproduce:
We'll use the default company as vendor, choose depending on your setup
- Install `purchase`
- Create a Product (invoicing policy: ordered qty, and control policy: delivered qty)
- Create and confirm a PO (Vendor: Default Company, Product: Created Product, Quantity: 2, Unit Price: 100)
- Set the received quantity to 1
- Create and post an Invoice (Customer: Default Company, Product: Created Product, Quantity: 2, Unit Price: 100)
- Download the PDF
- Go in Bills and import the PDF Before the fix, the match should be done and there is a quantity mismatch

opw-5043054

Currently, certain `valid GSTINs` for Non-Resident taxpayers are not 
recognized by the partner `autocomplete` feature.

**Steps to reproduce:**
- Install the `l10n_in` and `partner_autocomplete` modules.
- Navigate to Settings > Users & Companies > Companies.
- Click `New` and set `Tax ID` to `9922JPN29001OSU`.
- Wait for 5–10 seconds.

**Observation:**
The partner autocomplete does not trigger, although it is valid and verifiable 
on the official GST portal: https://services.gst.gov.in/services/searchtp

**Root Cause:**
The issue was already fixed in core validation by PR [1], but the 
GSTIN validation logic used in partner autocomplete was not updated.

At [2], the GSTIN validation regex for NRI taxpayers only supports 
formats ending with `NRX` (X = any alphanumeric character). However, 
certain valid GSTINs follow a revised structure and therefore are not 
matched by the existing regex.

**Fix**:
This commit ensures that valid NRI GSTIN formats are accepted 
during validation by applying a fix similar to [1] to the partner 
autocomplete GSTIN validation at [2].

Related IAP PR: https://github.com/odoo/iap-apps/pull/1491

[1]:
https://github.com/odoo/odoo/pull/251760

[2]:
https://github.com/odoo/odoo/blob/3016c08a7aa8701ec9b0092b5aafc282b16dd9f3/addons/partner_autocomplete/static/src/js/partner_autocomplete_core.js#L36-L52

Forward-Port-Of: odoo/odoo#253799

Description:
------------------

When viewing attendance in Gantt view with flexible working schedules,
expected hours displayed incorrectly when device, company, and employee
calendar timezones differ (e.g., 1 day shows 16h instead of 8h).

Root cause:
------------------
 Two related timezone handling issues:
1. Gantt passes UTC boundaries that span multiple calendar days when
   converted to calendar timezone
2. Resource calendar creates flexible intervals using wrong timezone
   (employee timezone instead of calendar timezone)

Test update:
-------------------
Updated test_no_carried_over_leaves_for_flexible_resource to reflect
correct flexible calendar behavior. For flexible calendars, the duration
between dates counts inclusive calendar days. Changed the calculation
from `days * 24 / hours_per_day` to `(end_date - start_date).days + 1`
to properly account for inclusive date counting (e.g., Dec 30 to Dec 31
includes both days = 2 days).

Solution:
--------------
- hr_attendance_gantt: Normalize date boundaries to full calendar days
  in calendar timezone before passing to interval calculation
- resource: Force flexible hours block to consistently use calendar
  timezone for date extraction and interval creation

opw-5241330

**PROBLEM**
Here is the client use case:
The client uses fixed tax to do 'vidange/consignage'. When selling a product with a 'consigne/vidange', they add a fixed tax which amount correspond to the 'consigne/vidange'. When returning the 'consigne', you would create an invoice line, with a product with a price of 0, negative quantity,a 0% tax and the fixed tax for the 'consigne'. When an invoice contains such lines, it fails peppol validations.

**STEP TO REPRODUCE**
1. Create a fixed tax used for 'vidange/consigne'.
2. Create an invoice, with a line with unit price of 0, negative quantity, a 0% tax and the fixed tax for the 'consigne'.
3. Send the invoice using peppol, use a validator to validate the xml and notice you get the following errors: [BR-E-01] [BR-E-08].

**CAUSE**
Fixed tax (like the one used for vidange) are aggregated in new invoice lines by the function `_ubl_turn_emptying_taxes_as_new_base_lines()`. Let say we have the following invoice:
line 1: qty=2, unit_price=3, taxes: 21% & vidange(fixed tax of 1). line 2: qty=-1, unit_price=0, taxes: 0% & vidange.

After calling `_ubl_turn_emptying_taxes_as_new_base_lines()`, we got: line 1: qty=2, unit_price=3, taxes: 21%.
line 2: qty=-1, unit_price=0, taxes: 0%.
line 3: qty=1, unit_price=1(amount of the fixed tax), taxes:None.

When generating the VAT breakdown, we have 2 line will end up being tax exempted (line 2 and 3). Because the `tax_exemption_reason` differs, they will not be merged in the same entry in the breakdown, which break the constraint of peppol saying we can only have one VAT breakdown with code 'Exempt from tax'.
Line 2 reason comes from:
https://github.com/odoo-dev/odoo/blob/de22093ee225df499b2de80e1f07dd281ac686bc/addons/account_edi_ubl_cii/models/account_edi_common.py#L271-L274

opw-5912986

Currently, if a user selects an exchange difference account as a write-off but then
decides to keep the invoice open, the system still fully reconciles the invoice.

Steps to reproduce:
- Create an invoice in foreign currency
- Click 'Register Payment'
- Select company currency
- Change the amount to a lower one
- Select 'Mark as fully paid'
- Add the exchange difference loss/gain account as write off account
- Select 'Keep open'
- Click 'Create payment'

Issue:
Even though the user selected the option to create a partial payment and keep
the invoice open, it is totally reconciled with a difference booked in the
selected exchange account.

Analysis:
This occurs because the use of the exchange account as write off account
trigger a specific flow used in localization where a writeoff is not allowed.
Once the payment registration process is ongoing, the system does not check
that user kept the same choice on how to handle the payment difference.

opw-5468052

Forward-Port-Of: odoo/odoo#251965