Steps to reproduce:
-------------------------
1. Install `hr_payroll` module
2. Enable debug mode and click on Become Superuser
3. Go to All Payslips and open any payslip record
4. Click on the Export Payslip button

Observation:
-------------------------
A 404 (Page Not Found) error appears when clicking the Export Payslip button

Issue:
-------------------------
The button triggers the route `/debug/payslip/<id>`, which was removed in the following commit
https://github.com/odoo/enterprise/commit/57969bcaf876a13c36794adeb47e0da938e297ad#diff-0105b1a6a9e742e7eeaf7cc727745ebd3932177378d46332d4ca854f931b3359
The route was never reintroduced afterward, but the Export Payslip button remained in the view.
As a result, clicking it leads to a 404 error

Solution:
-------------------------
1. Temporarily bypass the `action_export_payslip` function.
2. Remove the Export Payslip button from the XML in the master forward port branch, as doing so does not impact any existing customizations relying on that button

opw-5115946

Forward-Port-Of: odoo/enterprise#97361
Forward-Port-Of: odoo/enterprise#96359

… number

Bankgiro and Plusgiro accounts in Sweden normally do not have a BIC. However, for Peppol BIS 3 invoices, a BIC tag is required in the XML. The existing _skip_CdtrAgt logic prevents _get_CdtrAgt from being called when no BIC is set, causing the clearing_number to be missing in SEPA payment files for Bankgiro and Plusgiro accounts.

This commit introduces overrides for SE-specific account types:

_get_cleaned_bic_code: Returns 'SE:Bankgiro' or 'SE:Plusgiro' for Swedish Bankgiro and Plusgiro accounts, ensuring a BIC is present for the invoice XML.

_skip_CdtrAgt: Returns False for Bankgiro and Plusgiro accounts to ensure _get_CdtrAgt is called, including the clearing number in the payment file.

This guarantees that SEPA payment files and Peppol BIS 3 invoices for Sweden are generated correctly while preserving standard behavior for other banks and countries.

Backport of https://github.com/odoo/enterprise/commit/0534491bcd7eed7d246bea85d6ac217a80af815b

Forward-Port-Of: odoo/enterprise#97330

**Steps to reproduce:**
1. Install the *Fleet* and `accounting` modules.
2. Create a new purchase tax.
3. Configure the tax with a 50% repartition line for an `600000 expense` account and a 50% repartition line for a `101000 current asset` account for both income and refund.
4. Create a vendor bill with two product lines, each having a different vehicle assigned with the newly created tax in both lines.
5. Check the *Tax Report*(account>tax), including the date of this vendor bill.

**Observed behavior:**
* Tax lines linked to the current asset account are merged.
* Tax lines linked to the expense account remain separate (since `vehicle_id` is set on the `account.move.line`).
* This mismatch triggers an error in the tax report.

**Root cause:**
The tax details query does not account for the `vehicle_id` field when matching tax lines with base lines. As a result, tax lines are incorrectly merged across different vehicles.

**Solution:**
Override `_get_extra_query_base_tax_line_mapping` to include the `vehicle_id` in the matching condition, ensuring tax lines are only paired with base lines having the same `vehicle_id`. This prevents incorrect merging and resolves the report error.

opw-5013757

Forward-Port-Of: odoo/odoo#228422

## Description of the issue

