When using a different uom for a receipt than the uom of the product, the forecast will not take it into account correctly.

Steps to reproduce:
-------------------
* Create a product AA and track it by Kg
* Create and confirm a receipts for 10 000g of AA
-> On the product AA forecast, the value from the past start a -9990.

Observation:
-------------
To load the forecast it will create a ReportStockQuantity, all the forecast operation will be done on the sql query:
https://github.com/odoo/odoo/blob/427d398880c381981e088f7001f855a10d1cd581/addons/stock/report/report_stock_quantity.py#L47
In this query it will calculate the quantity of product and it will reconstruct the history of the inventory.
For dates intervals before the move date it will use quantity (the actual quantity moved), for moves after it will use product_qty (the expected quantity to be moved):
https://github.com/odoo/odoo/blob/427d398880c381981e088f7001f855a10d1cd581/addons/stock/report/report_stock_quantity.py#L152-L160
Since it is reconstructing the history of the inventory, for the dates before the move happend, it remove the quantity from the inventory:
https://github.com/odoo/odoo/blob/427d398880c381981e088f7001f855a10d1cd581/addons/stock/report/report_stock_quantity.py#L161-L166
The issue is that quantity is not in the same uom as product_qty, product_qty is in the uom of the product and quantity of the stock move.

opw-6401941

Steps to reproduce:
- More products/customers than the loading limits (or a product made unavailable in PoS after its order was placed)
- Sell such a product to such a customer, close the order
- Reopen the ticket screen in a fresh session and open the paid order

Issue:
The order shows without its orderlines (silently deleted), so it cannot be refunded correctly. Its customer is blank: a refund loses the partner and invoicing asks to pick a customer again.

Cause:
Since 64ca0e5e924a the ticket screen fetches paid orders through `callRelated("pos.order", "get_ticket_screen_order_data")` instead of `data.read("pos.order", ids)`. `read` is part of
`autoLoadedOrmMethods`, so `missingRecursive()` fetched the products and partners referenced by the orders; `callRelated` loads the payload as-is, and `read_pos_data()` includes neither `product.product` nor
`res.partner` records. An orderline whose product is not in the store is deleted by its `setup()`, and an unknown `partner_id` stays unresolved.

Fix:
Send the orderlines' products and the orders' partners along in `get_ticket_screen_order_data()`: `loadData()` links the records before the orderlines' `setup()` runs, so the frontend keeps them. Server-side only, no API change; 19.0 already loads missing records through `read_pos_orders` + `missingRecursive` (f12407c2cf31), so the forward-port is a no-op.

opw-6524807

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

Before this commit, the "Get A Booth" page of an event could keep listing the booths of the category checked on load after the visitor picks another one. Only a page reload brought the right ones back. The tour webooth_exhibitor_register timed out on that list:

FAILED: [5/13] Tour webooth_exhibitor_register -> Step Choose Booth (trigger: .o_wbooth_booths div:contains(OpenWood Demonstrator 2) input:not(:visible)).
TIMEOUT step failed to complete within 10000 ms.

This happens because the page fetches the booths of the category checked on load, and clicking another category fetches its booths while that first answer is still on its way. The answer coming back last fills the list, and the widget caches it under the category active on arrival, so the booths of the first category land in the cache of the clicked one.

This commit fixes the issue by caching an answer under the category it was asked for, and by filling the list only while that category is still the chosen one.

https://runbot.odoo.com/odoo/error/110527
https://runbot.odoo.com/odoo/error/161834

Steps to reproduce:
- open Discuss, open any chat, open the emoji picker (no 'Frequently used'
  emojis)
- search a term and select emojis without closing the picker (shift+click on
  desktop, plain click on mobile)
- clear the search with backspace

=> traceback: 'Cannot read properties of null (reading
`getBoundingClientRect`)' in adaptNavbar().

