Due to more number of moves during compute it out of memory while getting the country_code per move. So, just pre fetch the country code. So, it won't go for computing that and will be available in memory

records
```
sagu_3267671=> select count(id) from account_move;
  count
---------
 1034179
(1 row)
```

```
File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 102, in determine
return needle(*args)
File "/home/odoo/src/odoo/17.0/addons/l10n_rs_edi/models/account_move.py", line 85, in _compute_l10n_rs_edi_is_eligible
move.l10n_rs_edi_is_eligible = move.country_code == 'RS' and move.is_sale_document() and move.l10n_rs_edi_state in (False, 'sending_failed')
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1219, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1401, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 105, in determine
return needle(records, *args)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in _compute_related
values = [first(value[name]) for value in values]
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in <listcomp>
values = [first(value[name]) for value in values]
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6695, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 2933, in __get__
return super().__get__(records, owner)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1182, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3824, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3874, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3984, in _fetch_query
self.env.cache.insert_missing(fetched, field, values)
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 1135, in insert_missing
field_cache.setdefault(id_, val)
MemoryError
```

upg-3267671
opw-5246681


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

Forward-Port-Of: odoo/odoo#235919

### Issue:
When sending an invoice and creating CFE, we fail to retrieve the PDFs generated by Uruway.

### Steps to reproduce:
- Install 'l10n_uy_edi' and switch to an Uruguayan company
- In the Settings change 'UCFE Web Services' to 'Testing' and input credentials
- Create a new invoice, confirm and send, click 'Generate CFE'
- The CFE status is accepted but the PDF from Uruware is not on the record

