**Problem:**
If a vendor bill associated with a project through its analytic distribution has lines with negative subtotals, those lines are not considered in the project profitability report. An example use case is a downpayment invoice, followed by a final invoice with the downpayment amount deducted.

**Steps to Reproduce:**
- Ensure project_purchase is not installed
- Create a new project with "Billable" enabled
- Go to the project settings and create an analytic account
- Create and post a vendor bill with a line labeled "downpayment", the analytic account set, and a unit price of 5
- Duplicate the vendor bill, set the "downpayment" line unit price to -5, add a line labeled "product" with the analytic account set and a unit price of 10, and post the bill

-> Go to the project updates and see that the vendor bill costs is wrong (15)

**Solution:**
A similar bug affecting customer invoices was resolved in PR #130992. AMLs with non-zero subtotals should be considered, so the domain is adjusted accordingly.

opw-6172523

**Steps to reproduce:**
- In the contact app, chose your company
- Go to the Accounting tab
- Create a bank account and check "Send Money"
- Create a partner, create a bank account for it
- Do not Check the "Send Money"
- Go to the POS, click on a product and refund it 100% to make the price 0
- Chose the partner we created as the client and ask for an invoice
- Try to pay, the account is not trusted

**Why the fix:**

With this same steps, if we make a normal order with a price different than zero, it will work. But if the price is negative,
we will get the same error.

This happens because the *partner_bank_id* is chosen depending on if this is a refund or not. With an amount of zero, the order is considered to be a refund, and we chose the partner's partner_bank_id, which is not trusted.

On a normal positive flow, we chose the company's which is trusted, so we can send the money and it works.

This does not make sense to assume a zero amounted order is a refund, because when we invoice something that is zero or greater, we get an invoice, but only for the *partner_bank_id* we chose it as if it was a credit note.

So we should take the partner's *partner_bank_id* for every order that has a strictly negative amount, and take the company's for every order that is zero or positive.

Another way to fix this would be to backport this commit that also resolves this issue starting in 18.0 by adding a fallback to the company's *partner_bank_id*, but it might be a bit much of a change for version 17.0 https://github.com/odoo/odoo/commit/7e63991dceb6e443b950e6a1b94454a82d5668c7

opw-6005384

**Problem:**
On the /shop page, the "Fill" option in the web editor (cover/contain toggle on product card images) appears clickable but has no visible effect on the product thumbnails.

**Steps to reproduce:**
1. Install website_sale and open /shop.
2. Open the web editor and select the shop page.
3. Locate the "Fill" button group in the right panel (with the two svg icons).
4. Click the alternate option to switch between cover and contain.
5. Observe that the product card thumbnails do not change appearance.

**Current behavior:**
The toggle flips the `o_wsale_context_thumb_cover` class on the products table (and the activation of the `products_thumb_cover` view), but the product images keep rendering with `object-fit: contain` regardless of the toggle state.

**Expected behavior:**
The image fill mode follows the toggle:
- "cover" option active   → product image uses `object-fit: cover`
- "cover" option inactive → product image uses `object-fit: contain`

**Cause of the issue:**
The product image template renders the img with the `object-fit-contain` utility class, and the local SCSS rule declares
`.object-fit-contain { object-fit: contain !important; }`. The CSS variable `--o-wsale-card-thumb-fill-mode` (set to `cover` by `.o_wsale_context_thumb_cover`) does cascade down to the img, but the non-variable, `!important` rule on the utility class always wins, so the variable-driven rule
`object-fit: var(--o-wsale-card-thumb-fill-mode, contain)` is silently overridden and the toggle becomes inert.

**Fix:**
Making the `.object-fit-contain` rule read the same CSS variable lets the existing toggle mechanism take effect without changing any template or removing the utility class. Outside the `.o_wsale_context_thumb_cover` context the variable is undefined, so the `var(..., contain)` fallback preserves the prior `contain` behavior for any other consumer of the class. This keeps the change to a single SCSS line, with no XML touched and no other CSS class semantics altered.

opw-6231432