Before this commit, a print invoice that's on 2 pages with a boxed template left 2 vertical lines on the page bottom
A negative margin top in applied that push the table top to the first page


I change the layout of `report_invoice_document` to avoid a negative margin.
The negative margin-top to `total` was there to move the float div higher to compensate the ´table` margin-bottom.

I remove the `table` margin-bottom and replace that by a `payment term` margin-top.
The margin were collapsed for `total` and `payment term` so I had to add an overflow-hidden on the parent div.


## Before :
![image](https://github.com/user-attachments/assets/382f9a8e-37db-41c3-a81e-e9adf8ceab82)

## After :
![image](https://github.com/user-attachments/assets/8e9fedec-3207-4c47-adbf-a98bc4f291ad)


## Steps to reproduce :
- Change the document layout to a boxed one in the Settings
- Create products with long descriptions (example can be found in the linked ticket)
- Create an invoice with the products
- Print the invoice (the total should be on the second page top)
- The vertical lines should be there

opw-4841652

Versions
--------
- 18.0+

Steps
-----
1. Set company email to the same as the admin's;
2. log in as demo user;
3. set up a sales order without a salesperson;
4. send sales order via email.

Issue
-----
Sales order shows as being sent from admin user instead of the company email. The expected behavior for sales orders is that they're sent from the salesperson email if available, else the company's email.

Cause
-----
When sending the email, it has the correct `email_formatted` value, i.e. Company Name <company@email.com>. To get the author however, `mail` uses the `_mail_find_partner_from_emails` method, which normalizes the given emails before searching matching partners.

Without the "Company Name" part, it will also match admin user's email, and because the method prioritizes user emails over partner emails, the company's `partner_id` doesn't even get checked in the lookup.

Solution
--------
Add a `_computer_authorship` override for `sale.order` messaging.

opw-4690644

**Description:**

Due to a recent [commit](https://github.com/odoo/odoo/commit/12ef230df58122fbdac0b4c1b4781c535b8516ba), a margin-top was added to the total table for the report type-pdf. Previously,in the box layout, this table did not have a top border because it appeared visually connected to the preceding table — they seemed seamlessly joined.

However, after the margin was added,the table now appears visually disconnected, making the absence of a top border look inconsistent and awkward.

Steps to reproduce:
- install account module
- select box external layout
- create invoice
- print report as pdf

Before commit:
![before-commit](https://github.com/user-attachments/assets/1fc5076c-879d-4b4e-9dfe-aa3b5a420d5e)

After commit:
![after-commit](https://github.com/user-attachments/assets/a0ec957c-7b01-45ba-8f69-05499ff5c162)


opw - [4873157](https://www.odoo.com/odoo/project/70/tasks/4873157)
upg - [2839564](https://upgrade.odoo.com/odoo/upgrade.request/2839564)


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

Issue
-----
When processing partial receipts on small resolution screens, the incomplete transfer window has an overlap of its headers for translations with long terms.

Steps to reproduce
-----
- Set DB language to French
- On Inventory>Configuration>Operation Types, configure the operation type "receipts" to create backorders on "Ask"
- Create an incoming transfer
- Open barcode on a low resolution screen (eg 340x400px)
- Open the transfer in barcode
- Process part of the quantity
- Validate the partial transfer

--> The "Terminé /" & "A faire" column headers overlap

Cause
-----
The resolution is not wide enough to fit the headers without word break. However breaking words isn't a suitable solution either as it makes headers unreadable. For example, "Terminé /" & "A faire" would read as
"Term A   "
" iné fair"
" /   e   "

Given that the 2 columns are semantically related, we can merge their headers together without losing readability.

Visual comparison
-----
Low resolution before (left) & after the fix (right).
![low_res](https://github.com/user-attachments/assets/76738e1e-a9b0-4664-a36d-d7997d1ab603)

Desktop display is a bit affected but still readable.
![desktop](https://github.com/user-attachments/assets/f3f00ce5-6e23-4c4b-8627-5c5ea840f07c)

-----
Ticket:
opw-4715939

**Steps to reproduce:**
- Install Accounting + Inventory + Sales apps
- Enable Automatic Accounting in Settings
- Ensure two companies are available
- Set one product category (same for both companies)
    - For company 1 (current) -> FIFO + automatic valuation (`'real_time'`)
    - For company 2 -> FIFO + manual valuation (`'manual_periodic'`)
- Create a storable product for this category
- From company 1:
    - Buy 10 products at 10$ each and receive them (Purchase + Delivery)
    - Sell 15 products at 10$ each and deliver them (Sale + Delivery)
    - Buy 10 products at 10$ (Purchase)
- Switch to company 2 (keep company 1 checked)
- From company 2:
    - Validate the third delivery order (WH/IN)
- Go to Inventory/Reporting/Valuation
- One journal entry is missing for the last move

**Issue:**
During the processing of the SVL in `_run_fifo_vacuum`, the product used its current env context company instead of the one provided explicitly in the parameters. This caused inconsistencies in valuation logic when the method used differed between the given companies, which results in a missing `account_move_id`.

**Fix:**
Ensure that the product is evaluated in the correct company context by using `product.with_company(company.id)` before the valuation logic.

opw-4732067

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

Forward-Port-Of: odoo/odoo#208644

**Current behavior:**
Creating a purchase order in a foreign currency and billing the
product prior to reception will produce 2 issues:
A) The bill line for the product will only make a conversion of
1 single unit of the product with the defined currency exchange
rate, making the amount on the line incorrect when qty > 1

B) When the receipt is finally validated, there will be an
unwanted exchange difference on the journal items generated due
to asymmetrical rounding for the bill AMLs and receipt valuation
AMLs

**Expected behavior:**
Correct bill line currency amounts and symmetric rounding.

**Steps to reproduce:**
1. Set the company currenct to IQD, make a product invoiced on
ordered qty, for sake of example set cost to 500 IQD

2. Create a currency exchange record to USD with a company rate
of `0.00756`

3. Create a PO for 13 of the product created in step 1, with a
discount of 1%

4. Confirm the PO and create the bill -> post it

* Issue A) look at invoice line, see only 1 unit in the
converted currency amount is accounted for by the `balance`

5) Receive the product -> look at the journal items generated
and see that there is a diff of 0.185 IQD

**Cause of the issue:**
A) commit: 90158f6 added a method to try and calculate an AML
balance from its purchase line values, but mistakenly is using
`qty_received` instead of `qty_to_invoice` which explains why
this issue only presents for the bill-before-receipt flow

B) commit: 9f046d5 is using `round=False` context for
`AccountTax.compute_all()` when the expected key is `round_base`

**Fix:**
A) Replace `qty_received or 1` with `qty_to_invoice`
* Also make the test added in 90158f6 more robust

B) Add `round_base=False` alongside the `round` key (not
removing as that existing one could have become expected in this
context)

opw-4689170

Forward-Port-Of: odoo/odoo#205850

### Description of the issue/feature this PR addresses:

When doing an Invoice B to exempts customer we have a problem the RG Legend new table is not showing: this because if the VAT Content or other taxes sum is 0.0 (we are not showing any information if sums 0.0)

After checking with ARCA Online PDF sxampels, and some feedback of Argentinen users, we found out that the Legend should be always present. event if the totals of theTax Breakdown are shown with 0.0

### Steps to reproduce

1. Go to an Argentina Company
2. Create a new invoice for "Final Consumer" with document type "Invoice B"
3. Create a product line with tax 0 (could use either VAT Exempt, VAT 0, VAT Not Taxed)
4. Print the PDF

### Current behavior before PR:

The PDF is NOT showing the Tax Breakdown table

![image](https://github.com/user-attachments/assets/94bbddc1-1dcf-4eb4-887b-2106914290df)

### Desired behavior after PR is merged:

The PDF is showing the Tax Breakdown with the line VAT Content 0.0

![image](https://github.com/user-attachments/assets/c6b8a1b6-322b-4eb7-b11e-3df8bcb3ec42)


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

Forward-Port-Of: odoo/odoo#207367

**Step to reproduce:**

1. Install l10n_ae module.
2. Create and post a customer invoice with product and Taxes.
3. Print the invoice using the Invoice PDF report.

**Issue:**

The "VAT" columns in the invoice report for AE localization are left-aligned, 
which causes a visual misalignment.

**Cause:**

The header cells for the "VAT" columns use the text-start class, which left-aligns them, 
whereas the VAT data is right-aligned.It arises because the `<th name="th_taxes">` element is 
aligned with text-end in the base view account.report_invoice_document , but it is overridden
for the l10n_ae module with text-start.
https://github.com/odoo/odoo/blob/638268a81ed5a292a02d7fc353c4954159de54e1/addons/account/views/report_invoice.xml#L116

**Solution:**

To fix this, update the alignment of the "VAT" header columns to use text-end,
ensuring consistent alignment.

opw-4863313

Before fix:
![rkth_Before_fix_Vat](https://github.com/user-attachments/assets/685785df-797c-4564-b65f-c12dda369258)

After fix:
![rkth_After_Fix_Vat](https://github.com/user-attachments/assets/db32f7a6-6299-438c-b953-6bfd8b2f508e)

Forward-Port-Of: odoo/odoo#214499

## Steps to reproduce:
- Install **Timesheets** and **payroll** apps.
- Create a copy of the (**Standard 40 hours/week**) working schedule but remove **Wednesday** working hours.
- Create a new **employee**, and set his Working Hours to the newly created working schedule.
- Create a new **_running_** **contract** for the newly created employee with the newly created working schedule.
- Go to **Timesheets** app, and search for the newly created employee.
- **Add a line** for a project and register 8 hours in each day from Monday to Saturday.
- Switch the view to Day, Notice how for both Wednesday and Saturday, no overtime is shown. +08:00 should be shown for each as both are non-working days per the newly created working schedule. **(Issue 2)**

## Investigation:
- The overtime text comes from https://github.com/odoo/enterprise/blob/1720b5578998b28c91c6820a63ecbd397297c47f/timesheet_grid/static/src/components/employee_overtime_indication/employee_overtime_indication.xml#L8 using `overtimeIndication()` getter https://github.com/odoo/enterprise/blob/1720b5578998b28c91c6820a63ecbd397297c47f/timesheet_grid/static/src/components/employee_overtime_indication/employee_overtime_indication.js#L34
- For the off days - (Wed, Sat, Sun) in our example -, the `allocated_hours` (`this.props.allocated_hours`) = ZERO
- And so `shouldShowHours()` returns `false` https://github.com/odoo/enterprise/blob/1720b5578998b28c91c6820a63ecbd397297c47f/timesheet_grid/static/src/components/employee_overtime_indication/employee_overtime_indication.js#L19-L21
- which makes `overtimeIndication()` returns null. That's why no overtime text is shown for off-days
- Note that `allocated_hours` is `undefined` for rows that represent employee hours of the current week

opw-3718279

Forward-Port-Of: odoo/enterprise#66528
Forward-Port-Of: odoo/enterprise#60048