Steps to reproduce
------------------
1. On a peruvian company, set a cash rounding method on an invoice
2. Post the invoice and generate the SUNAT UBL 2.1 XML

-> the rounding is in `PayableRoundingAmount` but `PayableAmount` still
   has the amount before rounding!

Why it's happening
------------------
The generic code computes `PayableAmount` from `amount_residual`, and Peru overrides it to be the total tax included of the XML minus the prepaid amounts, because the residual can not be used there.

Then odoo/odoo@b847552872ad changed the meaning of the totals. The cash rounding line is not part of the base lines anymore, its amount is kept aside in `cash_rounding_base_amount_currency` and the totals do not contain it anymore.

The generic code stays correct because `amount_residual` already has the rounding inside but the Peru total using `tax_inclusive_amount_currency` is now the amount before rounding and this is what ends up in the `PayableAmount`!

The fix
-------
Add the cash rounding amount when computing the `PayableAmount`.

opw-6509677

## Steps to reproduce:

- Create a customer with France E-Invoicing (UBL2.1) as eInvoice format in a French company
- Go to the PoS, select that partner
- Make a sale and ask for an invoice
- The downloaded invoice will be a pro-forma invoice

## Why the fix:

The pro-forma should not be used here, it is because it is used as a fallback when we get an error while trying to print the invoice.
https://github.com/odoo/odoo/blob/4a508586970e44367bbdbbb3cbe88ffb5a1eadb7/addons/account/models/account_move.py#L6187-L6204

As we get an error while trying to send the data with this setup, it goes to the fallback and prints a pro-forma invoice, even though this should not be the case, a regular invoice would do.

This happens because when an error is found, we do not populate invoice_pdf_report_id, so it goes to the fallback.

We now check if there are any errors in the order, and if there are and the customer requests an ubl_21_fr invoice, we just print the invoice as it is, without going to the pro-forma fallback, as this is not the intended flow.

With this fix, we now have the same flow as we do in the sales module, that allows the sale even if the customer has missing data. It will just print the invoice and allow the sale but won't send anything to external entities.

opw-6428369

Forward-Port-Of: odoo/odoo#281420

# Description

**Steps to Reproduce**

1. Install Belgium Localization, then go to **Settings → Accounting/Invoicing**.
2. Enable **Verify VAT Numbers** (`vat_check_vies`).
3. Go to **Accounting → Configuration → Fiscal Positions** and confirm or create an **Intra-Community** fiscal position with:
   - Detect Automatically (`auto_apply`): enabled
   - VAT Required (`vat_required`): enabled
   - Country Group: EU, no specific country configured
4. Open an incognito/private browser window and make sure the session is unauthenticated.
5. Go to the website's `/shop` page and add any product to the cart.
6. Proceed to checkout until reaching the Address step (`/shop/address`).
7. Enter a delivery address in an EU country different from the company's country (e.g. company in Belgium, delivery address in the Netherlands).
8. In the VAT Number field, enter a real, valid, VIES-registered VAT number corresponding to the delivery country (e.g. a valid NL VAT number for a Netherlands address).
9. Click **Save Address / Continue** and proceed to the Payment step (`/shop/payment`).
10. Check the tax applied to the delivery line and the resulting order total.

**Issue**

The delivery product and the overall order are taxed at the standard/domestic VAT rate instead of the expected 0% intra-community rate — even though the customer provided a valid, VIES-registered EU VAT number matching the delivery country.

**Root Cause**

In `base_vat`, `res.partner.create()` unconditionally removes `vies_valid` from the ORM's pending computation queue via `env.remove_to_compute()`, relying on a subsequent `write()` to trigger the actual VIES check. This holds for the standard backend flow, where creation is followed by a `write()` — but the website guest checkout flow differs:

- `website_sale` creates the guest partner through `_create_new_address()`.
- The partner is created via a single `create()` call, with no follow-up `write()`.
- `_compute_vies_valid()` is therefore never triggered.
- `vies_valid` remains permanently unset (`NULL`), despite a VAT number being provided.

Downstream, `account.fiscal.position._get_vat_required_valid()` reads this unset value as falsy, so the Intra-Community fiscal position's `vat_required` condition fails and is rejected in favor of another applicable position (e.g. EU B2C or Domestic).

**Solution**

After partner creation, explicitly trigger `_compute_vies_valid()` when the partner has a VAT number and the operation is not part of a file import (`import_file` context) — performing the VIES check immediately instead of relying on a `write()` that guest checkout never issues.

