Performing an External Data Transfer 
Performing an External Data Transfer
Purpose
This component enables you to transfer data from a legacy or previous/feeder system to the R/3 system and process it in the R/3 system.
Prerequisites
Before starting external data transfer you must have selected the required data from your source system. Additionally, you must have specified the relevant system settings in Customizing of the respective component.
Process flow
Data is transferred from the source systems to the R/3 data pool in the following steps:
With the help of data selection programs you create a sequential input file (for example, as Excel file that you have to save in CSV format or as (UNIX) text file) to make the required data available for transfer. The data record structure in this file corresponds to the sender structure you define in Customizing. You have the following options for this:
The file has to be available on the presentation or application server. Within Customizing, you need to have entered logical file names for the physical file paths in which the files are stored. (Refer to the Implementation Guide (IMG) of the respective component under Platform-independent file name assignment). This helps avoid any later adjustments in connection with the respective operating system.
The data requirements of the R/3 system depend on the transfer categories and other Customizing settings. (Refer to the IMG of the respective component under Transfer categories, and in Treasury and in the industry solution for banks SAP Banking also under Display required/optional fields). Ensure that you do not supply two data records (or logical units in the case of header/item structure) on the same subject (for example, transaction) in one input file. For example, if you enter a new loan and change data of this loan soon afterwards, you may not deliver the resultant data records for transfer in the same sequential file. If the same data records are processed in the same block, (see below), runtime errors occur or there is an error entry in the log.
First of all the system checks the parameters assigned at the start of external data transfer. This involves checking the name of the transfer program (corresponds to the sender structure) and the date details. Then the input file is divided into blocks that are processed one after the other. All blocks first pass through conversion. Once this is completed without termination or conversion errors, the blocks pass through the function part.
Every program run starts with the import of the acquired data to an internal table. Then you can trigger a user exit for sender records (see the IMG of the respective component under Enhancements for external data transfer). Then conversion of the sender records to receiver records takes place in accordance with the transfer rules and, depending on Customizing, other conversions such as currency conversion. At this point, in some components there can then be a user exit for receiver records.
If an error occurs during conversion, the transfer is terminated. In this case, no data records are written to the database. The error is noted in the conversion log.
An error-free conversion process results in an internal table containing all the receiver records. The table is made available to external data transfer so that the function part can be carried out.
In the function part, the system also reads the receiver records in blocks and processes these one after the other.
First the system checks whether the delivered and converted data records are complete, logical and filled with permissible values. Incorrect data records are extracted and later forwarded to post processing. The system totally rejects a data record for a transfer category consisting of a header/item structure, even if only part of it is incorrect.
Correct data records are completed in an additional step. In this step, for some transfer categories the system enters certain empty fields (such as the transfer date and the time). Then the records are written in the data pool and the error handling routine is triggered.
The incorrect data records are written in an output file. You name this file when you start external data transfer. The program uses this name and adds other data to it. This helps to identify the output files at a later stage. The system also creates a detailed log for incorrect records.
With this, the program run is completed. If there is a program termination during the function part, you can perform a restart. For more information, see
You always have the option of repeating the entire external data transfer run. Records which have already been imported are recognized by the system and disregarded.
The system creates a log for every transfer - even an error-free one. This serves as basis for the correction of errors. Several functions are available for this. For more information, see
Evaluation of Logs.The following graphic explains the entire process flow of external data transfer from a technical perspective:
Result
The data from your legacy / previous systems is now in the R/3 data pool and can be processed in the R/3 system.
Special features of a release upgrade in some components
It is possible that a changed receiver structure is delivered with a new release. If a field is added, the system would not enter this field unless it is appropriately adjusted. It could be necessary for you to adjust the sender structure and the sequential input files or the transfer rules to incorporate the additional fields (see the IMG of the respective components under Transfer categories, in Treasury and in the industry solution for banks also in the Required/optional field display in Customizing.
If a field is removed, it is possible that an existing rule no longer refers to a target field. In this case, a transfer can terminate with an error message. For this reason, before other transfers, we recommend you first perform a test run and check the transfer rules. If you have entered complex rules for a transfer program, it is advisable to print these before a release upgrade.