Hi guys,
Another new UOM reletes issue highlighted, decimal quantity issued (How?) to a job of UOM NOS. I cannot adjust the qty in decimal.The reflection of this decimal qty issue made a unbalnced total in PartBin. How i can resolve this issue? I have tried conversion 6430,9201 already . Important thing is, the part UOM is not allowed decimal.
What was the QtyPer and total qty produced by the Job that caused the STK-MTL of 0.01?
If the Job is still open, can you do a Material Issue to it of 0.99.
Or edit the job to make the total required be a whole number, and then use mass issue to issue the remaining difference. Make sure Job Material isnāt marked Issued Complete, before the Mass issue.
Not sure about E9, but in E10 each UOM can have decimals enabled, and how many places to limit to.
Like e10 ,e9 also supports for decimals, but i have not enabled it for NOS UOM. I reopened the job ,(total requred qty is 20 nos, and 1 Nos for each job.),unmarked the issue complete, tried to issue remaining 0.99 NOS, but I already disabled the decimal issue, it is not allowing the 0.99 . When i clicks on stock qty 0.99 it shows round up qty to 1 and total issued 19.01 to 19. it is very clear that total require qty 20 =0.99 + 19.01.
Hi Calvin,
Yes i tried that, i have enabled decimals up to 3 for UOM NOS and tried. But its not done. Also i just spent lot much time to find why it happened, but not found any reason. Because, hence there is decimal not allowed, u cant issue decimal,interesting thing is u cant even type decimal in that text boxā¦still it happened.
The I tried on test DB for perticular Partran table row by updating 0.001 to 1 Nos, nothing happened. I found it changes previous records and running total.
I have a similar problem, with a crazy amount that I cannot adjust in our out, normally nor via dmt. We keep the quantity in the positive, so that we donāt get unecessary purchasing suggestion for it.
We have found the error caused by: When the part is setup with conversion factor and different inventory and purchasing UOM, pull of material onto job allows conversion to use more decimals than the rest of the system allows. This is what causes the error.
Seems like a bug that should be reported. Weāre on 905702A, not sure if still occurs in E10. We askengineering to not use different UOMs for purchasing vs inventory to alleviate occurence now.
Regardless of what you set up for decimal precision, the system is always going out 8 places in the background. This can cause very small quantities to get stuck on-hand.
The way to correct the issue is pretty simple.
In Company Config, set the decimal display to 8
On the UOM for the part, set the UOM to 8
Log out of the system and then back in
Use Quantity Adjust to remove the fractional quantity
Set the UOM and Display back to what it was.
This is a pain, but it is simply how the system works and nothing can be done about that. It is one of the pitfalls of UOM conversions.
I have found that Mass Issue to Mfg when issuing Feet stock UOM to Inch use UOM will create fractional inventory, based on the conversion of feet to inches. Once a month I run a query to find the fractional inventory, go into UOM Length and change my decimals to 9 places, then I miscellaneous issue the fractional inventory. Then I return the UOM Length to 2 decimal places.
I made two dashboards ( attached ) to update the PartBin and PartFIFO table to clear these. We use when a part is āzeroā, but you canāt get past the fifth decimal in an adjustment. I only let the materials manager use since they are wide open. You could change the query to only return quantities you wanted to allow to be adjusted off.
@Kenadian : Yessā¦Doneā¦i updated the decimal allowed column, decimal places by backend and adjust the qty for -0.99 nos on that day. Now parttran history and partbin showing correct running total.
Thanks very much Ken!
Do you think the company config decimal display does much other than display what exists? Iām trying to decide if I need people to be offline to do this in production database, to ensure no unexpected new cases of more decimals than desired. If itās only display, it seems like it shouldnāt matter to tweak a bit during business hours. Any thoughts on this?
FYI, when the company configuration Quantity Decimal Display is temporarily altered, to allow adjustment in/out fractions of parts with more decimals than setup in inventory, Reports also show the additional decimal places. Many of our reports couldnāt fit the digits and showed ############## on print. Epicor help does not make it obvious that reports will be affected, though they areā¦
Epicor help states:
Controls the number of decimal places that the UI uses to display a āquantiityā field. This only controls the display, the actual number of decimals that can be entered is based on the Unit of Measure. (UomConv.NumOfDec)
It appears (I have only run a couple of tests so far) that 10.1.500 does the rounding up at āMass Issue to Mfgā screen which has been creating fractional inventory for me. (Mass Issue now follows the same ruleset as āIssue Materialā LIKE IT SHOULD)
Greg, I setup the Partbin Dashboard, but it complains when I try to run itā¦are you able to help??..looks like this will do exactly what I need (remove some Deciamlise qty of stock which is setup as Count, and we do not allow decimals (I assume they occurred before we unticked allow decimals).
In the dashboard it hangs at āSavingā¦āā¦so I checked in the BAQā¦and get this errorā¦
āThere is no BPM customization attached to Update method of ā00002-FixQtyPartBin1ā updatable query in ā00002ā company or BPM system is not enabled.
Please check presence of BPM customization and/or ask administrator for assistanceā
This is a little beyond meā¦are you able to assist?
@rkelley792 It sounds like the baq got messed up somewhere. I just downloaded it from the site and put it in my test system and it was fine. Given that this is an advanced baq update just getting it running will not also make sure it will not cause damage to your data I am going to recommend you take the same approach the OP did and use company config to fix the issue.
I appreciate that Greg and fully understand from your POVā¦.I donāt know enough to fix the issueā¦.but enough to be dangerous!!..LOL
I have in fact only 2 items which have decimal of a count UOM class and I was able to exploit a backflush bug that allows me to allocate a decimal qty and just get it consumed that way.
I think our processes are robust enough to prevent this happening again, so I am all sorted.