Issue:
---
Due to this issue, generating PDF Quote using Quote Builder leads to traceback.

Steps to reproduce:
---
1- Using a python 3.13 env, install requirements.txt. (You could instead uninstall pypdf2 and install pypdf==5.4.0)
2- Enable Quote Builder.
3- Create a SO and in quite builder tab, select a document.
4- Print -> PDF Quote.

This will lead to traceback.

Cause:
---
There is a requirement change on https://github.com/odoo/odoo/pull/233600, as pypdf2 will not be
supported in future. Instead we use pypdf==5.4.0.

In pypdf 5.4.0 it is required to have `Fields` present in `Acro Form` (introduced in [1] v3.13.0):
https://github.com/py-pdf/pypdf/blame/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/_writer.py#L1060-L1061

FIX:
---
We could add an empty `fields` dictionary when it's not present. The entry should be `/Fields`:
https://github.com/py-pdf/pypdf/blob/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/constants.py#L362-L370

Note:
---
In this fix, we replace `is_upper_version_pypdf2` with specific version comparison.
To be precise `getNumPages` is depreciated in version 1.28.0 [2].

References:
---
[1]- https://github.com/py-pdf/pypdf/commit/dcf997a028e993b215457c5629cb4e78186e11c0
[2]- https://github.com/py-pdf/pypdf/blob/3ab1581a51f446f86dd445662005f8747941c2b6/pypdf/_writer.py#L507-L514

opw-5784464

… request

ARCA requires numeric fields such as unit price and quantity to have a maximum of 12 integer digits and 6 decimal places. If these fields are sent with more than 6 decimals, AFIP rejects the invoice with errors like:
`Code 1814: Campo Cmp.Items.Pro_precio_uni invalido. El valor debe tener 12 enteros y 6 decimales como máximo.`

To ensure compliance, values are formatted before sending the request to ARCA.

**Precision rationale**
ARCA WS documentation mentions 4 decimal places, while the WS error message itself refers to 6 decimals, and in practice the service accepts up to 6 decimals without rejection.

In this implementation, we intentionally use 2 decimal places. The reason is consistency with the rest of the monetary amounts in the invoice: line totals, invoice total, taxes, and related amounts are all rounded to 2 decimals, even in cases where the documentation allows higher precision (e.g., 3 decimals).

Before the changes in rounding precision, the stable version already rounded values according to line rounding. In real-world accounting scenarios, the vast majority of use cases operate with 2 decimal places. Keeping this behavior ensures consistency across calculations and avoids discrepancies caused by mixed rounding strategies.

For a stable release, this was considered the safest and most predictable option, even though the WS technically allows higher precision.

Stable version changes are covered in the following commits:
https://github.com/odoo/odoo/pull/243987/changes/8a21ec45f9d72a7c80d9c1f8398fe01e298ae775
https://github.com/odoo/odoo/pull/246347/changes/79ceeed707ef274f19a04e741f6cb8ac60c44321


<img width="780" height="435" alt="image" src="https://github.com/user-attachments/assets/9f25a0e8-b9d2-4ad2-bbcf-e988c7f8a4c9" />

[WSFEX - Manual de desarrollador](https://www.afip.gob.ar/ws/WSFEX/WSFEX-Manualparaeldesarrollador.pdf)

**Issue**
Lots manually indicated on stock move lines can be overridden when producing a
Manufacturing Order.

**Steps to reproduce**
- Create a storable product P tracked by lot
- Create two lots for product P with 2 units each
- Create a MO for a product consuming two units P and confirm it
- On the raw move, manually set 1 unit for each lot
- Click on "Produce All"
- Check the move line associated to the product P
-> 2 units associated to the first lot consumed instead of 1 unit each

**Cause**
While producing:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2109-L2110
It sets the quantities:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2246
This calls `_set_quantity_done_prepare_vals` with a qty of 2:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2264
which will, for each move line:
- Take the quantity indicated by move line:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2274
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2296-L2297
- Then take all the available quantity left for the lot associated to the move line:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2302-L2309
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2326-L2327

Instead of first taking all the quantity indicated by the move line, before checking available quantity

opw-5946439

Step to reproduce:
- Install point_of_sale
- Enable Identify Customer on the Card payment method
- Create an order with a customer and refund it
- Use Card as the payment method
- Close the POS session
- Go to Invoicing → Customers → Payments

Observation:
- Two payment records are created
- Both payments have payment_type = inbound
- The refund payment should be outbound

Cause:
- When Identify Customer is enabled, `_create_split_account_payment` is used to create payment records
- The method does not adjust payment_type for refund transactions

Fix:
- Add helpers to swap destination and outstanding accounts
- Set `force_outstanding_account_id` instead of `outstanding_account_id`, as the former has priority
- Ensure refund payments are created as `outbound`

few related fix: https://github.com/odoo/odoo/commit/303a9061da85048f14a3ca7b1e13df0ab34da99e
https://github.com/odoo/odoo/commit/718fac6832ecd343bf26d41fa5ae5b1ab74f4228
https://github.com/odoo/odoo/commit/684415b9ff2e151506da561016dbfa991bfa8dc8

opw-5437456


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