We have dozens of jobs that are showing this error, claiming that more serial numbers are assigned than there are required for the job. In Job Tracker under the Serial Numbers tab, the correct amount of serial numbers are displayed with no extras in sight. Does anyone know why this is happening, and how to fix it? I’ve opened a case with Tech Support, but no dice just yet.
Are you using serial number assignment to assign serial numbers?
Are there lower level assemblies using serial numbers?
Mark Wagner
Sr. Partner
Capstone Alliance Partners 888.597.2227 Ext. 71
<888.597.2227%20Ext.%20714>2 | 904.412.6847 mwagner@capstoneap.com (cell)
Yes, we’re using Serial Number Assignment for this. The few jobs I’ve checked so far don’t have additional lower-level serial numbers. They look like this in the SN Tracker:
I noticed something in the Tracker’s Transactions tab-- for a job that has three serial numbers (but the error says 4 are assigned), two serial numbers have STK-PCK and STK-CUS transactions. The Third serial, however, does not. Does this indicate something?
Serial WITH STK-CUS transactions:
Serial WITHOUT STK-CUS transactions:
I’ve normally seen this in situations where users are assigning serial
numbers based on different methods. For example, you have 4 parts to
produce, each with a serial number. If you use Serial Number assignment and
pre-assign 4 serial numbers, you will be prompted to use these serial
numbers based on one of the following:
If the operation(s) is checked as “Serial Numbers required from this
operation” then when you go to report a quantity you will be prompted to
use one of those selected serial numbers
If you are receiving the parts to inventory you will be prompted at that
point, if you have not already recorded serial numbers on the operation or
If you are shipping parts from the job you will be prompted at that point,
if you have not already recorded serial numbers on the operation
Do you happen to know if you are both pre-assigning serial numbers as well
as recording from operations?
Mark Wagner
Sr. Partner
Capstone Alliance Partners 888.597.2227 Ext. 71
<888.597.2227%20Ext.%20714>2 | 904.412.6847 mwagner@capstoneap.com (cell)
did those serial numbers ship two in a pack that did not ship yet and 2
that did ship to a customer?
Sounds like that may be the culprit
Mark Wagner
Sr. Partner
Capstone Alliance Partners 888.597.2227 Ext. 71
<888.597.2227%20Ext.%20714>2 | 904.412.6847 mwagner@capstoneap.com (cell)
Forwarding your questions to the production folks here to figure out what they did for these.
Also, Epicor Support is suggesting a datafix that just forces all these jobs closed. Which sounds like a good enough fix for me, but we’re still digging to find the cause of these.
This could be a problem of too many serial numbers being generated during labor entry. Try making a labor transaction on the OP where serial numbers are reported. Completed Qty of 1. There will probably be an available serial number. Record that SN and cancel the labor transaction.
Go into Serial Number Maintenance for that SN and delete the Job Number reference near the bottom of the screen. You may even be able to delete the SN after you do this. I can’t remember off hand.
Once the job number is deleted in SN Maintenance you should be able to close the job.
Can you post a picture of the Serial Number assignment window?
In the Job tracker screen under the Serial numbers tab you don’t have 4 serial numbers?
Nope, in the job tracker screen (and everywhere else) we’re only seeing the correct number of serial numbers.
Also, I’ve been told by the Regulatory dept. that serial numbers are assigned exclusively through Serial Number Assignment. Still gathering info from folks on this, maybe someone else is entering serials and wound up entering the same one twice somehow? This looks like a glitch in Epicor to us.
Did you ever figure this out @LReynolds?
May I ask, what version of Epicor are you on?
We are on 10.1.500.14 and seem to bump into this with a job or two (they seem to come in little batches, maybe it’s related to the part number or BOM for a specific part - our top-level assemblies we run as 1 quantity per job, so if we’re going to make 3 of part X, we have 3 separate jobs).
Maybe? We’re still having issues with this from time to time. I offered the following information to the users involved here, but I never got a response on whether or not this was helpful.
Tech support theorized that when the serial number was assigned to the job a second time, equaling the “4 assigned,” when its status was changed to ADJUST while the job was still open. In their words:
"Luke,
I see that SN 11088 has an additional ADJUST transaction at 16:29. In my own experience I have noticed that at times when there is an ADJUST transaction on a SN it ‘re assigns’ to the job if it has not been closed. We would need to determine first how that ADJUST transaction came in in the first place. We have 2 fixes for this scenario, one would be the generic job closing fix and the other one is to remove that ADJUST transaction which is specific for that one record. Let me know your thoughts on this. "
I checked the problematic jobs in our database and sure enough, each of them have at least one serial with a transaction history that abruptly ends in an ADJUST transaction.
Yah, looks like for the job I’m looking at they did an adjust out of inventory on the part/serial number (product was to be used as a showpiece or something) and did this before closing the job. Thus, same thing - there is an ADJUST transaction on the serial number.
I already had the datafix from Epicor to force a job closed, so I did that.
Now you’re all caught up with us on this, then! Now if only there was a way to prevent or resolve this without a brute-force datafix.
Do you have another example of this?
Many years later, and this issue is still lingering. it is already V10.2.5.
If you cannot wait for a datafix use an Updatable BAQ to close the job - sad, but it does the trick. Just ensure that not too many people have access to this 
Mind sharing the Updateable BAQ?
