LATAM task 1299 / Adhoc Task 47453

---

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

Update the Argentinean Legal Invoice Report regarding ARCA's new legal requirement: Tax breakdown on B2C. This only affects Factura B and related documents. Now, we will show an extra tax detail section with the title "Fiscal Transparency Regime for the Final Consumer (Law 27.743)" and show the details of the taxes grouped by type: VAT Taxes and Other National Internal Indirect Taxes.

For more info about the RG, go to https://servicioscf.afip.gob.ar/publico/sitio/contenido/novedad/ver.aspx?id=4448

### Current behavior before PR:

Old version of legal PDF report; we are not showing vat taxes, and summarying internal and national taxes on the tax totals

![before-print-detail-other-taxes](https://github.com/user-attachments/assets/2bc416c9-4231-42c4-8c71-fd1f5531d3d2)

### Desired behavior after PR is merged:

We add a special table at the end of the report (ask required in the RG) with the detail of the taxes group by type: vat taxes, and other internal and national taxes

![new-taxes](https://github.com/user-attachments/assets/d75ae2ad-b787-4399-a9d7-c6b3082c67ec)

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

Forward-Port-Of: odoo/odoo#204055
Forward-Port-Of: odoo/odoo#201257

### Steps to reproduce:

- Create a storable product tracked by serial number available from the pos and with a set pos category.
- Open a pos session and click on your product.
> A dialog openns for you to register serial numbers.
- Edit a first SN: SN001 and press enter
> A new line can now be set to create a second one.
- Edit a second SN: SN002 and press enter
- Confirm the dialog
#### > The quantity displayed on teh POS order line is 1 rather than 2.

### Cause of the issue:

Clicking on the product card from the pos will trigger a call of the `AddProductToCurrentOrder` that will add a quantity of the product set via the options:
https://github.com/odoo/odoo/blob/6197233ef1611ddd974cfdb06ae2568e4af369de/addons/point_of_sale/static/src/app/store/pos_store.js#L1965-L1978 However, the `getAddProductOptions` call sets a quantity to add of 1 no matter if you added multiple or even removed multiple registered SN. https://github.com/odoo/odoo/blob/6197233ef1611ddd974cfdb06ae2568e4af369de/addons/point_of_sale/static/src/app/store/models.js#L180 On the other hand, since at the moment of this call we do not have the info of the lines that were removed in the dialog it is not possible to always provide the correct (possibly negative) quantity to add to the line for the qty to be correctly handledby the posorder line. However, just as when you edit the line dirrectly this can be achieved by updating the quantity based on the relevant lots present on the line: https://github.com/odoo/odoo/blob/6197233ef1611ddd974cfdb06ae2568e4af369de/addons/point_of_sale/static/src/app/store/models.js#L570-L572

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

Forward-Port-Of: odoo/odoo#202887
Forward-Port-Of: odoo/odoo#199127

**Steps to reproduce:**
1. Create a company with IQD as its currency
1. Create a product with average costing and real_time accounting
2. Create an exchange rate from USD to IQD (e.g, 0.00075758 USD per IQD)
3. Create a purchase order for the product like:
    a. currency: USD
    b. price unit: 12.6
    c. qty: 6
    d. discount: 33.33%
4. Confirm the order
5. Receive the product
6. Create the bill
7. Open the journal items tree view

The credit/debit amounts of the journal entries for the reception and the invoice don't match. The `amount_currency` is the same, but there are additional exchange differences items.

The reception journal item balance is taken from the `stock.valuation.layer`.
In the example, `unit_cost` is in the company currency IQD:
https://github.com/odoo/odoo/blob/191d44c91a4578445d8cb59d3172042022cb5a9a/addons/stock_account/models/product.py#L177

The invoice's balance is computed with `amount_currency`, which is converted to USD with the exchange rate and rounded:
https://github.com/odoo/odoo/blob/4e724323d811dec76c186b5cfff6e4b0135b2128/addons/account/models/account_move_line.py#L1570

The difference between the roundings (depending on the conversion rate) may generate exchange differences that shouldn't be there.

**Fix:**
Try to prepare the AML balance while creating it from a purchase
line- we have the unrounded `price_unit_discounted` that may be
used to find an accurate balance.

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4103167)
opw-4103167

Forward-Port-Of: odoo/odoo#203386
Forward-Port-Of: odoo/odoo#190043

Currently, atraceback is occurring when the user tries to generate an e-Waybill.

To reproduce this issue:

1) Install `l10n_in_ewaybill_irn` and switch to Indian company 
2) Create a posted customer Invoice with aml containing taxes 
3) Click `Create e-Waybill` button and provide the required values. 
4) Now click on the `Generate e-Waybill` button

Error:- 
```
AttributeError: 'NoneType' object has no attribute 'get'
```

