Do you provide an F4 value help for File names so that user can browse through his PC directories to get the directory / file name? If answer is yes then very good, you didn�t irritate your SAP user.

But make his life better. Have you also given a provision so that user can manually enter a directory path and then F4 will directly open the given directory of his PC?

You might be creating batch sessions or an error report for the unsuccessful transactions, but �Test Run� can save a lot of hassles for the SAP users. It will help users in identifying the problems with the file beforehand and a lot of error processing effort can be saved.

How to implement it?
In case of BAPI interfaces it�s easier and almost full-proof ( Luckily, I realised and corrected, earlier I wrote fool-proof ). After the BAPI call check the BAPI return messages but don�t trigger a COMMIT WORK for a �Test Run�. Show the erroneous records in the report so that user can correct the file.

If you are using BDC call transaction then the recording will be slightly different for �Test Run� case. Just use �Back� in place of �Save� button to end the transaction. The results of this check might not be as correct as in case of BAPI since checks done by SAP at the time of save will not be carried out.

In case you need to check / validate file data-fields, try to provide an Application Log so that all unrelated problems with a record can be identified at the time of program run.

For example, say you are creating address records for business partners using File Upload and checking PO Box, Phone number & email formats before calling the BAPI. Since all these values are unrelated, you should check all these values one by one and add the messages to application log rather than exiting at the first encountered error. This will ensure that user will be able to correct most of the problematic values in the File. Otherwise user will run the file again after correcting the PO Box, only to find that Phone Number format is also wrong.

Did you realize that what will happen if user will try this option in production and get caught in middle of 3000 transactions to be processed in foreground? Poor guy will have no idea as how to get out of it and even if he does mange somehow, he will not have any clue as how many of 3000 records already got posted in the process.

A Fool with a Tool can be dangerous to himself and for everything else. Remember 9/11. Somehow, I am still not convinced that they actually wanted to hit the twin towers. I am sure they could not find the gap, they were searching for, between the twin towers.

For a developer, Error Mode / Foreground options are helpful in testing and debugging the problems but don�t pass it as a parameter in the program. Rather you can define it as a variable and change the variable values while debugging to process in foreground mode.

Your customer reported that he is not able to download the file on configured directory and program is terminating with some message like �File could not be opened� or �Directory not accessible�.
You tried from your side and everything is working fine.
So do you think that now your user is trying to irritate you like you did to him earlier?

Not really, just check out and there might be multiple Application Servers in production ( Use Transaction SM51 ) and probably the way you coded and configured file path, either you made it Application Server dependent or it is not accessible from all the application servers ( except from the central instance as this particular directory is only created on central application server ). e.g in FILE transaction, you have configured the file path as
�\\< INSTANCE>\Outbound� or �\\< HOST>\Outbound�

Now, since as a developer, you generally login to central instance, you will not be able to see the problem unless you deliberately login to other instances. Ask the user to run it from central instance for the time being and then modify you program to make the file path instance independent.

Provide a �End of File� indicator in the file so that other system program can determine that file is completely written by SAP and then only it will start further processing or else it should retry after a few minutes.

I understand your concern with the user and also that you probably want to implement less automation in order to save your users from being classified as redundant resource.

So do you want that user should check the spool file every 30 minutes or so to find if something has gone wrong? If not then implement the mentioned Functionality and also don�t send a message to the user who has scheduled the program.

He might be a Basis-guy and will re-boot the SAP system on slightest of doubt.

Rather create a Z Table and configure users to be informed against each program.

It�s better than asking the user to refer to the spool / error-report and then delete all the successful records first and further correct the error records before reprocessing.

It�s a little complex, but can be done. Check a sample program on my site and let me know if it does not work ( as usual ).

Not as yet. Good.

Now just pass on some documentation explaining what your program does and the steps required to run it. Also document the error processing for known cases.

Further, make sure that your documentation is written in a language that users can understand and is surely not ABAP.