Area: Options
Allows to set up options for program generation and File locations.
Sub-sections:

Program header
Allows adding/removing some attributes from the header of the programs that BIG Code Generator will generate.
Retrieving of client-side source files
Select if you want to use GUI_UPLOAD or WS_UPLOAD function to retrieve files located on the client-side. This parameter will not be saved as part of .BIG templates. Instead it will be saved as part of BIG Configuration.
Retrieving of server-side source files
When retrieving server-side files, select ENCODING additions for opening datasets; or type in your own additions to the OPEN DATASET. These additions will not be saved as part of .BIG templates. Instead they will be saved as part of BIG Configuration. When logging on to an SAP system, the application can change your selection based on the SAP version. SAP version prior to 4.70 does not support the ENCODING addition; and from 4.70 and higher the ENCODING addition is obligatory when opening datasets in text mode on a system which supports Unicode.
Naming Conventions
Click "Activate" to activate naming conventions for structures and variables defined for the ABAP source code generated by BIG. You can change these naming conventions to fit your needs. Naming Conventions do not apply for variables defined by the user nor for BAPI structures. These parameters will not be saved as part of the .BIG Templates. Instead they will be saved as part of BIG Configuration.

BDC session name
Use this field to name the batch input session (if a batch input session is to be generated) By default an automatic name based on .BIG format file name is generated.
Processing mode
Choose between sending all fields to a screen, or only non-empty fields. In case non-empty fields are sent, it is possible to set up a code for the empty value. Choose not to send empty-fields in order to minize errors like "the field nnnn does not exist for dynpro nnnn".

Input data when using fixed-width files
Use separate files for the main table and each step-loop/BAPI table, linked by a key to the main file (Default). A different file will be needed for each step-loop (when batch input) or each BAPI-table (when calling a BAPI), plus the main file. A key will relate the records from the step-loop/BAPI-table with the main records of the main file.
Use a single file with an ID in the first column: One file will contain all the information for data input. Two variants can apply when using this method:
Here is an example that uses a single file without a key (blue lines are not part of the file):
| Identifier (3) | Employee name (50) | Marital Status (1) |
| 001 | John Smith | M |
| Identifier (3) | Employee's children (20) | Age (2) |
| 002 | Carol | 5 |
| 002 | William | 2 |

Enable error-handling through a Z table
You must create a table to use this option. BIG will tell you which is the structure needed for this table. This table can be used for more than one program at a time (LINE field must be the largest needed), an a Program ID must be given to avoid conflicts with other programs.
Synchronization information when multiple programs work with this table:
When a program is running an if an error is detected (the first error only), the program searches for the last batch number used, and adds one to that number; with this new number the program saves the erroneous information. If two different programs search for the last batch number used exactly at the same time, they may take the same number (which is not so probable), however, there won't be any problem since they have a different Program ID. The batch number will be the same, but the two different programs will only reprocess their records. A problem may occur if the same program is running on two different machines and exactly at the same time they search for the last batch number, one of them will give the user an error when trying to save a record with the same key of the other program. You should evaluate how to handle this situation (a NUMBER RANGE would solve the problem; replace it if you think is necessary).
Why batch number is unique if it can be the same for different programs? Just because it's better for the user to remember one number, instead of a program and a number. Also when the user calls HelpDesk, he/she can give the batch number and the operator can find which was the program that generated it (if it is the same for more than one program the operator should also ask the user which was the program that the user was using).
Button for Files Location