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.
Even I might argue that it’s a UI and not a BI (barcode interface).
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.
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):
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
P.S. - I totally agree that it is a bug if manually typing on a physical keyboard can cause the problem.
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:
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!
You are not crazy. I apologize if it seems that I’m not being supportive. It’s me. I’m so used to having technology change and break the way things used to be, that I’ve gotten to the point where I don’t get too attached to anything tech. I just…
In general:
That’s because most of us here are obligate problem solvers, and literally can’t help but try
to figure out a way for you to get what you want.
And also us–>
That’s whether they agree or disagree if it’s a bug. (Of course it’s a bug.)
But if you just want to complain, I agree with you
From Epicor Support this morning:
I was able to replicate this behavior. I was using 4 options in the dropdown before. I did 6 options and was able to replicate. Will report this with development team and cancel this meeting. Thank you
I don’t meant to beat a dead horse here, but today Epicor Support reversed their statement and now say they can’t replicate it again.
I am now being told that their official position is that we need to work with a consultant on this issue.
I again encourage anyone having this same issue to contact Epicor Support and reference my existing case CS0003457451.
Thanks
Can you record a video example, using Epicor’s own Demo database to prove your point that this can be done by hand, on a keyboard? That’ll negate the ‘it’s the bar code scanner’s fault’ excuse.
I did. Not only a recorded video, but demonstrated it live in a Teams call. No barcode scanner involved. It wasn’t the Demo database, but that’s probably a good idea, just to prove the point.
And you’ll still get, “Cannot reproduce.”
I’m trying to fully understand the root cause of the bug (with more detail than it is a race condition). So the steps to reproduce are:
The value in that prior dropdown is not set to what was typed.
The prevailing theory is that the dropdown’s list is not populated until the first time it gets focus. And the value can be typed in faster than the list is populated from the DB, thus no match is found when the field is exited. Sound correct?
And a couple of questions to close up any holes…
How did you get into the field in question? Tabbed into it, selected it with the mouse?
Does the list populate upon entry into the dropdown, or not until you start typing, and/or use the mouse to show the list? What does a trace show when doing the entry by hand?
What triggers the query to populate the list? Control gets focus, mouse click, keydown, changes from blank, … ???
Is that dropdown list dependent on another field in the form? (As in, “Why can’t it be populated when the form loads?”)
I feel that if you could identify the root cause with more detail, then they would have a harder time denying it. And would make it easier for them to reproduce (so they don’t take shortcuts like not closing the form between tests).
(I keep biting my tongue at providing more work arounds, as you clearly stated you’re more interested in proving its a bug)
I’d like to preface by saying I am sorry to anyone who is still subscribed to this thread…
It is my assumption that anyone using the Kinetic UI can reproduce this.
Example 2: Miscellaneous Charge/Credit
Notice that in both examples the dropdown stays open as I am tabbing through the other controls.
Also notice that in the MES example, it throws the UI out of whack and displays a blank slide-out menu.
How did you get into the field in question? Tabbed into it, selected it with the mouse?
Tab, mouse-click, doesn’t matter.
Does the list populate upon entry into the dropdown, or not until you start typing, and/or use the mouse to show the list? What does a trace show when doing the entry by hand?
What triggers the query to populate the list? Control gets focus, mouse click, keydown, changes from blank, … ???
It seems to populate once you begin typing. Enter the field alone doesn’t cause it to load. There is a little loading indicator that shows up where the dropdown arrow is.
Since it is dependent on the speed at which the data is loaded from the database and presented to the UI, there are probably several factors that could make this happen more or less frequently. Performance of the database and app servers, connection speed/latency, etc… That may be why I can reproduce it on demand but Epicor Support cannot.
Thanks, and excellent testing.
I get that those dropdowns are dynamic and thus can’t populate until a prior field has a value - like in your first example, the list of operations to choose from depends on the Job number and Asy sequence.
Has no one at Epicor ever watched really fast data entry people? I could see this causing issues for real people, and not just when “automated” with barcode scanners.
Probably some UX designer that just assumed we will all just be using a touch screen to select from that dropdown list. At least the graphic exists to show the list is updating. That was actually valuable, and not just “pretty”.
I forgot to come back and provide a final update on this. I was able to convince Epicor to reconsider this as a bug, and it is now in development’s hands. PRB0260870
I also submitted a similar issue to them regarding the behavior of selecting values in comboboxes with arrow keys. That was also accepted by development. PRB0261006
I’m pretty sure many of us here know how hard it is to convince the powers-that-be of bugs and get them to accept them to a tracked problem. Great job getting 'em to do it twice!
