Accounting reports now handle journal filters more accurately when multi-ledgers are used across multiple companies. Users can include journals from all companies while excluding only those specifically blocked by a ledger, and ledgers can also be made visible to all companies.

Improve journal filters on accounting reports, particularly when multi-ledgers are used. Following changes from the community PR, multi-ledgers can now exclude journals from different companies. The company_id field now only indicates which company can view the multi-ledger in the filters.

When a multi-ledger is selected, all journals from all companies are included, except those explicitly excluded by the ledger. Additionally, a ledger can be made visible to all companies.

task-4141521

Thread action buttons in messaging-related screens have been visually improved for a clearer, more consistent experience. This helps users interact with discussions, knowledge threads, and WhatsApp conversations more easily without changing the underlying workflow.

https://github.com/odoo/odoo/pull/178865

This change restores timesheet billing targets from percentages back to billable hours, making it easier for managers to see whether employees are meeting yearly expectations. It also adjusts leaderboard and reporting views so performance is measured against each employee's billable time target rather than their working calendar.

This commit will revert odoo#54238, because the changes introduced in this PR makes it difficult for the manager/team leader to know if the mployees in his team reached the yearly target.

- Revert "billing_rate_target" (in %) to "billable_time_target" (in hours)
- Revert the computation of the billable rate in the leaderboard from using the employee's working calendar to using the employee's billable time target

task-4122708

The calculation of amounts still to invoice now follows each sales order line instead of the full order total. This keeps credit limit checks aligned with how Sales considers orders completed, avoiding misleading outstanding balances after price changes or down payments.

In 16.2, the amount to invoice was introduced to effectively compute the total receivable of a partner.
The goal was to take into account the confirmed SOs that are not invoiced yet, in order to trigger the partner's credit limit warning.
Since then:
- The total receivable of a partner = unpaid posted invoices + SOs amount to invoice.
- Where the amount to invoice = SO total - confirmed down payments.

The issue with that method is that we go against the Sales philosophy, which considers that a SOL (Sales Order Line) is invoiced as soon as the invoiced quantity (whatever the invoice status) equals the ordered quantity.
That can lead to incoherent situations.
For example:
Let's imagine a SO with 2 products:
- 3 desks at €100
- 5 chairs at €50.

We invoice 3 desks at 90€ because of a price change and 5 chairs at 50€.
Sales will consider the SO to be done ("nothing to invoice"), whereas Accounting consider that there's still €30 to invoice.
The bottom line is that:
- We should consider the amount to invoice per SOL and not per SO total.
- We should remain consistent with the Sales methodology, to avoid weird cases as demonstrated before.

task-3764582

When invoice scanning cannot match an existing partner, the partner creation form now opens with more suggested details already filled in. This can save time and reduce manual entry by using extracted information such as contact details, tax number, country, and bank information.

With this change if a partner is not found using the ocr, the user when opening up the partner creation form will receive additional default values. The fields that can be added are: phone, mobile, website, email, vat number, country and bank details.

Task-3818879