This PR aims to improve the way we create NomItem and DscItem lines on the XML files we send to DGI in order to generate the PDF report.

We have two fields to inform to DGI in an electronic invoice, NomItem which is mandatory an has a maximum of 80 characters to send, and DscItem that is optional an has a limit of 1000 chars. So we ensure NomItem is always sent, and the description will be filled like this:

First, if the product name is longer than 80 chars, DscItem field will contain the characters that didn't fit in the NomItem field (characters from the 80th)
Then it will contain the description of the product and the addenda content if it exists.
Plus, I refactor the method _l10n_uy_edi_cfe_D_global_discount so it is also aligned with what I mentioned before.

Another reason for this improvement is that, as the description of a product contains the product name at the beginning, we faced some issues when a user added a description on the fly in the line of the product, and then confirmed and printed the report. In this case, the name of the product was duplicated in the report. With this change, the description will only contain the the part of the product name that exceeds the 80th character.
Example:
![image](https://github.com/user-attachments/assets/60966bf9-8d24-4719-b369-a51e6ddc0baa)

Forward-Port-Of: odoo/enterprise#80993

### Background
In https://github.com/odoo/enterprise/pull/85026 we changed the behaviour of `l10n_mx_edi_post_time` so that it gets set during the CFDI sending process, rather than when the invoice is posted.

This was needed to ensure that the post time both reflects the sending time and is re-used if the invoice needs to be re-sent.

### Bug description
Since then, several Mexican customers have reported that some CFDIs are sent duplicated, with a difference of a few seconds in the CFDI's Fecha.

### Analysis
A disconnection might occur during sending of the CFDI. In that case, the PAC will process the CFDI, but in Odoo the transaction will be rolled back, and the `l10n_mx_edi_post_time` will be lost. When Odoo re-sends the CFDI, it will take a new `l10n_mx_edi_post_time`.

### Solution
Commit before performing the API call so that the `l10n_mx_edi_post_time` gets committed to DB.

opw-4780096

Forward-Port-Of: odoo/enterprise#89263
Forward-Port-Of: odoo/enterprise#89117

When the OCR parses documents from the same supplier concurrently, it can happen that it creates duplicated `res.partner` entry for it. This typically happen when the update of the documents is done through the webhook.
In that case, the different SQL transactions overlap each other and can't "see" the partner created by another request.

In order to prevent this, a new field `is_created_by_ocr` and a unique index are introduced to be able to detect duplicated partners created by the OCR.

This solution is quite costly as it requires introducing a new field and an index on `res.partner`...
Other alternatives were considered:
- Updating the documents through a cron instead -> introduces latency, especially on the SaaS where we can't force a cron to run immediately, even with a cron trigger.
- Introducing a new model on which we could add the uniqueness model -> also costly, requires a new model just to fix the issue, and we need a way to frequently clean the records, so probably a cron on top of it (or using autovacuum, but its frequency might be too low).
- Adding random delay on OCR side before calling the webhook -> introduces latency and no guarantee, it only reduces the chances of duplicated partners.
- Using explicit SQL locks -> no guarantee, we only know what should be locked late in the SQL transaction (after fetching the results from the OCR), it wouldn't be very effective. Locking the whole `res_partner` table from the start of the transaction would be too restrictive and equivalent to serializing the transactions. An attempt was made in #88830, but it was deemed too complicated.

task-[4904333](https://www.odoo.com/odoo/project/2068/tasks/4904333)

Issue: 
When [currentOrder](https://github.com/odoo/odoo/blob/a43ef8e15f4e0ee28bdb1975a8a359d3373e8d2c/addons/pos_self_order/static/src/app/self_order_service.js#L377) evaluates orders, it returns an order only if it's in  'draft' state or 'paid' with zero amount in kiosk mode.

https://github.com/odoo/odoo/blob/a43ef8e15f4e0ee28bdb1975a8a359d3373e8d2c/addons/pos_self_order/static/src/app/self_order_service.js#L377-L386

If self_ordering_mode is not 'kiosk' (e.g., 'mobile'), such orders do not match the filter. 
(Note: 0 priced orders are considered as 'paid')

if order is not found (because it didn't pass the filter), a new order is created and returned
https://github.com/odoo/odoo/blob/a43ef8e15f4e0ee28bdb1975a8a359d3373e8d2c/addons/pos_self_order/static/src/app/self_order_service.js#L393-L412
and the original order context— like access_token and tracking_number—is lost in new order, raising a traceback.

Steps to reproduce:
- Enable the self-ordering for a POS Restaurant
- change the price of a product available for self-ordering to 0
- open the self-ordering and just order the product

FIx:
As this is a corner  case, concerning, 0 priced orders from `mobile` mode, we return the original order in this case, else return the current order

Note: 
- A [fix](https://github.com/odoo/odoo/commit/9f1441cc43c951356dc1a48555621c326a5be8f2
) was applied for this exact issue, but it gradully got removed later in other PRs.
 [here](https://github.com/odoo/odoo/pull/192874/files#diff-0c985bf4d5fc0f1d25c9014209f090dd09727488ec15ca71897986119d49d5bfL366) and [here](https://github.com/odoo/odoo/pull/197569/files#diff-0c985bf4d5fc0f1d25c9014209f090dd09727488ec15ca71897986119d49d5bfL706-R640)
- issue only in 18.0

opw-4677724




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

…ating

**Steps to reproduce:**
- Inside Settings/Sales activate the "Product Packagings" setting
- Create a new product (the final product)
- Inside the inventory tab add a packaging line for a pack of 9 units
- Create a new product (the comp product)
- In the general information tab, set a unit of mesure of g
- In the inventory tab add a packaging line for a pack of 0.9 g
- Set an on hand quantity for the comp product
- Create a new BOM for the final product
- Add a a line with the comp product for a quantity of 0.1 g
- Select kit
- Create a new quotation and select your kit product
- Select your packaging > Confirm
- Click on the delivery smart button
- print without validating

**Current behavior:**
traceback with error message :
"The unit of measure g defined on the order line
doesn't belong to the same category as the unit
of measure Units defined on the product."

**Cause of the issue:**
https://github.com/odoo/odoo/blob/57282becdeab5cdd7f581e149dede683fc352abe/addons/stock/models/stock_move_line.py#L136 line.move_id.product_packaging_id is the packaging of the final product whose uom is unit.
ine.product_uom_id is grams so _compute_quantity will fail

**fix**
the fix is a backport of https://github.com/odoo/odoo/pull/201580 with an adaptation of the filtering so that the lines where the packaging was changed on the line to a packaging of the component are sent to super (it otherwise results in a wrong quantity computation)

related to opw-4781180

Forward-Port-Of: odoo/odoo#214814

### Issue:
When having two lines on an invoice with the same tax and different analytic distribution, the base value is doubled on the tax report.

### Steps to reproduce:
- Create a new tax on sales (eg 10%)
- Make sure the option "Analytic Accounting" is ticked in the settings
- Create an invoice with two lines (eg both at $100), add the tax on both
- Change the analytic distribution on both lines to different values
- Confirm the invoice
- Go to the tax report
- Select the report "Group By: Account > Tax"
- On the report the "Net" amount is doubled ($400), the tax amount is correct ($20)

### Cause:
On the invoice we can see in "Journal Items" that two tax lines are created instead of one (one for each analytic distribution).

The "Group By" reports are generated by [this query](https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/account/models/account_move_line_tax_details.py#L92).  At the [creation of the second subtable](https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/account/models/account_move_line_tax_details.py#L164-L198) the move lines are linked together based among other things on the tax id. The [filter on analytic distribution](https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/account/models/account_move_line_tax_details.py#L187-L191) does not apply here as `tax.analytic = False`. The result is that each tax line is linked with both base lines. The second subtable have 4 lines in this case, with each base line doubled.

The result of the query have the base amount doubled.

### Solution:
We cannot fix the query as there is no link to find the tax line origin among the base lines.

The method `_read_generic_tax_report_amounts` in `account_reports` is made to fix the base values in report in case of duplicate. Until now, it did not include the duplication caused by analytic distribution but duplication because of repartition lines for example.

The fix is to use this method also for analytic distribution. So we add `tdr.analytic_distribution` in the `GROUP BY`. This value must be returned by the query in `account` so we add it.

opw-4753676

Forward-Port-Of: odoo/odoo#213751

**Issue**:
When multiple invoices with different customer languages are sent and printed together, the invoice email button may appear with an incorrect translation for some of them.

**Steps to reproduce**:
- Open the Accounting app
- Go to Customers > invoices
- Create a new invoice with a customer with its language set to German
- Create a new invoice with a customer with its language set to English
- Go back to Customers > invoices
- Select the two invoices just created and click on action > Sent & Print and then click on the Sent & Print button
- Go to Settings > Technical > Email > Emails and check the two last emails. One of them should have the invoice email button wrongly translated

**Cause**:
Before sending an email, it retrieve the `type_name` using the lang of the customer https://github.com/odoo/odoo/blob/28c3b9cf10488536dce5a4927fdbe8fcd6e5a839/addons/account/wizard/account_move_send.py#L596C1-L605C14

This will trigger that compute method
https://github.com/odoo/odoo/blob/a6368e8a5787f3067d09d79516a2924b3f1207f0/addons/account/models/account_move.py#L841C1-L850C67

which set the `type_name` of all the records. Since the compute method only depends on move_type, it does not recompute type_name per record. As a result, all records may share the same type_name, regardless of language context. Please notice that `type_name` is used to display the invoice email button in the right language. 

**Solution**:
Make the compute method `_compute_type_name` depending to the lang parameter, thus it will use the right `type_name` for each email to send.

opw-4748741

Forward-Port-Of: odoo/odoo#216811

# How to reproduce the issue

- Create an invoice with price 1000 in a non-company currency (e.g., CHF).
- Modify the currency rate after the invoice date, then generate the payment for this invoice.
- This will generate three journal entries (invoice, payment, and currency exchange difference).
- Export those journal entries and include in the export the `matching_number`, `currency`, and `amount_currency` fields.
- Import those three entries with the matching number and post them.
- In the Journal Items, the line corresponding to the currency exchange difference is not matched with the lines from the invoice and the payment, leading to an unbalanced credit and debit.

# Cause

In `_prepare_reconciliation_single_partial` within `account_move_line`, the reconciliation is stopped by checking whether the debit/credit is fully matched.
However, this check only considers `amount_residual_currency` and not `amount_residual`, which, in the case of an exchange difference, are different.

opw-4776188



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

Forward-Port-Of: odoo/odoo#216097

**Steps to Reproduce :**

1. Install MRP.
2. Create a Bill of Materials (BOM) and add a component with lot tracking.
3. Create and confirm a Manufacturing Order (MO) with BOM.
4. Navigate to the shop floor and click on Generate Serials/Lots.
5. The error appears when trying to generate the lot .

**Issue :**

Error raised when try to Generate Serials/Lots during the manufacturing
process.

`TypeError: unsupported operand type(s) for //: 'NoneType' and 'int'`

**Cause:**

This error occurs because the quantity field is undefined when
Generate Serials/Lots is triggered, the quantity field is not being passed in
the context, and its value is undefined, which is leading to a division by [none](https://github.com/odoo/odoo/blob/18.0/addons/stock/models/stock_move.py#L993).

**Solution:**

To fix this, we added the stock move’s demand quantity as a fallback.This ensures the 
quantity field value is present and its value correctly passed during lot generation.

opw-4763600

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

If you have a product template with variant, ex: Telephone case, variant name : Iphone 15 SE, Samsung Galaxy, Nokia 1999
When doing a search with more then 2 letters you will only find the Telephone case, search exemple: Iphone 15 SE, Galaxy, Samsung.
    
    ** Step to reproduce **
    - Create a product with variant samsung galaxy S24 ultra
    - Create a product called Samsung galaxy
    - Enable them for point of sale (don't forget to select a category that will appear on your shop)
    - Do a search for the product Samsung galaxy
    - Only Telephone case will appear.
    
    ** Cause of the issue **
    Doing a search will call getProductsBySearchWord:
    https://github.com/odoo/odoo/blob/5a1fff2cc61bd8676049879039defa3fb2a3f13d/addons/point_of_sale/static/src/app/services/pos_store.js#L2401-L2407
    During the product.exactMatch(words) we will get a hit since we will have a name of the product variant:
    https://github.com/odoo/odoo/blob/5a1fff2cc61bd8676049879039defa3fb2a3f13d/addons/point_of_sale/static/src/app/models/product_template.js#L265-L278
    And the call for the function will finish there since the searchword lenght > 2 and we have a hit.
    
    opw-4864976

When multiple `ir.ui.view` records exist with the same key
(e.g., due to duplication), it can lead to a singleton error.

**Steps to reproduce:**
1. Install the website module
2. Go to `Settings > Technical > User Interface > Views`.
3. Find and duplicate the **Home** view for **My Website** (same key).
4. Open the website home page in Editor mode.

**Error:**
`ValueError - Expected singleton: ir.ui.view(2776, 2774)`

**Cause:**
In `viewref()`, it uses `filter_duplicate()` to filter for the 
most suitable view, but it may return multiple views if more 
than one match the criteria. - [1]

**Ref:**
At [2], system uses `limit=1` in `_view_obj()` to 
ensure only one view is returned, even if duplicates 
exist for the same key.

[1]: https://github.com/odoo/odoo/blob/edfa37271a0015a0d4acb17e6985a87e707e5f33/addons/website/models/website.py#L1228-L1230

[2]: https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/web_editor/models/ir_ui_view.py#L326

**Fix:**
This commit ensures that the result is a record set with at 
most one view and preventing singleton-related errors.

sentry-6223988092

Forward-Port-Of: odoo/odoo#213113

**Problem:**
when scanning a package with a different uom
than the barcode line, the conversion is not made

**Steps to reproduce:**
- enable the "packages" settings
- create a new storable product and set  uom of kg
- click on the on hand smart button
- add a new line
- in the package column create a new package
- set a quantity of 10 kg
- create a new internal transfer and select your product
- set a demand on 10000 and the uom of g
- mark as todo
- open the barcode app
- inside internal operations click on your move
- scan the name of the pack

**Current behavior:**
the quantity on the line is now 10/10000g

**Expected behavior:**
it should be 10000/10000g

**Cause of the issue:**
https://github.com/odoo/enterprise/blob/4c9fa9dc010958710d848fbcb3241b17ea7205ca/stock_barcode/static/src/models/barcode_picking_model.js#L1500-L1505 remaining_qty is expressed in the uom of the quant so it will be 10 but qty_needed is expressed in the uom of the line is it will be 10000.
qty_used beeing the minimum of those two it will be 10.

**fix**
for the comparison to work we need to convert qty_needed before compairing.

Also we need to make sure that the line is updated with the quantity converted in its own uom.
Adding the uom to fieldsParam enables _udpdateLineQty to do the conversion
https://github.com/odoo/enterprise/blob/4c9fa9dc010958710d848fbcb3241b17ea7205ca/stock_barcode/static/src/models/barcode_picking_model.js#L1669

opw-4860064

Forward-Port-Of: odoo/enterprise#87642

### Issue:
When having two lines on an invoice with the same tax and different analytic distribution, the base value is doubled on the tax report.

### Steps to reproduce:
- Create a new tax on sales (eg 10%)
- Make sure the option "Analytic Accounting" is ticked in the settings
- Create an invoice with two lines (eg both at $100), add the tax on both
- Change the analytic distribution on both lines to different values
- Confirm the invoice
- Go to the tax report
- Select the report "Group By: Account > Tax"
- On the report the "Net" amount is doubled ($400), the tax amount is correct ($20)

### Cause:
On the invoice we can see in "Journal Items" that two tax lines are created instead of one (one for each analytic distribution).

The "Group By" reports are generated by [this query](https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/account/models/account_move_line_tax_details.py#L92). At the [creation of the second subtable](https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/account/models/account_move_line_tax_details.py#L164-L198) the move lines are linked together based among other things on the tax id. The [filter on analytic distribution](https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/account/models/account_move_line_tax_details.py#L187-L191) does not apply here as `tax.analytic = False`. The result is that each tax line is linked with both base lines. The second subtable have 4 lines in this case, with each base line doubled.

The result of the query have the base amount doubled.

### Solution:
We cannot fix the query as there is no link to find the tax line origin amongst the base lines.

The method `_read_generic_tax_report_amounts` in `account_reports` is made to fix the base values in report in case of duplicate. Until now it did not include the duplication caused by analytic distribution but duplication because of repartition lines for example.

The fix is to use this method also for analytic distribution. So we add `tdr.analytic_distribution` in the `GROUP BY`. This value must be returned by the query in `account` so we add it.

opw-4753676

Forward-Port-Of: odoo/enterprise#87404

This [PR](https://github.com/odoo/odoo/pull/209860) adds a fallback to product_uom_qty when the quantity field is not present during
serial/lot generation from the shop floor.

Includes a tour and test case in mrp_workorder to validate the fix.

**Steps to Reproduce :**

1. Install MRP.
2. Create a Bill of Materials (BOM) and add a component with lot tracking.
3. Create and confirm a Manufacturing Order (MO) with BOM.
4. Navigate to the shop floor and click on Generate Serials/Lots.
5. The error appears when trying to generate the lot .

**Issue :**

Error raised when try to Generate Serials/Lots during the manufacturing
process.

`TypeError: unsupported operand type(s) for //: 'NoneType' and 'int'`

**Cause:**

This error occurs because the quantity field is undefined when
Generate Serials/Lots is triggered, the quantity field is not being passed in
the context, and its value is undefined, which is leading to a division by [none](https://github.com/odoo/odoo/blob/18.0/addons/stock/models/stock_move.py#L993).

**Solution:**

To fix this, we added the stock move’s demand quantity as a fallback.This ensures the 
quantity field value is present and its value correctly passed during lot generation.

opw-4763600

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

### Background
In https://github.com/odoo/enterprise/pull/85026 we changed the behaviour of `l10n_mx_edi_post_time` so that it gets set during the CFDI sending process, rather than when the invoice is posted.

This was needed to ensure that the post time both reflects the sending time and is re-used if the invoice needs to be re-sent.

### Bug description
Since then, several Mexican customers have reported that some CFDIs are sent duplicated, with a difference of a few seconds in the CFDI's Fecha.

### Analysis
A disconnection might occur during sending of the CFDI. In that case, the PAC will process the CFDI, but in Odoo the transaction will be rolled back, and the `l10n_mx_edi_post_time` will be lost. When Odoo re-sends the CFDI, it will take a new `l10n_mx_edi_post_time`.

### Solution
Commit before performing the API call so that the `l10n_mx_edi_post_time` gets committed to DB.

opw-4780096

Forward-Port-Of: odoo/enterprise#89263
Forward-Port-Of: odoo/enterprise#89117

Issue
-----
The ticket raises 2 issues products tracked by lots and stored in a specific location:
1. Scanning Location > Lot overrides the reserved location without asking the user for confirmation
2. Scanning Location > Product > Lot should first produce a warning then, if repeated, override the reserved location with the scanned one

Setup & issue reproduction
-----
- Enable in settings
    - Lots & Serial Numbers
    - Storage Locations
- Create 2 storage locations Shelf1 & Shelf2
- Create a product Prod tracked by lots
- Create a lot Lot1 of Prod in location Shelf2
- Go to Inventory > Configuration > Operations Types > Delivery Orders
    - In "Barcode App" page, set "Source Location" to "Mandatory Scan"
- Create a new delivery for Prod, set it as To-Do
- Open the delivery in barcode

To reproduce issue 1:
- Scan Shelf1
- Scan Lot1
--> No warning, the user can validate the transfer

To reproduce issue 2:
- Scan Shelf1
- Scan Prod1
- Scan Lot1
--> You get a warning & repeating the steps doesn't work as the warning suggests


Problem analysis
-----

#### TLDR

**The current behaviour is flawed. The warning is for when there is a reserved quantity so the check should happen in `updateLine` and not `createNewLine`. Also, there is a confusion with `needSourceConfirmation` serving for both the need for a warning and indicating the user has been warned. These should be 2 separate flags.**

List of tested flows (with fix) can be found [here](https://github.com/odoo/enterprise/pull/87740#issuecomment-3004459646).

#### Warning popup

The warning popup happens thanks to the check for matching of locations which happens in `createNewLine`

https://github.com/odoo/enterprise/blob/5d10fb2c734d1379c1415f683f3c5ab0620d425b/stock_barcode/static/src/models/barcode_picking_model.js#L51-L57

but not in `updateLine`. This is incorrect as the warning is meant to protect changing the location of an *existing* line. Since it has no reason to be in `createNewLine`, we can move it from there to `updateLine`.

#### Setting the warning flag

When scanning a product after a wrong location, the flag value can be changed in 2 parts of the code...

1. In `_findLine`, where we iterate over the existing lines and, for each, check whether it can be taken from the current location (using `lineCanBeTakenFromTheCurrentLocation`)

https://github.com/odoo/enterprise/blob/cf13e6b102ad33ace724b5ffd28d508158db2d15/stock_barcode/static/src/models/barcode_model.js#L1351

2. In `createNewLine` (`updateLine` after fix) where we check if we need to warn the user before setting the flag to false

https://github.com/odoo/enterprise/blob/cf13e6b102ad33ace724b5ffd28d508158db2d15/stock_barcode/static/src/models/barcode_picking_model.js#L49

#### lineCanBeTakenFromTheCurrentLocation problems

https://github.com/odoo/enterprise/blob/cf13e6b102ad33ace724b5ffd28d508158db2d15/stock_barcode/static/src/models/barcode_picking_model.js#L188-L191

The condition only works for one "acceptable" use flow. Updating the condition wouldn't make much sense, because there is no way to make en exhaustive list of "acceptable" use flows (e.g. adding X unrecognised scans between the location and product scan). The domain of "acceptable" use flows is too large for a simple condition.

We set the flag to true only for "acceptable" use flows. This is the opposite of what we want. We don't want to warn the user when they scan again using an "acceptable" flow.

We `return false` although there is a line we want to take from. This tells `_findLine` that no line can be taken, leading `processBarcode` to create a new line instead.

https://github.com/odoo/enterprise/blob/cf13e6b102ad33ace724b5ffd28d508158db2d15/stock_barcode/static/src/models/barcode_picking_model.js#L192-L193

Setting the flag to false here doesn't make sense, since only non "acceptable" flows lead to here.

We can simplify the behaviour here to simply set the flag to true and not do anything else in this block. This is possible thanks to

https://github.com/odoo/enterprise/blob/cf13e6b102ad33ace724b5ffd28d508158db2d15/stock_barcode/static/src/models/barcode_picking_model.js#L183-L184

which ensures that we are in the case of a mismatch of locations with an existing line. We don't return in here because a line was found so the closing return of the function suffices.

The reason why we want to return true here even when there is a mismatch is because we want the code to try to edit the line. It is up to `updateLine` to ensure no line needing confirmation will be edited. This change means we will have to make adaptations to other parts of the code that were written with the previous behaviour in mind.

#### Updating the condition in `updateLine`

After applying the above change, we have a problem with the condition in `updateLine`. If we set the flag to false when warning the user, we get the following behaviour when scanning the product:

- `lineCanBeTakenFromTheCurrentLocation` sets the flag to true then
- `updateLine` sees that the flag is true, it will warn the user and set the flag back to false.

We have to change how `updateLine` checks if it has to warn the user to avoid this logical loop. We want to warn the user using some combination of the following conditions

1. the location of the line we are trying to update doesn't match with the scanned location (`needSourceConfirmation` is true)
2. the user has been warned (we use a new `askedSourceConfirmation` flag with the same structure as `needSourceConfirmation`)
3. the scanning sequence is an "acceptable" confirmation one (the new `isConfirmationSequence` function)

Using these, we can define 2 scenarios which require a user warning:

A. The locations don't match and the user hasn't been warned yet => 1 AND (NOT 2)

OR

B. The locations don't match, the user has been warned but the scanning sequence isn't "acceptable" => 1 AND 2 AND (NOT 3)

If we are in either scenario, we warn the user and set 2 to true. If both A and B are false, we can update the line and reset both 1 and 2 to false.

#### Example of a simple flow with flag values

- Initial values
> 1 = false, 2 = false, 3 = false
> A = 1 AND (NOT 2) = false, B = 1 AND 2 AND (NOT 3) = false
- Scan wrong location
- Scan product => 1 is set to true
> 1 = true, 2 = false, 3 = true
> A = 1 AND (NOT 2) = true, B = 1 AND 2 AND (NOT 3) = false
- The user gets a warning because A is true => 2 is set to true
>1 = true, 2 = true, 3 = true
> A = 1 AND (NOT 2) = false, B = 1 AND 2 AND (NOT 3) = false
- Scan wrong location
- Scan product => 1 is set to true
> 1 = true, 2 = true, 3 = true
> A = 1 AND (NOT 2) = false, B = 1 AND 2 AND (NOT 3) = false
- The line is succesfully updated because both A and B are false

#### Arbitrary limitation of condition 3 in implementation

We arbitrarily decide to only accept 3 flows for location confirmation.

>this.scanHistIsProd(0) && this.scanHistIsLoc(1) && !line.lot_id ||
>this.scanHistIsLot(0) && this.scanHistIsLoc(1) ||
>this.scanHistIsLot(0) && this.scanHistIsProd(1) && this.scanHistIsLoc(2)

This is to avoid possibly costly computations. Imagine the user gets the warning message. They scan the location again. Then, instead of scanning the product, they scan an unrecognised barcode. After this, they scan the product. Adding this specific case would be easy. But what if the unrecognised scan happens multiple times? Or they scan many products in the meantime? We would have to go through the whole scanning history to see if we can find the "Wrong Location > Product" scanning sequence twice (a first time raising the warning, the second confirming). And what if the first time didn't raise the warning but simply confirmed an existing line?

The domain of possible use cases is hard to formally define. Instead, we can make the reasonable assumption that when prompted the warning, the user will simply rescan "Wrong Location > Product".

-----
Ticket:
opw-4731237