An issue has been brought to my attention for at least one user at this time, I have not had anyone else report this. Every once and a while when he is issuing a FT length of raw material for a machine shop job he will have the material issue screen showing him the “precise” value blinking icon in the required qty. We have found out this is coming up this way because the screen has dropped the 4 decimal places for the FT unit of measure. He is also unable to issue the proper amount of material since he can not enter a decimal value. The fix for this is to close Epicor and relaunch it and the UOM will appear as normal when he goes to issue that job again. When this problem is happening it appears to be isolated to the Issue Material screen as well because he’s opened up the job in Job Tracker and Job Entry and sees the correct decimal required value.
The next occurrence I instructed him to only close Issue Material and re-launch it to see if that alone fixes the problem.
Just wondering if anyone else has experienced something like this.
When you say " … and the UOM will appear as normal …" Is the UOM actually different (say IN vs FT) after E10 is closed and re-opened? Or are you saying that the number of decimal places in the numeric field is different (like from 4, to 8)?
Just curious if the material in question has a different IUM than the UOM on the job. Like if you stock it in feet, but the job requires 4 IN. Then during Mtl Issue, it might be defaulting to the IUM (FT) and expecting 0.333333333…, instead of being in IN and expecting 4.0.
The job that this just happened on is inventoried in ft and the job has that material issued in feet so it’s requirement on the job is 0.25FT. When he initially tries to issue the material its only showing a whole number for FT and he can’t enter 0.25, it wont accept a decimal point. When he closes and reopens Epicor and goes back to Issue Material, its now showing the required amount as 0.2500FT and he can issue 0.25FT to the job. This is an interface issue only, nothing on the job is ever changed or edited to allow him to issue material, simply closing and relaunching Epicor corrects the view and allows him to issue a decimal qty.
Here is a screen shot of it demonstrating the issue on a previous instance, different requirements of material but same symptoms.
So I’m assuming no one else has seen this? It happened again today to the same user. Job entry showed a no decimal UOM on only the required qty field, but no others, and he couldn’t issue the material either since the QTY field there was a whole number as well. Both the 170 and 180 material lines were affected. The issue QTY only shows a whole number so he can’t enter the .25, or .75 that is required for the two lines. He had to close Epicor and re-open it and then Material issue worked again.
For me too same issue today. I tried clear client cache and relogin to Epicor but still issue persists.
Any other workaround, why suddenly it behave like this…
It is accepting Int only and not decimal.
Sadly I have no other work around. This has only been present on one machine and one user, and every time he’s re-launched Epicor the problem has gone away. Even when he is experiencing the issue if I open up material issue on my machine it shows up perfectly fine. That is why I’ve deemed it a machine/user profile issue, vs anything to do with Epicor.
Have you tested the same screen on another box to see if it’s showing the same thing there? If so then I would be checking your UOM configuration and making sure someone did not change the decimal settings for whichever UOM you’re trying to work with.
Luckily I am one of two who have the ability to change those settings and the other individual does not ever venture into setup applications. He has the rights as a backup if I’m not available, so I can be 100% certain none of the UOM settings have been edited when this issue arises.
In those screen shots that don’t show decimals, the Info symbol is shown. Meaning there is a customization on the form. I’d guess it’s a Row Rule, to inform when the value doesn’t match the expected qty.
Perhaps it’s the rule that is messing things up. Especially since the rule affects the appearance of the control. Next time it appears, launch the form without any customizations, just to see if it is still happeneing.
If it doesn’t happen without any customization, Try changing the rule to “highlight” (which would change the back color, instead of adding the icon), to see if that still causes it. Might want to make a customization with the different row indicator now, and then that way you could try it out the instant this returns.
There is not a single customization or personalization on that form for the user experiencing this issue, the Info symbol is shown because it’s showing you an “exact value” since the decimal places can’t be shown, and the value is rounded to the nearest whole value.
So this occurs randomly, for one user, and lasts their entire session. Is that correct?
And you one post says this now affects Job Entry also (your original post said only IssueMtl was affected).
Does it ever appear in the middle of a client session? Like it is working properly, then in the middle of the session it does this rounding thing.
Has the user tried switching the UOM to Inches, and entering 4? I know this won’t work on conditions that would require fractions of an inch, but just try it as a debugging test.
Yes this occurs randomly. I believe he has stated that one material issue in the AM has been fine, and he’s gone back to that in the afternoon to be presented with this issue, only closing and re-opening has corrected the problem. He has not attempted to change to inches as the UOM since that may work yes, but it still doesn’t explain why this is happening, and why it corrects itself after a re-launch of the application.
It was brought to my attention in material issue before, and I decided to check another screen that would report those same qty’s which happens to be the Job Entry screen. That is why I’m now showing that it happens on more than one entry screen.
I just had this appear on another users machine. Different user, different parts, different box… everything was unique except for the symptoms. Attempting to do an Inventory Transfer of a item with a UOM of FT and could not enter a decimal value at all. Closed Epicor and re-opened it and it was back to normal.
Once it appears, is it persistent within that session of the client? Meaning that the problem persists even after:
closing and reopening the form (not the client session)
changing the record (enter a different Part Number)
selecting “Reset Layouts to Base”
If it does persist between instance of the form being opened, check to see if it is happening when the form first loads. Before selecting a Part, the form looks like:
closing and reopening the form (not the client session) - Yes
changing the record (enter a different Part Number) - Yes
selecting “Reset Layouts to Base” - Yes
When the form is opened you can see the lack of decimals immediately. It stays the same after selecting the part.
As noted the settings on these PN’s do not change from when the instance of the problem occurs to when it’s corrected, so there is no way a UOM would be set to not accept decimals before they opened the window and changed back to accept it before re-launch since I’m the only individual who can make those changes. And they are not serialized parts otherwise closing and re-opening the application would not result in it now being a possible task, it would still prevent it.
I was only thinking of a bug where the number format gets set based on data from a different part, or some criss-crossed data in the DB (like pulling the wrong UOM conversion for the selected part).
Definitely wort reporting to Support.
One last thing to see if it helps (or hurts) is to enable or disable memory cacheing on that form
Worth reporting yes, but ability to replicate the issue, which will be their first request, is nearly impossible with how this happens. I was just wondering if anyone else has seen this activity, and it sounds like it’s not common, or at least if others have they don’t venture to this group.
I have 1 user that is experiencing the same problem when issuing material. I have not really delved into the issue because, as stated above, closing and reopening Epicor seems to clear the issue. The other work around I found was that the user can open MES to issue material and the decimal entry will be available.
I have a user reporting this same issue. It only effects the one user and is present across all of their entry screens. List views do not seem to be effected. Closing Epicor and a PC reboot resolved. Strange.
