Versions
--------
- 16.0
- 17.0
- 18.0

Steps
-----
1. Have a product that cannot be sold out of stock (but is in stock);
2. have a confirmed sales order for a portal user with said product;
3. as portal user, add the product to your cart;
4. go to My Account / Your Orders;
5. open the confirmed sales order;
6. click Order Again.

Issue
-----
The cart that was opened by the portal user now has OdooBot as Customer.

Cause
-----
The `_document_check_access` method returns a sale order record with `SUPERUSER_ID` in its env[^1]. Meanwhile, the `website.sale_get_order` method checks the current user's partner, and if it's different from the order's partner, it gets reassigned, assuming an address change[^2].

[^1]: https://github.com/odoo/odoo/blob/9eb0b12/addons/portal/controllers/portal.py#L439-L459
[^2]: https://github.com/odoo/odoo/blob/9eb0b12/addons/website_sale/models/website.py#L386-L404

Because `SUPERUSER_ID` is the user in the environment, the order's partner gets changed to OdooBot.

Solution
--------
After `_document_check_access`, add the request's user to the record's env.

opw-5097915

Forward-Port-Of: odoo/odoo#233204

Currently when users change the rounding unit filter in the Journal Report, the Global Tax Summary values remain in the old format instead of updating to reflect the new rounding setting. This creates inconsistency where main report values update correctly but tax summary values stay unchanged.

Cause:
- The issue occurs because `_format_column_values` method in `account_report.py` wasn't handling the special tax summary data structures (`tax_report_lines` and `tax_grid_summary_lines`) that store pre-formatted values. These structures need to be reformatted when rounding unit changes, but the formatting logic only covered standard report columns.

Fix Applied:
- Updated frontend (`filters.js`) to call `format_column_values_from_client` via
  `dispatch_report_action` instead of calling `format_column_values` directly.
  (this enables proper routing through the custom handler system)
- Added `format_column_values_from_client` override in `JournalReportCustomHandler`
  that intercepts the formatting call and applies special handling for tax summary
  lines by adding logic to reformat `tax_report_lines` and `tax_grid_summary_lines`
  monetary fields using their `_no_format` counterparts.
- The custom handler then delegates to the base method via
  `report.format_column_values_from_client()` to format standard columns.
- Also added missing `_no_format` fields in `account_journal_report.py` for
  `base_amount` and `tax_amount` to enable proper reformatting.

Co-authored-by: Katherine Zaoral <zaoral@users.noreply.github.com>

THE FIX COMES FROM: 37faec2f38c9658a0f491c72f284908dc929fa17
ORIGINAL PR: https://github.com/odoo/odoo/pull/205430

Description of the issue/feature this PR addresses: 
- In debit notes wizards: If we make a wrong credit note and we want to correct it we must generate a debit note related to it. Currently odoo only allows to generate debit notes from an invoice.

Steps to reproduce the error.
- Install the Argentine localization
- Create an invoice and post it
- From the invoice using the wizard create a credit note and post it. From the credit note open the wizard to create a debit note. 
On submit the wizard we obtain an exception "You can not use a credit_note document type with a invoice" This happens because the debit note wizard use copy method without change the l10n_latam_document_type_id value.

Current behavior before PR:
When creating a debit note from a credit note get an error.

Desired behavior after PR is merged:
We can create a debit memo from a credit note.

opw-4304256

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