This error occurred after the refactoring was done from the commit(https://github.com/odoo/odoo/pull/191920/commits/c985becafc4a1245c441451e9ca0d2b2c4efda21)

But in the previous version an else block was there to pass and empty dict if there is no indian edi.
https://github.com/odoo/odoo/blob/eb4a03f4e00c35b74aafa16533c8c8b74004542f/addons/l10n_in_edi/models/account_move.py#L49-L52 

However after the above commit, it was removed

https://github.com/odoo/odoo/blob/3be945c89dcd1276551a855189f2d5f908908651/addons/l10n_in_edi/models/account_move.py#L156-L159 

This leads to the above traceback from the below line.
https://github.com/odoo/odoo/blob/3be945c89dcd1276551a855189f2d5f908908651/addons/l10n_in_ewaybill_irn/models/l10n_in_ewaybill.py#L45

sentry-6442414522

Forward-Port-Of: odoo/odoo#203070

Issue: In Barcode, performing certain operations and then reverting your changes can drastically affect the state of records: "picked" status or the visual demand of the move.

### Steps to reproduce:

- Create a storable product tracked by SN. Put 2 SN in stock SN1 and SN2
- Create a delivery order for 2 units and mark as to do.
> The two SN's should be reserved on your delivery.
- Go to the barcode app, scan SN1.
- Edit edit the SN1 line to set the qty back to 0.
- Leave the barcode app and come back to the record.
#### > The subline related to SN1 displays now a demand of 0. A new barcode line has been created with a demand of 1 for SN1. In short an extra record was created unecessarily.

### Cause of the issue:

In the barcode app the demand of each line is measured by the quantity present on its move lines. In our set up, the move is related to 2 moves lines with a quantity of 1 that are not picked. Scanning SN1 will update the qty_done of its line to 1. As such, the move line quantity will be set from 1 to 1 and the move line will be picked:
https://github.com/odoo/enterprise/blob/e8c831a540c12019c560cc19abf7abe8785d0e0e/stock_barcode/models/stock_move_line.py#L58-L61 In turns, the picked state of the move will be set to picked: https://github.com/odoo/odoo/blob/7bc38562f1988ba15525c04168e30c06a8f1d33c/addons/stock/models/stock_move.py#L208-L212 Now, editing the qty done of the move once more from 1 to 0 to reset the reservation will not revert the process for 2 reasons:
1. The quantity of the move line will be reset form its current value to 0, altering the demand of the barcode line to 0.
2. Even if the move line was unpicked in this process, the picked compute method of the move will never reset the picked state as the compute method can only set a True value.

We therefore end up with a picked move without any picked move line and for which one of the picked move line has a quantity of 0. Now, leaving the barcode app will launch the split_uncompleted_moves method in order to not lose the changes made to the record and since the move is picked for the wrong reason, the move will be splitted in 2 instead of escaping the split process.
https://github.com/odoo/enterprise/blob/e8c831a540c12019c560cc19abf7abe8785d0e0e/stock_barcode/models/stock_move.py#L21-L22

Enterprise: https://github.com/odoo/enterprise/pull/80675

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

Forward-Port-Of: odoo/odoo#202882
Forward-Port-Of: odoo/odoo#200167

Issue: In Barcode, performing certain operations and then reverting your changes can drastically affect the state of records: "picked" status or the visual demand of the move.

### Steps to reproduce:

- Create a storable product tracked by SN. Put 2 SN in stock SN1 and SN2
- Create a delivery order for 2 units and mark as to do.
> The two SN's should be reserved on your delivery.
- Go to the barcode app, scan SN1.
- Edit edit the SN1 line to set the qty back to 0.
- Leave the barcode app and come back to the record.
#### > The subline related to SN1 displays now a demand of 0. A new barcode line has been created with a demand of 1 for SN1. In short an extra record was created unecessarily.

### Cause of the issue:

In the barcode app the demand of each line is measured by the quantity present on its move lines. In our set up, the move is related to 2 moves lines with a quantity of 1 that are not picked. Scanning SN1 will update the qty_done of its line to 1. As such, the move line quantity will be set from 1 to 1 and the move line will be picked:
https://github.com/odoo/enterprise/blob/e8c831a540c12019c560cc19abf7abe8785d0e0e/stock_barcode/models/stock_move_line.py#L58-L61 In turns, the picked state of the move will be set to picked: https://github.com/odoo/odoo/blob/7bc38562f1988ba15525c04168e30c06a8f1d33c/addons/stock/models/stock_move.py#L208-L212 Now, editing the qty done of the move once more from 1 to 0 to reset the reservation will not revert the process for 2 reasons: 
1. The quantity of the move line will be reset form its current value to 0, altering the demand of the barcode line to 0.
2. Even if the move line was unpicked in this process, the picked compute method of the move will never reset the picked state as the compute method can only set a True value.

We therefore end up with a picked move without any picked move line and for which one of the picked move line has a quantity of 0. Now, leaving the barcode app will launch the split_uncompleted_moves method in order to not lose the changes made to the record and since the move is picked for the wrong reason, the move will be splitted in 2 instead of escaping the split process.
https://github.com/odoo/enterprise/blob/e8c831a540c12019c560cc19abf7abe8785d0e0e/stock_barcode/models/stock_move.py#L21-L22

Community: https://github.com/odoo/odoo/pull/200167

opw-4600565

Forward-Port-Of: odoo/enterprise#82065
Forward-Port-Of: odoo/enterprise#80675

This module implements issueing NFC-e receipts through the POS. The process is conceptually similar to what we do for invoices. First taxes are calculated, and then we e-invoice.

The calculated taxes will never change the order total. NFC-e mandates taxes to always be included in the price so we don't need any additional RPC call before payment.

One way of achieving this was through l10n_br_edi, forcing every pos.order to be invoiced and then following the implemented flows on account.move. We decided against it because:

- It leads to a large amount of mostly unnecessary invoices,
- It's conceptually strange to the user, NFC-e "invoices" resemble POS receipts more than they do invoices,
- The flow in the POS is simpler, we handle tax calculation and EDI in one atomic step.

We therefore chose to re-implement EDI for pos.order. The downside of this approach is that we temporarily need to copy some code from l10n_br_edi. In master this code can be consolidated in a common mixin.

The integration tries to never block POS sales. You're allowed to retry EDI later. When EDI fails, the POS user is informed and we fall back to the standard receipt (marked as a "receipt without fiscal value").

For refunds we still go through account.move, as NFC-e doesn't support refunds (must be NF-e, which is what we already support for account.move).

task-3564171

Forward-Port-Of: odoo/enterprise#81796
Forward-Port-Of: odoo/enterprise#77206