We have had double backflushing recently also.  This seems to come when the receiver receives the parts, but then realizes there was a problem and uses the up arrow to move back up the screen to correct it.  Then, when they cycle through again the backflush repeats.
 
Another issue is that the materials stay in WIP (as shown on IN-A) until the user says Y or N as to whether or not to use STD cost.  the only problem is that often users will leave their station to work on other things during the backflush (as it takes a long time on large BOMs), and mistakenly close the screen without hitting Y or N to the standard cost question.  
 
A fix for either or both issues would be much appreciated, as it would save a lot of time having to fix the records.

Quote from Tim Keating   on 05/03/05 at 07:35:45:

 
It is very disheartening how many of these little gotchas are in DBA.    SOP should be that no part of the transaction is committed until all of the transaction variables are validated. It would be better to lose the entire transaction when a problem occurs than to capture part of it and then waste time figuring out what to fix. I understand that the Serial module is separate from the inventory transaction module, but losing the one-to-one relationship between those two bits of data is a big issue in the eyes of our regulators.

There is a fundamental problem with the logic here I agree but unfortunately, the backflushing needs to be processed so that the associated component costs can be used in the calculation of the assembly cost.  This is why we developed the "B" default setting in SD-B for backflushing which means "Backflush the balance needed".  That way, if the backflush happens once and the transaction for Enter Finished production is not fully processed, when you go back in to process it again and it attempts to backflush, it will see that no component balances are needed and it wil not process the second backflush.

Fix one problem, create another...
 
If you change default setting to B, if you enter finished production for qty -1 (to disassemble a unit), nothing gets backflushed.

The ultimate problem with what Mike indicated, although he is absolutely right, is that to do so requires the ability to create TEMP tables, or some such solution, during processing and then wipe that info out and transfer the data to the permanent tables. However, in the non-RDBMS environment that is DBA this is a LOT of extra programing effort and has some pretty serious potential data transfer error opportunities.

I agree with Mike, the B option is great, but it should have some capability for negative receipts.

OK, next update will have a change so that if the default is set to B and you are processing a negative, it will act as though the default were set to Y and prompt to backflush and if you say Y it will process negative issues of the components so you can disassemble using negative work order.  
 
We have also disabled the ESC so that once the backflush has happened, you can't get out without completing the full process.  If you realize you made a mistake, you will have to go back in and process a negative.