Add an option to improve barcode matching by accounting for discrepancies caused by leading zeros. When enabled, the app should attempt to match both the original scanned barcode and a version with leading zeros stripped. This would help address frequent mismatches between physical product labels and barcode data.
In many cases, physical barcodes may differ from the expected format in the database due to missing or extra leading zeros. This causes the app to fail to find a product that is actually present in the database, just under a slightly different format of the same code. For example the barcode in the VCloud could be 00123456789 but the actual physical barcode could be 0123456789 or 0000123456789.
Introduce a setting (toggle) that enables dual barcode lookup:
First, search the product database using the scanned barcode as-is.
If no match is found, automatically retry using a version with leading zeros stripped. (It's also possible to submit both at the same time to reduce API calls).
The data provider must supply both the original and stripped versions of barcode values for this feature to function correctly. If the original barcode was 00123456789 then the references array in the API call should include 00123456789 and 123456789.
The app should prioritize an exact match but fall back gracefully to the alternate format if needed.
Importantly the feature should be off by default but either a setting on VLink or under the store settings in VCloud would need to be turned on to enable the functionality.
Improved product lookup reliability.
Reduced frustration for users scanning valid barcodes that don’t return results due to formatting discrepancies.
Minimal impact on performance if implemented efficiently.
This issue has been reported by a large number of customers particularly related to US products with UPCs that contain leading zeros. The issue is reported every second week so it's a continuous problem for retailers across many data providers.
Guest
