And what happens if you take the "1" out of that field?

If you have been folowing the topic "WO-A not showing all materials issued" you know I am struggling with this issue.  I checked one of the problem work order BOM's for the above mentioned "1" in WOBOM_EXTRA  field and I also have a one in all of the incorrect quantity issued components.  I deleted the "1" in the extra field of one of the components, then rebuilt the work order costs WO-K-H, and the quantity shown as issued did indeed change in the WO-A materials screen. Sequence of issues was .01, -.01, 1 all issued using enter labor, finish sequence( the first one obviously done incorrectly!, second reversed the first, third done correctly) and backflushing the sequence.  Before the extra fix the quantity was -.01.  After the extra fix the quantity is 1.01.  Not right but interesting that it changed.  What is this extra field??

The .extra field  is used internally by ISTECH to track what  Material was issued for a BOM component.  If you have the same component on the BOM more than once and issue 3 to one and 5 to the other, now you want to back out the 5. I needed a way to tie WOBOM records to WOMAT records. The next 10 chars are for Location. You can now issue materials from different locations. The 'abcdefghij' location is the Blank location.  Actually the number in wobom & womat in the Extra field was one of the last things I did for DBA before they stopped doing anything to the Classic product back in may of 2003.

Cathy,
This is also my situation.  The two Items that do not show that they were issued only appear once on the BOM.
 
It appears that these two Items went to 0 issued when we rebuilt the WO Actual cost while trying to close it the first time.  We have confirmation that these two items showed that they were issued before an attempt was made to close it.
 
NovaZyg Said: Quote:

This is strange.  We only use the 'Blank' location, but all the WOBOM_EXTRA fields that I see data in does not show the 'abcdefghij' text.  ???
 
While looking into: Quote:

I noticed that if a item appears more than one time, a kit issue will issue from every line.  If these items are backed out because of shortages, and then later issued, it shows an over issue on the first item and it leaves the other lines with 0% issued.
Is this the desired operation?

"The correct thing to do is to back out indivitual shortages from the F2 popup list. "
I am not sure how to backout using the F2 key.  As I wrote before we have always used a negative issue to back out of an issue error because we like the way both transactions stay in the record for WO issues and inventory transactions.  Lately its a crap shoot as to whether it will work or not.  When I do it in test company with no one else in that company, it always works, even in the WO-A and job cost modules,which leads me to believe that there is some record conflict when in the real company with 19 other users.  
We recently had a problem when lot controlled issues were entered incorrectly and then a negative issue was cone.  The transactions were correct in all but the WO file WO-A and Job cost.  When I backed out of both the positive and negative transaction ( my method is in WO-G click on the DSPL transactions button, highlight the correct transaction, and say yes to backout.), and rebuilt work order costs, everything was fine except for the inventory file which showed an incorrect amount on hand.  Running a transaction reconcile type B on the part number fixes that.  
It seems to me that both methods have problems.  
I would like to see the backout method not delete both transactions.  Is that possible?

Thanks, Kevin, for your response.  
 I did some further testing in a dummy company yesterday and had a problem with the backout method again.  I had forgotten what it does when it goes wrong;  what happened was that the backout showed up in the work order and job costs files, ie there were no transactions for the part numbers, and in the GL there were both issue and backout transactions, but the inventory file has only the issue and not the backout, so our inventory is off.  There is not an easy way to fix it, except I guess in maintain database delete the inv transaction that issued.  NOt something I like to do.  
It was obvious during that backout that something was wrong.  This was a backout of items backflushed in a sequence.  There were 5 items.  Three backed out just fine, but the 4th and 5th  stayed on the screen flickering for some time before clearing.  NO one was in this company ( our dummy test company) but I guess someone could have been using the WO issue DBA program, would this cause a problem?
Alas, we do make mistakes and need to fix them, and either way seems to cause problems in a completely random fashion!
I understand you and everyone at IS Tech Support have a full plate, and this is like one of those "electrical problems" in your car that only happens when you are not with the mechanic.  AS soon as you can get to it, I would appreciate the help.