This happens because when we clear the search input it calls
`highlightActiveCategory()`, which sets `categoryId` to the topmost category of
the grid, which is now the 'Frequently used' category (sortId 0), added to the
picker since the emojis we just picked updated the recent state. To update the
navbar, `currentNavbarPanel` then looks for the panel holding it in
`emojiNavbarRepr`, but that representation is only built in `adaptNavbar()`,
which runs on mount and from the `ResizeObserver` only, so it was built without
the 'Frequently used' category and no panel contains it. It returns undefined,
the navbar renders empty, its size change wakes the `ResizeObserver`, and
`adaptNavbar()` crashes on querySelector('.o-Emoji').getBoundingClientRect()`.

This commit solves the issue by rendering the `recentEmojis` from a snapshot
taken when the picker is opened, so they are not added to the picker while the
while `emojiNavbarRepr` does not contain their category id.

partial backported PR: https://github.com/odoo/odoo/pull/281104

Task-[6204249](https://www.odoo.com/odoo/project/1519/tasks/6204249)



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

…tempalts for VAT unregistered Companies

In Saudi Arabia (ZATCA), a business's legal authority to issue tax documents is dictated by annual revenue thresholds: registration is mandatory above SAR 375,000, voluntary between SAR 187,500 and SAR 375,000, and exempt below SAR 187,500. Per Article 53 of the KSA VAT Implementing Regulations, only a registered "Taxable Person" may issue a Tax Invoice (B2B) or a Simplified Tax Invoice (B2C). In the UAE, the Federal Tax Authority (FTA) imposes the same registration prerequisite.

Previously the bilingual GCC tax layout was chosen purely from the company's country, on both the invoice report and the POS receipt. For SA and AE, we now only use the GCC report templates when the company actually has a VAT number; otherwise we fall back to the standard report template. The remaining GCC countries (BH, OM, QA, KW) are unaffected.

The POS receipt flag `is_gcc_country` is renamed to `use_gcc_report` to enhance code readability

task-6326221

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

Issue:
----------------------------------------
When a user removes themselves as Attendance manager on the last employee on which they're set an error pops up.

Steps to reproduce:
----------------------------------------
- Connect as a user with the group `group_hr_attendance_manager`
- Install hr_attendance
- Don't be the attendance manager of any employee
- Go to an employee form, add yourself as attendance manager
- Try removing yourself as attendance manager
- Error

Cause:
----------------------------------------
When removing someone as Attendance manager, `_clean_attendance_officers()` is called to remove the group `group_hr_attendance_officer` from any user without any employee to manage.

But the field `attendance_manager_id` itself is only accessible to users with the group `group_hr_attendance_officer`. So during the `web_read` after the `write`, the user doesn't have access to the field and an access error is thrown.

Solution:
----------------------------------------
`group_hr_attendance_officer` is implied by `group_hr_attendance_manager`. So a user should never have only `group_hr_attendance_manager`.

We modify `_clean_attendance_officers()` to not remove `group_hr_attendance_officer` when the user has `group_hr_attendance_manager`.

opw-6471482

The issue fixed in commit[1] is again reproducible after commit [2] the pos order line for gift card is now not considered as a refund

Step to reproduce:
- Install pos_loyalty and l10n_es_edi_tbai_pos with demo data
- Create a gift card (add a tax to the discount product, any 0%)
- start pos, add a product and use the gift card
- fulfill the order
- go to backend and open that order
- In the TicketBAI XML, the values for the giftcard product will be positive, causing an inconsistency between the product line total and the invoice total

[1] https://github.com/odoo/odoo/commit/0bbc5ebdcc7e014d87130b2ff9cee98e3aa7479a
[2] https://github.com/odoo/odoo/commit/b17c9713e7a3305c240298fa54fcf1bc87a9bb8c

FIX
- we used to determine `sign` based on each order line's `is_refund` property
- this property is quite sensitive as it depends on factors like line's qty, price, is reward or not.
- so its better to depend on order's refund property for sign reversal

https://github.com/odoo/odoo/blob/4fef2c5b69fac10594fac81b149d542ee4621b13/addons/point_of_sale/models/pos_order.py#L1768


opw-6226003



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

#### Description of the issue/feature this PR addresses:
Rating a Starshipit shipment for an incomplete delivery address makes the whole rating loop fail instead of skipping that carrier. This breaks express checkout (Apple Pay / Google Pay), where the wallet only discloses a partial address before authorization: the customer gets "update postal address" and cannot pay, while manual checkout works.

#### Current behavior before PR:
delivery_starshipit is the only connector that rates a shipment without validating the addresses first, and it ignores the express_checkout_partial_delivery_address context key set by website_sale. The empty street is sent to /api/rates, which answers 200 with {"success": false, "errors": [{"details": "street parameter value is required"}]}, and _send_request turns that into a UserError. As starshipit_rate_shipment lets it propagate, it aborts the rating of every carrier instead of only this one, so no delivery method reaches the wallet. The same happens for errors only the api can report, such as invalid credentials.

#### Desired behavior after PR is merged:
Both the recipient and the warehouse address are validated before the api is called, as the other connectors already do, and the message is returned as an unsuccessful rate rather than raised. Starshipit requires the street, so a streetless address is still refused, but with a neutral message in the express checkout flow since the customer cannot complete it before paying. The Starshipit carrier is simply not proposed among the wallet's options, the other carriers are rated normally, and express checkout completes.

opw-6393393

Forward-Port-Of: odoo/enterprise#125117