### Cause:
This [commit](https://github.com/odoo/enterprise/commit/726ebfe7c6266b7e54d8b2716983e62eb3142a81) changed how `l10n_latam_document_number` is computed: it's no longer related to `move_id.l10n_latam_document_number` but computed when `move_id` is set.

In our case `move_id.l10n_latam_document_number` is [set in `_l10n_uy_edi_send()`](https://github.com/odoo/enterprise/blob/f8ac53cb6e6578a43780e07b6133fa09bdee8dbb/l10n_uy_edi/models/account_move.py#L837-L839) but as `move_id` is not changed, the compute is not triggered and the field of the document is not the same.

Later in `_get_pdf()` we use `self.l10n_latam_document_number` to retrieve the PDF from Uruware ([see](https://github.com/odoo/enterprise/blob/f8ac53cb6e6578a43780e07b6133fa09bdee8dbb/l10n_uy_edi/models/l10n_uy_edi_document.py#L240)).

### Solution:
We need to keep the fields coherent with either `move_id` or `picking_id`. To do this we add the fields of the linked redord in `depends`.

opw-5272776

Forward-Port-Of: odoo/enterprise#100128

**Problem:**
when selling a product valued by lot
and chosing a lot with a value of 0
the average value of the product
is used instead of 0.

**Steps to reproduce:**
- make sure your warehouse is in single step receipt and delivery
- create a product tracked by lot and valued by lot
- set the category as avco
- create a PO for a quantity of 10 and a unit price of 10
- confirm and open the receipt
- open the stock move widget on the stock move
- write "lot A" in the lot column and save
- validate
- create a PO for a quantity of 10 and a unit price of 0
- confirm and open the receipt
- open the stock move widget on the stock move
- write "lot B" in the lot column and save
- validate
- create a quotation for 1 quantity of your product
- confirm
- open the delivery
- open the stock move widget on the stock move
- in the 'pick from' column enter lot B and save
- validate
- open the valuation smart button

**Current behavior:**
the value of the stock valuation layer is -5

**Expected behavior:**
it should be 0

**Cause of the issue:**
Inside _prepare_out_svl_vals
lot.standard_price is 0 so the if condition
is false and we don't use the price of the lot
https://github.com/odoo/odoo/blob/cd2a241182cf56fc36d03df9f0afdcea30f682d2/addons/stock_account/models/product.py#L277

**fix:**
    deleting the lot.standard_price condition
    is not possible because when the lot is created
    at delivery it has no standard_price and in this
    case we want to use the standard_price of the
    product.
    (see test https://github.com/odoo/odoo/blob/d3835668349d466ed4ba27c9eacdbd3339f2ac37/addons/stock_account/tests/test_lot_valuation.py#L58)

opw-5077671

Forward-Port-Of: odoo/odoo#234764

Before this commit:
-------------------------
- On the Purchase Dashboard, the 'Not Acknowledged' and 'Late Receipt' counters
  also included purchase orders whose receipts had already been done.
- For Not Acknowledged:
  - Such POs should be implicitly considered acknowledged once their receipts
    are done, but they were still shown at the counter.
  - Additionally, unacknowledged POs that were locked were incorrectly excluded
    from the counter.
- For Late Receipt:
  - POs with received products were incorrectly counted as late, even
    though their receipts were already done.
  - Locked POs with late receipts were also excluded from the counter, which was
    an incorrect behavior.

Steps to reproduce:
-------------------------
1. Install the 'purchase_stock' module.
2. Open Purchase module.
3. On the Purchase Dashboard, click on the 'Not Acknowledged' or 'Late
   Receipt' card.
4. Notice that POs whose receipts are already completed still appear in the
   counters and some locked POs that are unacknowledged or have late receipts
   are missing from the counters

Cause of the issue
-------------------------
- The domains for both Not Acknowledged and Late Receipt counters only relied on
  the purchase order state without checking whether the receipts were done.
- As a result, POs with done receipts were still included in the counters, while
  some locked POs were incorrectly excluded.

After this commit:
-----------------------
- Updated the search domains for both counters to properly exclude POs whose
  receipts are done.
- The action_done method now triggers action_acknowledged, ensuring that any
  unacknowledged POs with completed receipts are automatically marked as
  acknowledged and excluded from the Not Acknowledged counter. Locked POs that
  remain unacknowledged will still correctly appear in the counter.
- Now the POs with received products are no longer shown as late once their
  receipts are completed and Locked POs with late receipts will now correctly
  continue to appear in the counter.
- This ensures that the dashboard accurately reflects only pending
  acknowledgments and genuinely late receipts, helping users track POs in
  the correct state.

Task ID: 4874116

Forward-Port-Of: odoo/odoo#224180

It may occur that when using 'Set Account' to reconcile a bank statement the reconciliation fail due to error "The operation cannot be completed: A reconciliation model already bears this name"

Steps to reproduce:

1. Create a current liability, reconciliable account "455010 My Account"
2. Create 2+ with a common labels (TEST RECONCILIATION)
3. Use "Set Account" button to reconcile the first transaction with account 455010.
4. Repeat 2-3 with a shorter label
5. Open Reconciliation models for the Journal and delete the one named "455010 My Account"
6. Repeat 2-3 with an even shorted label

Issue:

Reconciliation will be blocked by error during automatic creation of reconciliation model

Analysis:

It occurs because we don't take into account that old reconciliation models may have been deleted, so even if we count a singe record it may have already been labeled "<account_name> (1)"
Improved the naming by looking at the existing models and increasing the counter if necessary

opw-5184696

Issue
-----
In 3step manufacturing, changing the pre-prod -> prod rule to MTSO doesn't have the expected behaviour. That is, if there is an insufficient quantity of component present in pre-prod, updating the producing qty doesn't update the replenishment quantity.

Steps to reproduce
-----
- Enable warehouses and multi-step routes
- Set warehouse manufacturing to 3 step
- Edit the 3 step production route
	- Change the pre-prod -> prod rule to mts else mto
- Create a product "Comp"
	- Set a quantity of 5 in location pre-prod
- Create a product "Prod"
	- Add a BoM with "Comp" as component
- Create a MO for 10 of Prod
- Confirm MO
> There is a transfer stock -> pre-prod for 5 of Comp
- Open the production quantity wizard, update value to 12 and confirm
> The transfer still shows 5 of Comp instead of the needed 7

Cause
-----
Changing the production quantity updates the raw moves of the MO. This triggers a write on the move with the new `product_uom_qty` so we do a `run_procurement`

https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L481-L485

Before actually running any procurement we do

https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L492

Since the procurement group's method is `mts_else_mto`, when we go through

https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_move.py#L2329-L2332

we go into the `else` part and set the move's `procure_method` to mts.

This means that, in the `run_procurement` method

https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L504

is not true, so we don't add any procurement to run.

Solution
-----
In `_adjust_procure_method` we update the move's rule to the MTSO one we found

https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_move.py#L2328

This means that we can update the check in `run_procurement` to also add a procurement to run if the move's rule is MTSO.

-----
Ticket:
opw-5008871

Forward-Port-Of: odoo/odoo#235125