Has anyone been successful at resolving this issue? I am also seeing this in 2022.1.11 and did try turning on/off Function Key Mapping but no luck. Barcode scans work fine in Classic but not Kinetic. We are upgrading our PILOT environment to 2022.2 in a couple of weeks so can try then.
I ended up having to hide the combo boxes and just add text inputs bound to the appropriate fields - it would be great to see it working w/ the combos out of the box though. Hope that helps.
1 Like
First off, make sure the TAB key functions as expected using the keyboard. It could be that the tab order is different on Classic UI vs Kinetic.
If it happening specifically on certain fields, there might be be some hidden “helpful” code that strips off white spaces, which the TAB char could be interpreted as.
As always test the scanner in word (with the formatting shown - the Paragraph button on the ribbon). Look for: tab (displayed as an arrow), spaces (as dots), CR/LF (as new paragraph). Better yet use a program like Notepad2 that will the difference between CR, LF, and CRLF.
Number one thing to remember about barcode scanners - they are just keyboards. They convert an optical image to keystrokes.
1 Like
I did verify the items Calvin suggested. The tab order between Classic & Kinetic are the same. Tab is displaying when scanning in notepad and there are no unexpected characters. The difference I see between Classic & Kinetic…
Kinetic when values are entered via manual or scan, in the Assembly or Operation fields, the drop down list automatically displays. If entering manual you can then tab to the next field. The scan with a tab is getting confused with the drop down list display.
Classic does not display the drop down list if a value is entered via manual or scan, the user has to select the down arrow to display the list.
Has anyone reported this to Epicor Support yet?
We also resorted to replacing the Comboboxes with Textboxes in the Start Production view, using Application Studio.
@dgross I have an open support case with Epicor for this issue.
The issue is that the first time the combobox is opened, Epicor is querying the system for the available values to populate the combobox list asynchronously, and if you enter a value and Tab to move on to the next field, you have entered a value before Epicor retrieves it from the database.
You can even reproduce this with a keyboard if you enter the values quickly enough.
If you keep the ‘Start Production Activity’ slider open, go back to the Job field and scan the Job/Asm/Opr again, it works because the comboboxes have already been populated with their data.
2 Likes
One more trouble shooting idea.
- Printout the barcodes for individual characters: A thru Z, 0 thru 9, -, /, including the barcodes for the extended characters: TAB, CR, and LF. Space them apart so you can scan the one at a time.
- Disable the automatically appended TAB in the scanner.
- In classic screen, position the cursor in the field.
- Scan the individual characters one at a time, like if you were typing on a keyboard. After the printable characters have been scanned, scan the barcode for the TAB key.
This should be no different than using the keyboard. I think you said the scanner works as desired in Classic.
- Repeat steps 3 & 4 in the Kinetic screen. Making sure to provide a pause between the last printable character and the TAB.
If it doesn’t respond to the TAB barcode as expected, try again but use the keyboards TAB key instead of scanning.
There should be no difference between a scanned character and pressed keyboard key.
One far stretch of a root cause would be if the field has a keydown event that responds differently to multiple keys in succession, than it does to individual keys. It could be trying to process the TAB as part of the string instead of as a single keystroke used to advance to the next field.
A test of this would be to put the desired string plus the TAB character on the clipboard and paste it into the field. You can use notepad to get the string and TAB on the clipboard. Don’t use Word as that has many formats stored in the clipboard.
After sharing video, explaining the issue, and even a Teams call where I demonstrated the problem not only with the barcode scanner, but also with the keyboard, here is the response:
Thank you for your time yesterday in the remote session. I was unable to replicate this.
The go-to resource for this type of scenarios would be your Epicor Consultant as they are uniquely positioned to assist with this behavior. Epicor Consultants have access to the training materials and real-world scenario expertise to assist you with this setup, also they will be able to tell you if there is a customization for the feature you seek or if there is another way to make it possible by modifying your process. If you do not already have a consultant that you work with, your account manager would be able to put you in touch with someone that has the expertise needed to answer your questions regarding this call.
I will place this case under suggested resolution, please let me know if I can help you with anything else.
I’m surprised the analyst didn’t suggest entering something in IDEAS.
If anyone would like to submit a support case yourself, maybe you can reference mine in order to drive home the point that it is reproducible and several of us are experiencing it.
CS0003457451
So the real issue is that the Kinetic interface doesn’t respond to the same key strokes as the Classic?
Where does pressing TAB (in Kenetic) set the focus?
Or is the keystroke just absorbed and the cursor stays in the same position in the same control?
I believe it is a race condition. If you enter a value and ‘Tab’ too quickly, the value is not committed to the field, the focus moves on to the next field and the dropdown is left open.
What I’ve gathered is you are basically entering a value and tabbing to the next field before Epicor has a chance to load the list from the database, so the value you try to commit doesn’t exist in the dropdown yet. By the time Epicor has loaded it, you have already tried to move on to the next field.
1 Like
My cheapy 1D scanner has a setting for Transmit speed. Looks like it can be set to 0 or 25. No idea what the units are (ms delay, char/sec, ???)
Maybe yours has such a function. And unless your scanning items on a conveyor, I doubt anyone would notice scans taking 1.5 sec instead of .25
Stuffing data in through the UI is always going to be iffy. This is how DMT was born. Some of us tried to add implementation data via programs that operated Vantage. Then we discovered that we could use the client DLLs and upload data quickly and handle errors better. Not long afterwards, the DotNetIT people came up with an amazing generic tool that did all that and better.
In the pre-Kinetic era, we talked about having a text area control on a form that would capture the barcode scan, parse it, check it, fill in the EpiDataView, then refresh the page. I assume one could do the same with a browser… 
1 Like
Yes, we have something like that in the works. Take the input as a text ‘blob’, shoot it to a function to parse and return the usable pieces.
But this is not a case for DMT, this is normal daily input from our shop floor workforce. Epicor gives us barcodes on documents for a reason. Now if the software breaks when you try to use them, that’s a problem.
1 Like
Even I might argue that it’s a UI and not a BI (barcode interface).
1 Like
I don’t want to argue with you, but to the PC, input from the barcode scanner is no different than the physical keyboard… and if I can break it by typing quickly on my keyboard (which I can in this case), then it is still a problem.
1 Like
If YOU can type as fast as a barcode scanner then I totally agree with you!!! 
Seriously, it’s not just the speed. If the screen changes, either by the user or Epicor, then it also breaks. And error handling is much less weaker than DMT.
I’m not a fan of RPA either for this very reason. But again, that’s just me.
@andrew.johnson - I assume the next field after you tab out of the one the barcode scan goes into, is another barcode you wish to populate via scanning. Otherwise you’d just be reaching for the keyboard for the next entry, so might as well hit the TAB key manually.
If the desire is to scan a barcode into field A, have the focus jump to field B for another barcode scan, then try printing a barcode for the TAB character on a sheet of paper (and laminate it - making it look more official 
). The the proces would be (assuming you’re already in field A):
- Scan the bc for field A
- Scan the printed bc for the TAB. Focus should jump to field B
- Scan the bc for field B
So unless your users are really fast, there’s going to be a delay between field A getting fully populated and the TAB command to jump to B
edit
P.S. - I totally agree that it is a bug if manually typing on a physical keyboard can cause the problem.
1 Like
Thanks @ckrusen
No offense, but I don’t understand why so many of these topics turn into suggestions on how to change much of what we (the users) are doing to tiptoe around these problems, or to customize around the problem. As stated much earlier in this thread, I (and others) already have a customization in place to avoid this problem.
Changing a special process that only me or my company is doing, is one thing. But this does not qualify.
The simple fact is that this process works in the Classic UI, and now does not in Kinetic. It’s standard functionality that many people use, and many of us are experiencing the same problem. Jumping through hoops to change our process in order to skirt around a bug isn’t acceptable, in my opinion.
I am here in this thread to:
- Confirm that I am experiencing the same problem as the author of this thread, and others that have commented.
- Share what I have done to temporarily work around the issue.
- Share my progress with Epicor Support on this issue.
- Encourage others to submit cases to Epicor Support, to let them know this is a real problem.
I used to be a nice calm person, now over the past few days I feel like I’m becoming a troublemaker around here… and I don’t like that!
2 Likes