Allen or someone else - hopefully a simple one...
 
When importing an EDI order, on the ED-B screen, after it imports the DBASO.IN file, it asks "Do you want to clear the DBASO.IN file?  If you hit yes, the DBASO.IN file stays in the directory (it is not deleted - it would be great if it did get deleted).  Would it be possible to make this work?  It would eliminate the need to manually delete this file before each new import, and simplify our EDI process immensely.
 
Thanks!!

I have that setting at Y and it still doesn't work.  The DBASO.in file stays there even when you tell it to clear it.  The only thing I can think of is that I changed the default directory that DBA looks into for the DBASO.in file.  I may play with that a bit before I flatly say that it doesn't work!!

I'll take a look..

Not to whip a dead horse into mush but.. since you did include some source code there...
 
You do realize that if we all had the source code we could debug ourselves, right?
 
For instance, in this case personal debugging would probably best go down this path:
 
First, reduce the source you posted to just:
 
msg "You have just imported " + trim(trim(str(head_cntr),'T'),'L') * " EDI SO headers, " + trim(trim(str(line_cntr),'T'),'L') * " EDI Line Items, and "+ trim(trim(str(note_cntr),'T'),'L') * " EDI Notes from "+trim(bkedi.mst.path,'T') * file_name * "  Importing now complete.  Proceed to view/edit in ED-C. " windows 'I'
 
 
    close @in_file
    if delf(path*'dbaso.in') = .f.
     msg "Error deleting "+path*'DBASO.IN' windows 'i'
    endif
 
This would remove all pertinent conditional expressions from the mix thus isolating whether the deleting statement is working. If it is then the conditionals I removed could be put back one by one until the problem is found (well, they should be commented out initially and uncommented in sequence but you get the point.) If, however, it still doesn't work then investigation into why not might be served by moving the message on failure out of the if block thus making it alway happen. Then the end user can see what path + file it's trying to delete.
 
All of this is to say, in the right hands end users having source can be a good thing. Some of us have enough experience with debugging to find the problem ourselves.

Allen,
 
Actually, DE-P-B  thru D are all running the T6 versions.
 

You were correct, the T6EDIB still had that bug, it was fixed in ISEDIB but not in T6, I just fixed it and sent to Lynn
The only difference between T6EDIB and ISEDIB is T6 lets you import 5000 lines and IS only does 500.