**Result**

Guest customers providing a valid EU VAT number now get `vies_valid` computed immediately at creation. Fiscal position detection correctly identifies the Intra-Community position, and the expected 0% VAT treatment is applied to the delivery and order.

OPW: 6522992

Forward-Port-Of: odoo/odoo#286201

Description of the issue/feature this PR addresses:

Downloading an attachment from the file viewer fails with a `405 Method Not Allowed` error when the attachment belongs to a Discuss channel.

I've already submitted a ticket to Odoo: #6430586

Steps to reproduce (on a 18.0 runbot):
1. open Discuss and send an image in a channel
2. click the image to open the file viewer
3. click the download button (either the one in the header or the one in the bottom
   toolbar)

The server rejects the request:

```
POST /discuss/channel/1/image/519861?filename=image.png&unique=32647b0f&download=true  405
```

and the user gets a `RPC_ERROR: Arbitrary Uncaught Python Exception` dialog reporting `405 Method Not Allowed`.

Cause: `download()` always issues a POST request, while the routes serving the attachments of a discuss channel only allow GET:

* `/discuss/channel/<int:channel_id>/attachment/<int:attachment_id>`
* `/discuss/channel/<int:channel_id>/image/<int:attachment_id>`

so the request never reaches the controller. Downloading the very same attachment from the attachment card in the conversation still works, because that one is a plain anchor navigation (GET).

This is a regression from fb152985f4b8 ("[FIX] web: download FileViewer files via blob helper"), which routed the file viewer download through `download()` in order to honor the filename sent by the server in the `Content-Disposition` header.

Only 18.0 is affected: saas-18.1 and saas-18.2 do not have the commit that introduced the regression, and from saas-18.3 on, the `urlRoute` override was dropped and channel attachments are served through the standard `/web/content` and  /web/image` routes, which are not restricted to GET. 
The download is still sent with POST on those branches though, hence forward-porting this up to master.

Current behavior before PR:

Downloading a Discuss channel attachment from the file viewer raises a 405 error and the file is not downloaded. Images and other file types are equally affected.

Desired behavior after PR is merged:

The file is downloaded, keeping the filename advertised by the server. The download is performed with a GET request through `downloadFile()`, which still goes through the blob helper, so the fix of fb152985f4b8 is preserved. This is already the way a file is downloaded from its url in `readonly_file.js`.

Added a test that downloads an image attachment of a channel from the file viewer and asserts the request is a GET on the channel attachment route. It fails before this fix with `POST /discuss/channel/1/image/1`.

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

Forward-Port-Of: odoo/odoo#279957
Forward-Port-Of: odoo/odoo#279232

Currently on creating  new helpdesk team everytime a new website menu is created.

### **Steps to Reproduce:**
1) Install website_helpdesk
2) Navigate to `Helpdesk>Configuration>Helpdesk Team`. 
3) Create 2 helpdesk team with `Website Form` option enable. 
4) Navigate to Website.

### **Observed Behavior:**
Two Help menus are created.

### **Expected Behavior:**
Multiple menus should not be created.

### **Root Cause:**
The menu creation logic relies on the following [condition](https://github.com/odoo/enterprise/blob/b66097122ba3a758734ac6fb2b26579c35cb72c2/website_helpdesk/models/helpdesk.py#L111-L112)
`team_count_by_website` is built from `_read_group(..., ['website_id'], ...)`,
which keys its result by the `website_id` *recordset*, not its id. Looking it
up with `team_count_by_website.get(website.id, 0)` therefore always misses and
falls back to `0`, so `team_count <= 1` is always `True` regardless of how
many teams already exist for that website. The only thing left guarding menu
creation is `any(team.website_menu_id for team in teams)`, which only looks at
the teams in the current create/write call, not every team on that website.
So saving a second team in a separate call always creates another menu.

### Fix:
Make the website menu a resource shared by every team with the website form
enabled on a given website, instead of "owned" by whichever team created it:
- Before creating a new menu, look up other teams (active or archived) that
  already point to a menu, matched through the `website_menu_id` relation
  between teams rather than a hardcoded `/helpdesk` URL, so a customized menu
  URL doesn't cause a duplicate to be created. Reuse that menu when found.
- Only delete a menu once no team (active or archived) still references it,
  checked before removing a team's own reference.

**opw-6303846**

Forward-Port-Of: odoo/enterprise#130207
Forward-Port-Of: odoo/enterprise#121120