Currently, when a user deletes a line and validates internal movement in the barcode system, the system allows validation even though specifying the destination location after each scan is required.

## Steps to produce:
- Install the Inventory module
- Go to Settings and enable Storage Locations.
- Inventory > Configuration > Operation Types > Internal Transfers > Barcode App
- Configure the Destination Location to require scanning after each product.
- Create an Internal Transfer for Pedal Bin, demand 1.
- Mark the transfer as To Do and open it in the Barcode app.
- Add quantity using +1, then scan the barcode for the Pedal Bin(Barcode: 6016478556493).
- Delete the newly added line and attempt to Validate.

## Observed Behavior:
The system should prevent transfer validation when the destination location has not been scanned and display a notification to the user, similar to the behavior before user deleted the newly added line.

## Root cause:
This issue occurs because when the delete button is pressed, the deleteLine function [1] removes the line, but the deleted line becomes the selected line due to [2] being triggered before the UI updates.

As a result, the selected line is now undefined. Since the selected line is undefined, it fails to meet the condition at [3] during validation. This prevents notifications from being triggered and allows the transfer to be validated before the destination location has been scanned.
[1]:
https://github.com/odoo/enterprise/blob/3476d15bf8e75eb6530658dd623861b60963ab40/stock_barcode/static/src/models/barcode_model.js#L826-L836 [2] :
https://github.com/odoo/enterprise/blob/327d4478128f33fb2e0c477533bd4983178abf17/stock_barcode/static/src/components/line.js#L129-L133 [3]:
https://github.com/odoo/enterprise/blob/6ff158ca3a6d2d2b3d285a7f8317622844811688/stock_barcode/static/src/models/barcode_picking_model.js#L945-L948

## Solution:
We can prevent users from validating if any line has an unscanned destination location when destination-location scanning is mandatory after scanning each product.

To enforce this behavior, we can track whether a line has been modified and whether a destination location has been scanned and applied to that line. This allows us to identify which lines still require destination location scanning before validation can proceed.

However, line state information is currently discarded and recreated on every save. As a result, information about lines that were updated and already had their destination location scanned is lost. This may incorrectly require users to rescan the destination location, even though it was previously scanned.

To address this, we preserve the destination-scanned and modified state by carrying it forward from existing lines to their corresponding newly created versions using a loop. This ensures that destination location scan status is retained and users are not asked to rescan unnecessarily.

opw-6069614

Issue:
After manually modifying the taxes on a vendor bill that generates COGS lines, confirming the vendor bill causes the taxes to revert to their original values before the manual edit. This happens because the product’s purchase taxes are applied to the generated COGS lines, which triggers the tax recomputation logic and overwrites the manually adjusted tax amounts. However, COGS lines represent internal operations and should not have taxes applied to them

Steps to reproduce:
1. Turn on Anglo-Saxon accounting
2. Turn on automatic accounting
3. Make a FIFO product category and make the valuation automatic
4. Make a new product and set the FIFO product category on it
5. Make sure the product has a vendor tax set
6. Make a purchase order for 10 of the FIFO product category at $10
7. Create and validate the receipt for 10
8. Make a sales order for 6 of the FIFO product category at $10
9. Create and validate the delivery for 6
10. Create the vendor bill for 10 the purchase order created above (make sure that there is a tax set on the vendor bill; the vendor tax that was set on the product). Make this vendor bill set for 10 at $20
11. Edit the tax at the bottom of the total
12. Confirm the vendor bill
13. Notice that the tax at the bottom of the total changes
14. Reset the vendor bill
15. Remove the purchase tax from the product
16. Confirm the vendor bill again and notice that the tax at the bottom of the total does not change this time

Cause:
On confirmation, the COGS lines on the vendor bill will be generated and “_compute_tax_ids” will be triggered on those lines. Since COGS lines have a “product_id” set on them, those lines will receive the purchase tax set on the product. Setting the “tax_ids” on those COGS lines will cause tax computation to trigger again, which will reset the manually edited tax amount to the new computed amount. However, since COGS lines come in pairs that are equal and opposite in amount, the taxes from both COGS lines will cancel out, and the new computed tax amount does not change

Solution:
Skip setting the purchase taxes of the product onto COGS lines in “_compute_tax_ids”

opw-6110692

Forward-Port-Of: odoo/odoo#265352