Some jobs aren’t being marked as Issue Complete as they are being back flushed with ever so slightly the wrong quantity. Nobody is changing the quantity on the job as far as I can tell, so I don’t know where to start looking. Ideas?
Someone mentioned backflush only doing 2 decimals. (Unsure if correct)
Might be a hint on where to start.
Hmm that would make sense if it was 493.375 vs 493.37. But its back flushing 493.374
I wonder if it has to do with cost… does it round the material to a qty that comes out to an even number of cents maybe? brb doing some math…
Edit: that doesn’t seem to be it either…
I mean it may use only two decimals in it’s calculations somewhere.
May not be the full story.
Well I just noticed another strange thing, the first material is also off by a little but that one still got marked as “Issue Complete”
The plot thickens… 
Ok I found that thread, and I was misreading it.
So each part takes 4.93750000 of this material, if you round to two decimals that is 4.94. There are 10 parts, so that would be 49.4 ft of material, but what we see if 49.374 ft of material.
Its off by 0.0001 per part, or 0.001 over 10 parts… And that doesn’t explain why the issue complete is checked off for the first item but not the second one
I wasn’t suggesting it as an answer, just more info.
More of a “You are not alone” thing. 
If you notice, it is off by a little bit more than required while the other one is a little bit less.
Hmm, and the post you found is quite recent too. I wonder if there was a change in the latest patch…
I’m not sure, but there are a few similar threads from earlier as well to help keep it muddy.
You would think there would be a tolerance setting somewhere.
What’s it supposed to be ?
I see now.
I put in a case, hopefully it goes somewhere
Yeah, @Evan_Purdy I went round and round (no pun intended) with support of their rounding methods when it comes to issuing. I was trying to set up stock UOM in feet (because a stick was like 20’ long) but the issuing quantity on the bom in inches, because a part was like 3.75" long. Basically because of the conversion from inches to feet, you almost always have a bunch of decimals, and it would issue out to 5 decimals, but the stock UOM only allowed 2. So you have these bins showing up with a qty of 0.00* . It wasn’t rounding to keep within the allow decimals. The support guy would not understand why you would want to stock something in feet, but issue in inches. He could not understand.
We ended up having to just use feet for everything even though is makes for some dumb numbers, because the rounding errors would always mess things up.
Your situation isn’t exactly the same, but it’s the same root cause, and it’s that they don’t handle rounding correctly for job issuances. From my experience, Epicor doesn’t really care.
1 Like
If they did, they could at least allow us the option of setting a tolerance on issue complete.
Do you know, if there is a good place to hook, or hang a BPM from after a backflush,
so the data could be “massaged” …