When using shiplater in PoS and creating a backorder from the original picking, the COGS would be duplicated when validating the backorder.

Steps to reproduce:
-------------------
* Create 2 products, one with a cost of 20 and one with a cost of 0
* Create a PoS order with 2 lines, one for each product
* Validate the order using the shiplater option
* Close the session and go to the picking created
* Validate the delivery only for the product with a cost of 20 and make a backorder for the product with a cost of 0
* Go to the session accounting entries and check the COGS entries, you should see one entry for the product we just processed
* Validate the backorder
> Observation: A second COGS entry is created for the product with a
  cost of 20

Why the fix:
------------
Instead of creating the COGS entries based on the PoS order lines, we now create them based on the stock move lines. This way, we only create the COGS entries for the stock move lines that are actually processed. We also avoid creating COGS entries for the stock move lines that have no cost.

opw-4597430

Description of the issue/feature this PR addresses:
- This PR changes the TD05 to be considered a Vendor Bill instead of a Vendor Credit Note, when uploading document in Purchase journal in Italy's localization. 
- This PR changes the debit note of a customer invoice to be considered a TD05 instead of a TD01. The debit note used to take the document id of the original customer invoice, which is TD01. So new override `copy` function was created in Italy `AccountMove` to check if new move is from a debit note and if yes, set document type of new move to TD05.

tasks-4744444

Current behavior before PR:
- When uploading TD05 in the Purchase journal, it's considered a Vendor Credit Note.
- When creating a debit note from a customer invoice, the new invoice has TD01 document type

Desired behavior after PR is merged:
- When uploading TD05 in the Purchase journal, it's considered a Vendor Bill.
- When creating a debit note from a customer invoice, the new invoice has TD05 document type

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

… are share

If all the user type groups have the flag `Share` as true, they will be filtered out by `get_application_groups`. While updating `user_groups_view`, the field `user_type_field_name` will never be assigned, as the condition 
`app.xml_id == 'base.module_category_user_type'` will never be fulfilled.

That means that `user_type_invisible` will be `None`, but that's not a valid value and it will break.

Steps to reproduce:
- Mark all the user type groups as Share.
- Upgrade `base`.

```
File "/home/odoo/src/odoo/18.0/odoo/addons/base/models/res_users.py", line 1801, in _update_user_groups_view
    E.group(*(xml2), invisible=user_type_invisible),
  File "src/lxml/builder.py", line 204, in lxml.builder.ElementMaker.__call__
  File "src/lxml/builder.py", line 186, in lxml.builder.ElementMaker.__init__.add_dict
KeyError: <class 'NoneType'>
```

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

## Version:
17.0+

## Issue:
Stripe payments with an unregistered card on backdated subscriptions lead to Stripe API refusal.

## Steps to reproduce:
Ensure Stripe is well configured in `Test Mode` with `Credentials`; Create a new Sale Order with `Monthly Cleaning` as `Quotation Template` for any customer:
- Under `Other Info` tab, change the `Subscription` `Start Date` for a date at least 2 days before current date;
- Confirm and create regular invoice:
  - Set `Invoice Date` to the same date as the subscription;
  - Confirm and go to the invoice's preview and start payment process:
    - Use a new card for payment;
    - Check `Save my payment details` checkbox and pay.

## Cause:
The Stripe mandate needs to be filled with a start date at least equal to yesterday (https://docs.stripe.com/api/payment_intents/create#create_payment_intent-payment_method_options-card-mandate_options-start_date). Subscription app sets the start date to the SO's `start_date` via https://github.com/odoo/enterprise/blob/5642ad28919081a44bb47c0d936aa51980178d09/sale_subscription/models/payment_transaction.py#L51-L52. The values are retrieved by `_stripe_prepare_mandate_options()` via https://github.com/odoo/odoo/blob/d231565ec9054556d025b093195a934f28d067c3/addons/payment_stripe/models/payment_transaction.py#L206 and sent to Stipe under a new structure given by https://github.com/odoo/odoo/blob/d231565ec9054556d025b093195a934f28d067c3/addons/payment_stripe/models/payment_transaction.py#L209-L220

## Fix:
Initial suggestion made in the `payment_stripe` module (https://github.com/odoo/odoo/pull/207451), but later moved to the origin of the issue. As of 2025-05-12, Stripe seems to have fixed the issue, but this patch is still applied as a safety measure.

opw-4654142

…Inter-Company sync

### Steps to reproduce:

- With Company B in the settings Enable Inter-Company Transactions
   > Synchronize Sales and Purchase Order
- Sales > Configurations > Sales Teams, Archive all sales team
- With COMP A create a sales team with a set company_id: COMP A
- With COMP A create and confirm a PO with COMP B as customer
#### > Invalid operation: while generating the SO, the sales team belongs to COMP A and the SO to COMP B.

### Cause of the issue:

The `team_id` field of the `sale.order` model is a stored pre-computed and company checked field. As such, when the SO is created and even if no sales team is provided to the create vals:
https://github.com/odoo/enterprise/blob/c61ce5a8e46e706bfb2025d4c9c79a39598e8827/sale_purchase_inter_company_rules/models/purchase_order.py#L70 a default sales team will be computed and set on the SO based on the "allowed_company_ids" (including both COMP A and COMP B): https://github.com/odoo/odoo/blob/1fa8678a33ab35195005d1b65b5eecb1d089fe56/addons/sale/models/sale_order.py#L453-L460 https://github.com/odoo/odoo/blob/1fa8678a33ab35195005d1b65b5eecb1d089fe56/addons/sales_team/models/crm_team.py#L81-L88
While the domain checks that the sales team is either not tight to a company or belong to comp B, since no such teams were found, we fallback the invalid sales team of COMP A. The invalid operation is then raised during the `_check_company` of the created record.

opw-4627851