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.
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.
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…
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.
Do you think this is just tied to Method Directive not Data Directive? Also is this Pre-Process only or Post as well? Reason I ask is we are highly serialized firearm’s industry and I have seen this occur in multiple places. One of the issues was causes in serial number selection. If you do not click “retrieve” before scanning or typing serials it may drop one.
as far as this issue, I dont want to add code for every Bo as we have a lot.
