First Serial Numbers in Receipt Entry Disappears

When we purchase serial tracked parts, we enter the serial numbers during Receipt Entry in the Select Serial Number screen (10.2.700, but not Kinetic). Sometimes, we enter multiple serial number, and the receipt Entry screen accepts them (without posting the message “number of serial numbers does not match the number required”). But, when we look at Part Tracker/Serial Number tab, there is one less Serial Number than we received. And looking at Receipt Entry again, the Select Serial Number screen now shows one less Serial Number than it did before.

The serial numbers in the example below are alphanumeric, so the serial number “52291/52292” is one valid serial number. But the issue can occur in other parts with numeric serial number. It always the first serial number entered in Select Serial Number that disappears.

This seems to happen to one user and not others, so I deleted personalization and Cleared Cache. But issue recurred.

Is there any BPMs in the process? I have come across this on job receipts. It drops the first one on certain conditions.

If so, I’ll have to look up what I did to eliminate the issue.

Thanks for replying Doug, I saw that you had a similar issue last year and wondered how it was resolved.

There is a BPM on Receipt Entry that sends out an email alert if there is a requestor listed on the PO line. I can disable that, but the problem does not occur on every receipt with multiple SNs, so it will be hard to determine when it’s fixed. I am going to do some experimenting in our test db today to see if I can reproduce the error.

Haven’t seen this before but it does invoke curiosity.

What happens if you manually type in the missing serial number at the bottom in the ‘Serial Number’ field and click Select?


It is the presence of a condition block as the first step in the BPM. I needed to do a condition block, so I ended up using a code widget and wrote my own. As soon as I did that the first S/N issue disappeared. In our case it was seemingly random. We would receive qty X parts, and only qty X-1 serial numbers were created. It caused some funny SN Transaction numbers as well.

Putting a code block in for the initial check allowed me to set a variable which I could then check in a conditional statement after the code block:

As an example, the code block would look something like this:

ShouldProcess = false;

foreach (var row in ttPartTran.Where( r=>((r.RowMod=="U")) ) ) //only updated records
  //do some testing here and set the ShouldProcess variable

The condition statement would then compare the ShouldProcess and if true continue…

1 Like

My BPM on Receipt.UpdateMaster has two conditions. I’ll try to follow your example on the first conditional, and see if that resolves the issue. Thanks for the direction, I would never have found that on my own.

I finally was able to confirm that it is, in fact, that first conditional in my BPM that caused the issue. Here’s my workaround to eliminate that first conditional with a bit of code and a variable.

I have a case with Epicor Tech Support and they are passing it on to Development for analysis and resolution some day.

1 Like

I was told to use a data directive instead to try to get around this error. That was before I figured out the condition was causing it.

Keep us updated! I’d love to know the outcome.