[16.0][MIG] stock_barcodes_gs1: Migration to version 16.0

[sergio-teruel]

cc @Tecnativa TT47630

ping @carlosdauden @CarlosRoca13

Depends on:

• [16.0][MIG] stock_barcodes: Migration to 16.0 #610

[sergio-teruel]

Done

[pedrobaeza]

I don't see the temporary commit:

https://github.com/OCA/maintainer-tools/wiki/Use-temporary-reference(s)-to-another-pull-request(s)

Please also squash administrative commits:

https://github.com/OCA/maintainer-tools/wiki/Merge-commits-in-pull-requests

[dreispt]

result["use_weight_as_unit"] = bool(rule.use_weight_as_unit)

[kluna1998]

I think you can't initialize the gs1_separator_fnc1 field as False because it's a Char field. I think initializing it with an empty string ("") should work.

[alexis-via]

I just found a bug in stock_barcodes / stock_barcodes_gs1 which is fully reproductible: when you receive a product tracked by serial number with a GS1 barcode such as (02)product_code(21)serialnumber in multiple quantities:

1. in the scan interface: when you scan the GS1 barcode of the first product with serial SN001=> works well, no error
2. when you scan the GS1 barcode of the second product (same product_id as the first scan with a different serial SN002), you get a red banner "SN002 (S/N Already in picking)"

When you analyse the code: the error is located here: https://github.com/OCA/stock-logistics-barcode/blob/16.0/stock_barcodes/wizard/stock_barcodes_read_picking.py#L533
When you see the condition that leads to the error, you see that it uses "sml.lot_id == self.lot_id or sml.lot_name == self.lot_id.name". When you scan the second barcode, self.lot_id still points to the first serial.
When you look at the code of stock_barcode_gs1, on that line of code https://github.com/Tecnativa/stock-logistics-barcode/blob/16.0-mig-stock_barcodes_gs1/stock_barcodes_gs1/wizard/stock_barcodes_read.py#L59 you see that the code sets "self.lot_name", but not "self.lot_id".

I feel that the code of stock_barcodes considers that, when entering the method _process_stock_move_line(), self.lot_id should be set to the scanned badcode, whereas the code of stock_barcode_gs1 considers that it just has to set self.lot_name. Or there is a problem linked to the fact that self.lot_id is set later in the execution order. I'm not an expert of the code of stock_barcodes, so my analysis may not be the right one.

[alexis-via]

To fix the bug on products tracked by serial when receiving multiple quantities of the same product, I changed the code in stock_barcodes AND stock_barcodes_gs1:

• my changes in stock_barcodes: https://pastecode.io/s/7mgvz4h0
• my changes in stock_barcodes_gs1: https://pastecode.io/s/0bjh3c9j

The idea behind the change in stock_barcodes_gs1 is to reset self.lot_id when reading the GS1 barcode and setting self.lot_name, so that self.lot_id doesn't point to the previously scanned barcode any more.
In stock_barcodes, I made 2 changes:

• use self.lot_name instead of self.lot_id.name => needed to fix the bug
• use float_compare() => not needed to fix the bug, but it may avoid future bugs !

As I am not familiar with the codebase of stock_barcodes, my changes may not be the rights ones and it may break other scenarios. That's why I just put out those diffs and I didn't propose a PR.
But I use those diffs in production now, because I was obliged to fix the bug ASAP.

[edescalona]

Hi @sergio-teruel , could you please correct @kluna1998 suggestion?

And check why the runboat is failing?

Otherwise, it seems fine to me. Thanks for your contribution.

[sergio-teruel]

Hi...

I will review this week sorry!!!

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.

[ivs-cetmix]

Hi @sergio-teruel thank you for your contribution! any chances to fix the tests?

[sergio-teruel]

Hi @ivs-cetmix Not Yet!!! Sorry