GasGiant
|
We use serial control on hundreds of items and multiple BOM levels, so I'd be happy to help. I'm not sure if your post above covers one issue or two. Let me deal with "wrong serial number" first.
When someone here enters the wrong serial number (assigns the wrong # at WO-I), we always back out the WO-I and redo it. The "wrong" serial number will still have a record in the SERIAL.B file (unless you remove it with MDB), but the transactions will be removed. We then redo WO-I with the correct number. We need to have the transactions in there for traceability, so undoing and redoing the transaction is the "right thing to do", so to speak.
When consuming items that have serial numbers, whether via WO-G or backflushing during WO-I, we have trained our people to use F2 to look up the SN and select it from the list. This way they are checking to make sure they have completed WOs placing lower level items into stock and eliminating keying errors.
I'll pause here to make two notes (call them complains, if you like): Firstly, if the serial number you need is not available at this point then you cannot back out of the transaction. you must complete it, even if it means entering a dummy #. Then you have to reverse the transaction and go fix the problem. Second, F2 does not pop up a list of available serial numbers (or lot numbers) like other programs (e.g. IN-L-M), but shows every serial number ever entered for that item.
As to duplicate entries, we have found that performing negative transactions, such as WO or SO for negative quantity, causes DBA/Evo to add a second entry to the SERIAL.B table instead of updating the UOH. Using SC-A can cause the same issue unless you use F2 to look up the serial number before editing.
|
Pages: 1 2
Serial Control - Dups, Removing, etc. (SC-A) (Read 3345 times)
