Skip to main content

We are testing the scanning functionality of the Scan It app and noticed that in certain screens it drops the identifying prefix character when scanning and in other screens it does not.  Attached is an example, the numbers circled in RED appear with the prefix in front of the scan.  The item circled in GREEN scans correctly and it gets dropped.

 

For example, Move Inventory Part drops the “Q” prefix when scanning but the screen before that which is Part No it does not drop the “P”

 

Is there a place in IFS where you can set what gets dropped and what doesn’t?  Or do you typically set that on the scanner gun itself?  We are using Honeywell CK65’s

hello,

The IFS WADACO application does not have any configuration that enables you to change how it reads a barcode, i.e. how or if it trims off lead characters.  It’s possible you can configure something on a particular scanning device, but if haven’t come across that… 

I think you are indicating that the barcode for the quantity contains “Q44” in this case, is that right?  If so - IFS knows that it is expecting a number here, so I guess the logic knows to trim off alpha characters when scanning for a number.  But part number, PO number etc. are text fields so there’s no reason it would trim off a leading character.

If you can’t do it in the scanner then this would require a modification to IFS.

Thanks for the information, and that makes sense.

 

For anyone else who comes across this, what I ended up doing was downloading the Honeywell Enterprise Provisioner along with the device settings package for the OS version of my scanner gun.  Under Data Collection Service, Decode Filter, I entered the following script and generated a scannable barcode label.


This takes any code39 or code128 label and strips the characters specified in the data.regex parenthesis.  Anyone else using Honeywell scanners can take this code and modify it to strip the characters as they see fit.

 

if (_event == 'decode') {
if ( _aimId == ']C0' || _aimId == ']A0' ) {
found=_data.regex("^((PKQVNDSHMLT])(.*)");
if (_match2 ){
_data=_match2;
}else{
found=_data.regex("^(3S)(.*)") || found=_data.regex("^(4S)(.*)") || found=_data.regex("^(5S)(.*)") || found=_data.regex("^(1J)(.*)") || found=_data.regex("^(5J)(.*)") || found=_data.regex("^(6J)(.*)") || found=_data.regex("^(2P)(.*)") || found=_data.regex("^(1T)(.*)") || found=_data.regex("^(4K)(.*)");
if(_match2){
_data=_match2;
}
}
}
}

Just a comment about this. To my knowledge Scanit don’t trim off any alpha characters for number data items, that trimming must have happened in the scanning device before the string reaches the Scanit field. Since you can enter/send alpha characters in number data items but you will then get an error directly when trying to save it.

Only trimming that could happened is if you use GS1 barcodes then our server framework will remove the AI Code from the barcode string when each object in the barcode is saved to corresponding data item.

Reply


Terms & ConditionsCookie settings