Receipt Entry Not Using Correct Unit Cost

Today we noticed an issue with materials being received in. On Receipt Entry > Lines > Detail > General, there are two fields. Suppler Price, and Unit Cost. These should not be the same if supplier qty UOM (PUM) and our UOM (IUM) are not the same. For example, we received 1071.75 IN of material. The Supplier Qty is correctly, 89.32 FT. However, both the Supplier Price and Unit Cost show the per foot value instead of their correct UOMs.

To fix this, we have unchecked “Complete” and unchecked “Received” Then clicked save. The save process seems to correct the cost issue. Now we have to see if any materials got issued to a job with the wrong (WAY inflated) cost.

Why is this is happening? It seems to only happen after the last update. I don’t see any older records with this issue looking back a few years.

I made a BAQ to help identify this if it happens again. The BAQ simply looks at the records in RcvDtl for any packing slips where the IUM <> PUM, AND OurUnitCost = VendorUnitCost. After we ignore the EAs, ARs, and ZZs that show up we find only the packing slips where one UOM is FT and one is IN, and if the price is the same. This is the issue.

Have any of you seen this recently? If not do a quick check for me and let me know. If this is a known issue, do you know of a fix?

(I just submitted a support ticket with this similar info.)
Here is the BAQ if you want to check yourself.
ReceivedAtWrongPrice.baq (15.8 KB)

Thanks everyone! Happy Friday!
Nate

1 Like

@NateS Did you ever get this resolved?

Unfortunately no. This was my last post to the support person working on it. They made me make multiple tickets and passed me around, and then gave up on it.

We have instructed our receiver to employ the only fix we know. That is to uncheck receive and check it again if they notice the UOM is wrong. Since we asked him to do this, we have not had any issues. Someone else has taken over the receiving work, and they have not experienced the issue yet.
Unfortunately, we don’t have a satisfying answer to this. We have to close this ticket uncompleted. It is no longer worth our time to attempt to resolve the problem. If the problem comes up again, I will reference this case, and open a new ticket.

We still use the BAQ to review places where the UOM is not the same, just in case a problem slips by.

@NateS Would you please put the ticket EpicCare ticket number in this post? We are having the same problem, and Epicor’s refusal to address this issue is unacceptable. Thanks in advance for your help. I’ll keep you posted if we get anywhere with the problem.

CS0003446345
and
CS0003388048
Good luck! Let us know if you find out anything new!

I don’t see much in our system. 3 record in 5 years.

Is this only PUR-MTL that you are seeing this?

We never do that now, but we just had the idea to do it the other day, so I hate to recommend it if it results in this…

For us, it’s happening on PUR-STK and PUR-MTL.

All PUR-STK for us. But I suppose it could happen at PUR-MTL.

1 Like

OK, I just assumed this meant you were buying direct to jobs. But you probably are average or last or FIFO cost and worried about that being wrong.

Well, then this is odd that we have hardly had an issue with it after hundreds of thousands of receipts. I wonder what the difference is.

Do you allow price updates at receipt? (We do not.) No idea if it makes a difference, but I thought I’d ask.

Yeah, I mean we had some weird duplicated checks a while back and did the same thing as you: complained, got nowhere, made a BAQ, check it every day for problems. Hasn’t happened in a year. :man_shrugging:

@NateS Is it possible that those offending receipts were the result of the continuation of a previously partial receipt?

I am not sure! I will ask our finance person and let you know.