The client wants to register 0.0 line to the CFE (delivery line with price 0.0): based on our findings, the only way to report lines with 0 values to the DGI is by configuring the line as a "free delivery." (invoice indicator 5). But this lines is not been reported as part of the CFE xml (neither as a Free Delivery line or discount

## Steps to reproduce

1. Create a Uruguayan electronic invoice (sales default journal on a UY company) 
2. Add a line with quantity 1. price 0
3. Add a second line with quantity 1, price 500 and discount 100% 

## Before this PR

1. if we have a line with price unit != 0.0 but with total price of the line 0.0 (as the second line), then we are reporting the invoice line as Free Delivery.
4. But, If we have an invoice with line with price unit 0.0 (example first line) then is not being informed in the CFE at all 

## After this PR

Both lines are informed to DGI using the invoice indicator 5 (Free Delivery)
You can check this on to generate CFE XML in demo mode (not need to connect to UCFE)
If you want more visual example please connect to UCFE in testing enviroment and check the generated PDF file.


References
[Odoo task](https://www.odoo.com/odoo/project/967/tasks/5015691)
LATAM 1350 / ADHOC task 53445

Forward-Port-Of: odoo/enterprise#89808

## Issue:
In debug mode, the administrator could not resend or cancel an SMS that was sent by the system (e.g. delivery confirmation) using the `Retry` / `Cancel` button in the Technical Settings An Access Error was raised

## Cause:
When using the `Retry` or `Cancel` button, the method `_update_sms_notifications()` is called and finds `mail.notifications` records to update However, `notifications.write()` triggers an Access Error because only the recipient of a `mail.notification` is allowed to modify it: https://github.com/odoo/odoo/blob/98610ea2a1369b84b10adb8913c5d7725a0fad67/addons/mail/security/mail_security.xml#L184-L192 This happens even when the user has the rights to resend or cancel the SMS

## Steps to reproduce:
- Install an app like stock_sms to create blocking entries
- Create and confirm a Delivery
- Choose Send SMS
- Enable developer mode
- Search for the technical settings SMS
- Retry sending the automatically sent SMS

opw-4904157

Forward-Port-Of: odoo/odoo#230733

In [^1], a new feature was introduced to allow users to synchronize their eCommerce with Google Merchant Center and increase their product visibility, keep stock status updated, and improve product listings.

However, the initial implementation attempted to include shipping information in the feed, which required computing rates for every product, carrier, and country. This quickly became infeasible due to performance constraints and third-party carrier rate limits, forcing us to disable the feature [^2].

This commit reintroduces the GMC feed without shipping details, making it lightweight and reliable. To ensure scalability, we also (i) enforce a limit of 5000 products per feed, and (ii) introduce a caching mechanism to avoid recomputing expensive product data (e.g., prices) for subsequent requests.

~~task-5049357~~
task-5144256

See also:
- https://github.com/odoo/upgrade/pull/8605

[^1]: https://github.com/odoo/odoo/pull/186976
[^2]: https://github.com/odoo/odoo/pull/224649

To reproduce:
1. Ensure Analytic Accounting is activated in the accounting settings
2. Uncheck the option Auto-Check on Post in the Vendor Bills journal
3. Create a vendor bill and set analytic accounts in at least one line
4. Post the vendor bill
5. Go to Accounting > Analytic Items
6. No analytic item was created for the vendor bill

In some cases, such as when the vendor bill journal has `Auto-check on Post` disabled or a there is a lock date set, the analytic items are not created when posting the move, even if analytic accounts were set on the move lines.

Cause:
In #222196, a check is performed when writing an account.move.line, which unlinks analytic lines created for draft moves. However, this condition is too general, and if additional writes happen in between the analytic line creation and changing the move state to `posted`, the analytic lines are deleted.

Solution:
The unlinking on analytic lines should only be performed if `analytic_line_ids` are in vals.

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

Forward-Port-Of: odoo/odoo#231874

**Problem:**
When confirming the invoice of an order delivered via dropship for some kit bom 
product with fifo/avco comp, if the price was manually set on the purchase order, 
the invoice lines generated for the cogs are inaccurate

**Steps to reproduce:**
- In settings enable dropshipping, automatic account and anglosaxon accounting
- Create a kit product with one component.
- Set the route as Dropship for the component.
- add a vendor in the purchase tab of the component.
- set the cost of the component at 2
- Set the product category to AVCO (Automated) for the component and the product.
- Create and confirm a sales order with a quantity of 2 for the product.
- On the purchase order set the unit price at 20 for the component.
- Confirm the purchase order, then validate the delivery and create the customer invoice.
- Confirm the invoice

**Current behavior:**
In the journal items tab of the invoice the lines for the cogs (expenses and stock interim) have a value of 22

**Expected behavior:**
The value should be 40, in accordance with the purchase order

**Cause of the issue:**
In the mrp_account override of _compute_average_price,
the stock move has no bom because it was generated from the purchase order, 
so this condition will be true
https://github.com/odoo/odoo/blob/936ab5f3f120413c7af901dd6ecc414d3e3a6d78/addons/mrp_account/models/product.py#L67
This is not a problem, however the problem comes from the fact that
move.product_id is already equal to qty_to_invoice \*component_quantity.
https://github.com/odoo/odoo/blob/936ab5f3f120413c7af901dd6ecc414d3e3a6d78/addons/mrp_account/models/product.py#L73
Multiplying it a second time by qty_to_invoice is an error.
For instance in our steps, qty_to_invoice is 2, compenent_quantity is 1 
and move.product_qty is 2.
So when calling _compute_average_price for the comp, we call it with a 
qty_to_invoice parameter of 4 instead of 2.
As a result, because the candidates svls only have a quantity of 2, there will 
be we a missing quantity.
https://github.com/odoo/odoo/blob/936ab5f3f120413c7af901dd6ecc414d3e3a6d78/addons/stock_account/models/product.py#L927-L934
So the result will be the average between the quantity on the purchase order (20)
and the standard price (2).
Which is why the account line has a value of 22 (2*11)

opw-4985440

Forward-Port-Of: odoo/odoo#229956

## Issue 1: "Allow Extra Products" option ignored for packages

### Steps to reproduce:

- In the settings enable "Packages"
- Go to Inventory > Configuration > Warehouse Management > Operation Types
- Disable "Allow Extra Products" on the "Delivery" operation type
- Create two storable product P1, P2 and add on hand quantities
    - 10 x P1 in a package PACK01
    - 10 x P2 in a package PACK02
- Create and confirm a delivery for 10 unit of P1
- Open your delivery from the barcode app
- Scan PACK02
#### > The content of PACK02 is added to the delivery even thought it contains extra products.

### Cause of the issue:

The check for extra products is only applied when scanning individual products but is bypassed by package scan. To be more precise, the `barcode_allow_extra_product` option is checked in the public method `createNewLine`:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L59-L80
While this method is called at new line creation when a product is scanned, scanning a package will add new lines during the  `_processPackage` adn bypasses the rest of the `_processBarcode`:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_model.js#L1261-L1267
The issue being that the `__processPackage` does not check the  `barcode_allow_extra_product` option and creates its new lines via the  private `_createNewLine` call:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1564-L1565
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1655-L1667
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1671

### Fix:

Since scanning a package is expected to add all its content to the  picking, and since a package can not be split among two locations, it is necessary to check in advance if any product of its content is extra and avoid any update in this case.

## Issue 2: impossibility of package line removal

### State of the art:

There is currently no option to remove a package line from the barcode. In particular, once the option `show_entire_packs`(Move Entire Packages) is enabled on a picking type, you can not remove the package line once generated by a scan.

#### Steps to reproduce:

- In the settings enable "Packages"
- Go to Inventory > Configuration > Warehoue Management > Operation Types
- Enable "Move Entire Packages" on the "Delivery" operation type
- Create a storable product and add on hand quanties:
    - 10 units in package PACK01
    - 10 units in package PACK02
- Create and confirm a delivery for PACK01 (in the package lines)
- Open your delivery from the barcode app
- Scan PACK02
#### > The new line associated to PACK02 can not be removed by any mean

opw-4863621
opw-5080637

Forward-Port-Of: odoo/enterprise#96814
Forward-Port-Of: odoo/enterprise#96299

## Issue:
When a Purchase Order is linked to a Project and its quantity is billed through multiple vendor bills, the "Expected" amount in the project profitability view was incorrect

## Cause:
When at least one invoice line exists for a PO line, `_get_profitability_items()` computes `to_bill` and `billed` amounts without using the purchase order's ordered quantity This causes the computation to only consider the quantities already billed, ignoring the remaining quantity that still needs to be billed: https://github.com/odoo/odoo/blob/cdb8370647ca4b07f89edaf5fcc687508f6af16d/addons/project_purchase/models/project_project.py#L155-L178

Additionally, the code included all credit notes, even those that were canceled

## Steps to reproduce:
- Ensure the "Sales" app is installed to display project profitability
- Create a new Project "Profitability" and mark it as Billable
- Create and confirm a PO (any product, quantity: 5, unit price: 100, Taxes: None, Other Information > Project: "Profitability")
- Check the project dashboard for Purchase Orders (Expected: -500, To Bill: 0, Billed: 0)
- Create and confirm a Vendor Bill (Quantity: 2)
- Check the project dashboard for Purchase Orders (Expected: -200, To Bill: 0, Billed: -200)
- Create and confirm a Vendor Bill linked to the PO using Auto-Complete (Quantity: 3)
- Check the project dashboard for Purchase Orders (Expected: -500, To Bill: 0, Billed: -500)

opw-5077609

**Steps to reproduce:**
- Make a sub category, such as Soda for Drinks in PoS product categories
- Make a product and assign this sub category to it
- Allow the category in the PoS configuration for a Mobile order Session
- Open the Session, the product will not be displayed

**Problem:**
When a product has a subcategory, it is not displayed in the mobile interface, even if said category is allowed in the settings.
This problem does not occur in the Kiosk, only on the mobile sessions.

**Why the fix:**
The products should be displayed if their category has been added to the available categories in the settings. It now works as it does in the PoS and the Kiosk, meaning it is displayed as long as the sub category is mentioned in the Restrict Categories section of the configuration.

Also, in case you have categories A -> A/B -> A/B/C and you don't have products associated to A but you have some in C,
they won't show up in the self.

Currently, products from child categories can be shown in the self when all their parent categories had products associated to them.

When computing the available categories, we would only return categories which had products directly related to them, regardless if their nth child had some. Thus in the setting mentioned previously, only the category C was returned.

However this logic is not correct with the fact that the self, not in kiosk mode, only shows the top categories, meaning only the categories without parents. 
https://github.com/odoo/odoo/blob/434e8cf53a039cc2efc3cb531608028182928ad9/addons/pos_self_order/static/src/app/pages/product_list_page/product_list_page.js#L146-L151

The self was not showing the products from C as C had a parent category. In order for the product from C to be shown, the category A had to be included in the list of available categories.

opw-4934728

Patch the following commit locally:
https://github.com/py-pdf/pypdf/commit/8c542f331828c5839fda48442d89b8ac5d3984ac

Issue:
A PDF files contain `/FontName /TimesNewRomanGreek#5Bbold#5D`. While this is a valid font descriptor, it gets converted to `/FontName /TimesNewRomanGreek[bold]` in `NameObject.read_from_stream` through `unhexlify` (see the complete call stack below)
The converted value is not longer valid as `[` marks the start of a `ArrayObject`. The character should have been escaped back to `#5B` before being written in a new document.

```python
  /home/odoo/git/odoo/odoo/addons/account/models/ir_actions_report.py(37)_render_qweb_pdf_prepare_streams()
-> stream = pdf.add_banner(stream, record.name or '', logo=True)
  /home/odoo/git/odoo/odoo/odoo/tools/pdf/__init__.py(288)add_banner()
-> new_pdf.write(output)
  /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/_writer.py(935)write()
-> self.write_stream(stream)
  /home/odoo/git/odoo/odoo/odoo/tools/pdf/__init__.py(127)write_stream()
-> super().write_stream(*args, **kwargs)
  /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/_writer.py(908)write_stream()
-> self._sweep_indirect_references(self._root)
  /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/_writer.py(1057)_sweep_indirect_references()
-> data = self._resolve_indirect_object(data)
  /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/_writer.py(1102)_resolve_indirect_object()
-> real_obj = data.pdf.get_object(data)
  /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/_reader.py(1256)get_object()
-> retval = read_object(self.stream, self)  # type: ignore
  /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/generic/_data_structures.py(841)read_object()
-> return DictionaryObject.read_from_stream(stream, pdf, forced_encoding)
  /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/generic/_data_structures.py(270)read_from_stream()
-> value = read_object(stream, pdf, forced_encoding)
  /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/generic/_data_structures.py(834)read_object()
-> return NameObject.read_from_stream(stream, pdf)
  /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/generic/_base.py(469)read_from_stream()
-> name = NameObject.unnumber(name)
> /home/odoo/git/odoo/.env3.11/lib/python3.11/site-packages/PyPDF2/generic/_base.py(450)unnumber()
-> while i >= 0:
```

opw-4991601

Forward-Port-Of: odoo/odoo#229489