We recently had a new QC inspector make a simple mistake that caused a very big problem. While using WO-I to receive three dozen electrodes into stock (within the QWO chain) she mistakenly entered the lot number in the quantity field. The program had continued on to the lot number entry part of the process before she noticed her error. At that point she was not able to back up to fix the quantity, so she decided to quit the process and start over. The result would have been comical if it were not such an accounting nightmare to fix.
 
It appears that the program (WO-I) performs part of the transaction BEFORE gathering the lot or serial information. Looks like a GL entry is made (cost/WO number) and the UOH registers are updated (BKICMSTR/MTICMSTR/BKICLOC) along with the Book Value, but then the program asks for lot/serial input before recording the transaction in INVTXN and LOT or SERIAL. When she quit the process from the lot number screen I was left with a $6 million financial transaction and no type W inventory transaction and no Lot number transaction.
 
I had two choices for how to fix this: I could have done a negative transaction to fix the financials and I type transactions, but then I would have to rub out the INVTXN type W transaction and the Lot transaction; or I could use WO-G to un-issue the parts and then zero the UOH in BKICLOC. Neither is any fun, but I chose the latter, which was probably "wronger" than the former. Oh well.  
 
Now for my point... wouldn't it be best if the WO-I program gathered all of the required information prior to saving a portion of it to the database? Can't the "write" commands for UOH and financials wait until after the lot/serial info is collected? People are going to make mistakes, so can't we just set the software chain of events to be a little more gentle when doling out consequences?  

We have a design for a Lot/Serial processing program that would prompt for the entry of all the Lot/Serial information of componts and parents in advance of running WO-I and would have the added advantage of a mapping of parent serial number to component Lot/Serial information so you know exactly which component went into which assembly.    
 
However, programming priorities are based on bug fixes first, followed by a combination of our assessment of what is needed by the majority of users based on tech support personnel feedback and comments on this forum, and the willingness of users to "pay for priority" to move something important (to them) higher on the list.  This one has been proposed to several users with the potential of splitting the cost but nobody was interested enough to pay so it hasn't moved past the design stage.   It will happen eventually but money talks and can get it done sooner.  
 
Maybe we need a list of proposed enhancements that are significant enough to require a user investment and if several users pool their resources, we can make it happen.  The recent upgrade to allow for automatic serial number assignment of a range of serial numbers in WO-I was accomplished by 3 users each kicking in $200.  That covered about half the programming involved but we felt that it was a needed improvement to the program so user interest enough to cover half the cost was enough to bump the priority and get it done.