IS-U Migration Workbench: User Handbook

The User Manual for migration provides an overview and support in the following areas:

Operating the LS>Migration Workbench Procedures in migration Performing minor modifications on the standard system Performing your own modifications

Detailed descriptions are available here. However the user handbook should not replace the F1 help in the individual function areas of the migration tool. You should always refer to the user handbook for the individual migration objects. The user handbook describes the following areas in detail:

General Here you can find information about the migration principle. Important basic concepts and structures are also explained.

Migration menu The menu is described with the individual functions. You can find detailed information about how to proceed with the menus.

What do In have to do during migration? Processes that you encounter frequently in the migration environment are described here.

Migration objects In this section you can find information about transfering certain constellations. You can also find information about structuring import files.

Defining migration objects This area describes all the neccessary activities for determining user defined migration objects.

Alterations to system scope In this section you can find documentation about alterations to already existing migration objects for every release. You can also find information about new functions.

1. General Information
In addition to the principle of data migration, this chapter describes some important basic concepts. This knowledge provides the foundation for all additional chapters.

1 Shosh Friedman

1.1. The IS-U Migration Principle

Migration is an open interface for transfering master data and transaction data to IS-U. The outflow is orientated around the target system IS-U. This means that the data model, or the function of the legacy system for migration is neither required nor used. The migration procedure cannot run based on tables, because of the relational SAP system data model and the considerable complexities it contains. Instead it has to compile related data in such a way as to guarantee consistency in the data after the transfer. The data is compiled into migration objects for the migration into the SAP application. In these units the data is transfered into the SAP system. At the same time, special service function modules have been created in IS-U for the business objects of this application. They make an object-orientated transfer possible. These modules operate in direct input mode and can thus avoid the perfomance disadvantages of batch input processes. The structure of a migration object is defined in controling tables delivered by SAP. It can consist of several SAP structures. You can find all the structures connected with a migration object in the dictionary. User-defined enhancements (fields) are taken into account at the same time. Data can be extracted from the legacy system using user-defined extraction programs. The exact record structure is determined per table settings in the Migration Workbench (transaction EMIGALL). Data sets that have been generated in this way, and transfered to your target computer by file transfer, are read and processed in the SAP system by the import program, which is generated by the customer system. The code conversion (EBCDID to ASCII) is carried out at the same time. The data is then formatted and transfered to the direct input module.

1.2. Migration Object Definition

A migration object is a logical business unit containing the data that is transferred to the SAP System during migration A migration object is described by one or more structures. As a whole they are called Auto data. They are predetermined by the service function modules being used; in the SA environment they are defined via the dictionary. Example Migration object business partner Migration object connection object Special migration objects are the BDC migration objects, which can be created through batch input recordings during migration, and the Hyper Migration Objects for which data of several migration objects is summarized in one import file.

1.3. Automation Data Definition

--------------------------------------------------------------------| Automation data specifies the quantity of all fields of a | migration object, as well as its structural order. --------------------------------------------------------------------| |

The automation data is clearly predetermined by the interface of the function module being used.

2 Shosh Friedman

1.4 Field Rule Definition

----------------------------------------------------------| In IS-U Migration, field rule denotes the |

| unique rule basis, with which an individual automation | | data field is processed during import | ----------------------------------------------------------Examples of field rules are:

Initial value (allocating the typical initial value) Supplying a constant value ( Fixed value) Allocating a value transfered from the legacy system Executing a series of ABAP statements (complex field rules) Mapping through a conversion table

1.5. Fixed Value Definition

---------------------------------------------------------------| In IS-U migration, a fixed value is a definition of a | generally used assignment of a constant value | or table content | ---------------------------------------------------------------Examples of fixed values are: | |

The constant for the field company code (for example '0001') The constant for the application of contract accounts receivable and payable The current date (field content sy-date) The logon language (field content sy-langu)

A fixed value can be used in several Field Rules and is suitable for the uniform supply of fields with the same meaning.

1.6. Conversion Object Definition Definition

In IS-U migration, a conversion object refers to the definition of a generally applicable modeling rule for a set of discrete input values to output values. The data category and field length of the input field can be set independently of the target field.

Examples
Conversion objects can be used for:

3 Shosh Friedman

Mapping the industry key in the legacy system to the industry in IS-U Converting the company code from RIVA (e.g. from "01" to "0010") Mapping the values from a check table in the legacy system to the values in an IS-U check table

A conversion should be used when no clear fixed value can be set, and when creating an ABAP rule as a CASE distributor would take too long. A conversion object can be used in several field rules, and is therefore suitable for supplying fields with the same meaning.

1.7. Other Important Terms

1. Company Migration customizing is an client independent application. The Company represents the project to which migration objects are allocated. In order to work in various clients with their own migration configurations, different companies have to be created. The required migration objects can then be copied for each company. The company SAP serves as a reference configuration. SAP delivers the individual migration objects; they are overwritten when an IS-U upgrade takes place. 2. Migration class The migration class defines the business object. A migration object is based on the business object. In this way you can, for example, give the SAP migration object ACCOUNT its own name when you copy it. Now, when you transport settings, you can still recognise that the operation involves the migration object ACCOUNT. 3. Customer structure Using migration customizing you can allocate certain processing rules to parts of the auto data. You can also allocate the rules to the auto data fields. In this way you can determine which fields must be available in the data records of the import file. These fields form the customer structure, which you can display via the menu Utilities - Display customer structure. You can display the customer structure in either list or layout form. 4. Key and status management (KSM) In order to structure the database-key relationship between individual objects, the IS-U key for the data object must be transfered within the data records. The KSM administrates the relationship between the legacy system and the IS-U key, so that the extraction program in the legacy system can work with the available keys. 5. Event The load report for a migration object is not delivered, but generated in the customer system. Here you have the opportunity to include your own coding at certain points in the report. These points, and the exits defined here, are called events.

4 Shosh Friedman

1.8. Special Technologies

The following sections involve the application of special techniques during the data import.

Higher-Level Migration Object

The legacy system keys are replaced by the corresponding IS-U keys through Key and Status Management (KSM). The following techniques can be used in this process: Specify a higher-level migration object in the field rule The field in the automation data is supplied with the legacy system key of the specified higherlevel migration object, and the value in KSM is replaced by its allocated IS-U key. To do this, the object with the specified legacy system key must have been successfully migrated first. If no IS-U key can be determined in KSM, then message EM 102 is written to the error log. Specify several higher-level migration objects in the field rule The field in the automation data is supplied with the legacy system key of one of the specified higher-level migration objects. KSM attempts, in the specified sequence, to determine an allocated IS-U key. The first IS key that is found replaces the value that is passed on in the automation data. If no IS-U key can be determined for any of the specified higher-level migration objects, message EM 102 is written to the error log along with the last specified higher-level migration object. To achieve the best performance, you should specify the higherlevel migration objects in the order in which they will most likely allow an IS-U key to be found in KSM. Specify a higher-level migration object in the automation data You can also specify the higher-level migration object for a legacy system key in its automation data. To do this, set the Gen. KSM ObjFld flag in the field rule, which causes an additional field "o_<field>" to be generated in the automation data structure, where <field> stands for the field name of the higher-level migration object in the automation data structure. Any entry in this field overrides the specifications for the higher-level migration object specified in the field rule. If the additionally generated field is not supplied with data in a record, then the higher-level migration object from the field rule is used to determine an IS-U key in KSM. This method makes sense, for example, when master data was defined in IS-U with different migration objects and the same legacy data key, and this master data is referenced in an additional migration object. Using the KSM check indicator You can use the KSM check indicator to prevent the IS-U key from being determined in KSM. To do this, set flag Gen. KSM indic. in the field rule, which generates an additional field k_<field> in the automation data structure. <field> stands for the field name of the higher-level migration object in the automation data structure. If the field in the transfer structure is set (contents: capital letter "X"), then a check is performed with the KSM using the methods described above. If the field is not set, then the contents from the higher-level migration object is used as the IS-U key without any further check.

Lock Objects During Data Import

Locks prevent data from being imported, which cannot be consistently imported (for example, data is chronoligically incorrect) for a restart or due to faulty data in previously processed data records. The indicators Check Object for Locks and Lock Object can be set using field rule KSM. This rule checks locks on objects and sets locks where necessary. The indicator ObjLockMech. (Activate Object Locking Mechanism) must be set in the parameters of the migration object.

5 Shosh Friedman

Locks are only effective during an import run (work process). Message EM 101 (data record already imported) means that no locks are set, because if an import occurs without errors then no locks need to be set. Example Import file with the following data records (DR) for a hyper object with referenced migration objects INST_MGMT and DEVICEREL: DR 1: 01.01.1999 Installation of device G1 in installation A1 DR 2: 01.01.1999 Installation of device G2 in installation A1 DR 3: 01.01.1999 Create device relationship betwen devices G1 and G2 DR 4: 01.01.2001 Delete device relationship between devices G1 and G2 DR 5: 01.01.2001 Removal of device G1 from installation A1 DR 6: 01.01.2001 Removal of device G2 from installation A1 The indicators Check Object for Locks and Lock Object are set in the field rule for field INTERFACEINSTALLATION for the referenced migration objects INST_MGMT and DEVICEREL respectively. If an error occurs, such as incorrect data format, when creating a device relationship with the import of data record 3, another error occurs without locks if you attempt to delete the device relationship (data record 4). The subsequent data records 5 and 6 are imported without errors or locks. A restart is not possible after correcting the date, because installation dates must be imported chronologically. If lock indicators are set, a lock on installation A1 is active in data record 3. This lock indicator prevents subsequent data records 4 to 6 from being imported, with reference to locked installation A1. Additional locks on devices G1 and G2 can, for example, prevent modifications to these devices, in other data records.

1.9. Data Import Program: Method of Operation

The IS-U migration load report consists essentially of an initialisation module, a read loop and for legacy system data records in the sequential import file and a final processing. Various actions are carried out for a start event, such as:

Checking the object and the object's blocking status Determining the code page of the SAP system Opening an application log for the current run Trial reading the import file and the error file Structuring a template of the valid data types Deactivating some of the functions in the service modules

The main processing loop consists of one loop, which, depending on the hierachical structure of the auto data, can contain additional loops. In this loop are FORM calls, which contain the field rules, specific to the objects, of the individual auto data structures. After all these loops have been processed, the structure AUTO (object auto data) is filled with the transfered data and the service function module is called.

6 Shosh Friedman

After leaving this function module, the return code is queried. Depending on the result, the KSM is provided with the given key, or the error that has appeared is saved in the application log. In the end event the relevant files, application log and migration statistics are closed.

1.10. Naming Conventions in the Migration Environment

In the IS-U migration environment the following naming conventions apply: Control tables -> TEM* Work tables -> TEM*

Workbench Programs -> REMIG*, SAPMEMIG* Function groups -> EMIG* Import program Import variants ABAP/4 Include -> RE3TR_cmp_obj -> MIG_nnnnnn -> RE3DAALL data for all objects

-> RE3DA_cmp_objn object specific Data -> RE3FOALL cross-object form routines

-> RE3FO_cmp_objn object specific form routines -> RE3IN_* object-specific includes

Dictionary structures -> EMG_* Migration fixed values -> EMG_* Documentation -> EMIG_cmp_objn (migration object)

-> EMIG_cmp_objk_nnnnnn (structure or field) The following abbreviations apply here:

o o o o

cmp

: company

objn : migration object objk : short description migration object nnnnnn : internally placed number

1.11. Important Include Reports in the Migration Environment

When a load report is generated in the migration workbench, the report RE3TR_<cmp>_<abbr> is created. <cmp> represents the name of the company; <abbr> is the three-character representation of the migration object. In addition to the load report, two includes are generated:

7 Shosh Friedman

Data include RE3DA_<cmp>_<abbr> In this include the customer structures for the migration object is defined. These structures are called z_<strucname>. <strucname> represents the name of the partial structure for the auto data.

Form routine include RE3FO_<cmp>_<abbr> In this include the field rules are stored as code. The individual subprograms are called FILL_<strucname>. <strucname> represents the name of the partial structure for the auto data.

Remarks: The data include RE3DA_<cmp>_<abbr> can also be used to create your own reports, which process data created as migration import files. However, you must ensure that the RE3DAALL include,which contains general definitions for migration, is also included.

1.12. Sequential Import Files

The following IMG activities deal with the sequential data sets that are to be created by the unload program. They explain the physical structure and the various record types.

Physical Structure
The import file is a sequential file in which the data records of a migration object are kept in a particular sequence. The only format that is currently available is the "binary file" format. In order to control the file import into IS-U, all the data records for an import file are identified. This is possible because each data record begins with two fields. The corresponding information from the upload program in the legacy system must be entered in these two fields. These are:

A thirty-place character field (OLDKEY): You must enter the legacy system key for the data object in this field (for example the customer number in the legacy system). In IS-U migration it is denoted by OLDKEY. Using this field, several data records can be grouped together around one data object (for example a business partner).

A six-place character field (DTTYP): This enables you to identify the record type (structure, data record, etc.). In IS-U migration it is denoted by DTTYP or data type. This field assigns a special structure to the data record and creates a relationship with the structure. The data must then be arranged in accordance with the structure.

Every data record is structured as follows: Record length Old key Data type Data HEX 2 CHAR 30 CHAR 6 (lgth of corresp. structure)

The record length specifies the offset for the next record length field (the length of the data structure plus 36 bytes for the old key and DTTYP, plus 2 bytes for the record length field).

8 Shosh Friedman

Various Record Types

The following special data records exist in the import file: 1. Header record : This has to be the first record in the import file. It can only appear once and has the following structure: Record length Old key Data type Data HEX 2 X'004F' CHAR 30 CHAR 6 (Length of corr. structr) (space) &INFO (Cust. structure data) The migration object and company are included in the data part of the header record. These are checked against the current selected company and migration object for the data import. In addition, the user name, date and time can also be transfered as information fields (you must take the exact structure from the dictionay structure TEMINFO). 2. Actual data records : The data is transferred in records. They have the following structure: Record length Old key Data type Data HEX 2 CHAR 30 CHAR 6 (Lgth of cust. struct.) Length(hex) Old key Dt. cat. (Cust. strctr. data) The length must correspond to the length of the data in the customer structure, plus 38 bytes (for record length field, OLDKEY, and DTTYP). A legacy system key must be entered for old key. It must be unique to an individual migration object. The value that you enter in the data category field is defined in the context of the module structure for the auto structure. The structure and length of the customer structure is the result of customizing for the corresponding SAP structure. You can view it in Utilities - Display customer structure . 3. Final record for an individual data object This record identifies the end of data record for a data object. After the data records of a data object the final record must be present. It has the following structure: Record length Old key Data type Data HEX 2 X'0026' CHAR 30 CHAR 6 (space) &ENDE (0) (space)

1.13. Data Formats

When loading, the transferred data is partly processed differently dependending on the R/3 data category. Note the following rules and comments:

CHAR: Character fields

o o o

Value range: All alphanumeric characters Check: No check Conversion: No conversion, except conversion to capital letters, if the field does not support either upper/lower case letters or the execution of conversion exits.

NUMC: Numeric Character

o o

Value range: Numbers, spaces Check: Check on value area

9 Shosh Friedman

Conversion: After executing the field rule, the transferred value is displayed in a valid format (right justified with leading zeros)

DATS: Date fields

o o o

Value range: Characters in format YYYYMMDD Check: Check on correct date format and date validity Conversion: None

TIMS: Time fields

o o

Value range: Characters in format HHMMSS Check: No check on field content

DEC: Packed fields

Value range: If external format (screen format) is set, characters (dependent on the field definition), commas, +/- sign, period, and +/- sign after the decimal places are permitted. If internal format is set, a valid packed format must be transferred (for example 0001234C) Note: External format should be used in principle.

Check: Check on valid characters

CURR: Amounts in a particular currency

o o

Value range: Same as for data category DEC Note: All currency amounts must be transferred with the correct number of decimal places for currency because there is no internal conversion. For example, 100BEF or 100.00 DEM.

INT4: Integer fields

o o

If you select external format in the field rule, only numeric characters are permissible. If you select internal format, the transferred value must be a binary string

Conversion exits

If a field contains a conversion exit, it is executed after execution of the field rule (external -> internal).

10 Shosh Friedman

2. Migration Menu
This chapter contains the description of the menu items in the Migration Workbench.

2.1. Transaction EMIGALL- IS-U Migration Workbench

With the exception of the data transfer into the SAP System, all data migration functions are transactioncontrolled. Transaction EMIGALL (referred to in the following as the Migration Workbench ) is provided for this purpose. The individual functions of the Migration Workbench are described in the following sections. Note The functions of the Migration Workbench are valid for all clients. Only the data import must be performed in the target client.

2.1.1. Menu Option - IS-U Migration This menu item groups together the functions that are generally valid for migration.

Other company
This function allows you to change the company. Enter the company name in the displayed window. All the migration objects for the selected company are displayed after you press "Enter".

Company maintenance
This menu item is used to maintain the companies used in the migration. A migration object is always defined for a company. The standard company SAP may not be changed.

Project Maintenance
This function supports the selection of migration objects and Customizing with the help of a question catalog.

User parameters
With this function, individual settings can be configured and saved for a specific user in the IS-U Migration Workbench.

Settings
Use this IMG activity to set migration control parameters. These parameters are used to individually affect certain functions within the service modules.

Customer settings
This IMG activity is used to display the customer settings from the migration control parameters. The customer settings override the SAP settings. The settings can be used globally for the company or for the company and object.

11 Shosh Friedman

SAP settings
This IMG activity is used to display all supplied SAP settings of the migration control parameters. The customer can only display the SAP settings in his/her system.

Maintain migration class

Migration classes are categories supplied by SAP that are assigned to a migration object. They allow two different migration objects to be created for the same business object. The migration class currently only defines the function modules used during the display from KSM. The migration classes that are supplied by SAP may not be changed.

Information System
Various information is available in this area menu.

List of migration ojects

The migration objects of a company are displayed in a list. The list can be sorted according to migration object and migration class.

Key and Status Management

Key and Status Management is used to manage assignments from old key to new key (assigned in ISU). The KSM is displayed for each migration object. You can limit the number of key assignments to display. You can also display the data object in the usual display transactions, regardless of the underlying business object.

Display migration statistics

A statistics record is written for each run of a migration report, and is updated continually during the runtime. The migration statistics record runtime information, current old key, the total number of processed data records, the number of incorrect data records, and other important information. You can use this function to display these statistics. From this display, you can also display the error log and (in the case of batch runs) the job log.

Display Messages
The migration workbench news is intended to draw your attention to the most important changes made to existing migration objects, or to new migration objects imported via AOSP. The messages are automatically displayed when you start the migration workbench. You can deactivate this setting in the user parameters.

12 Shosh Friedman

User handbook
The existing user manual is displayed. You can also display the manual outside of transaction EMIGALL by starting report REMIG000 or by calling transaction EQ81.

Symbol/color key
Displays explanations of the screen symbols.

2.1.2. Menu Option - MigObject This menu item groups together all the functions that are performed at migration object level.

Create
This IMG activity is used to create a new migration object. Because determining and defining the involved structures and modules is usually an extremely complex task, we highly recommend consulting with SAP before you begin this activity. Guidelines for creating migration objects are available in chapters

Creating a Migration Object

You must carry out the following steps to define a migration object: 1. Fix the desired functions of the migration object (for example, the function "create entries for table XYZ999") 2. Check whether there is already a function module that offers this scope of functions or whether you have to create a new function module for the required function. 3. Check the interface for the function module a) Are there unique interface parameters for auto data? b) Are there return parameters that return the key for the newly createdtable entry? c) In what form are possible mistakes returned (sy fields, exceptions, IS-U message objects) ? 4. Structure of the migration object via the menu item Migration objekt - create, using the data for the service function module being used, as well as the transfer and return structures

Creating a BDC Migration Object

BDC Migration Object (Batch Input Migration Object)

A migration object that was created using a batch input recording in the IS-U Migration Workbench. Batch input, or BDC (batch data communication), is a standard technique for processing SAP transactions in the background. When a BDC object is created, an auto data structure is generated in the background. All the fields contained in the recording are assigned a field rule of processing type 3 (move). BDC objects do not use the conventional direct input technique. Instead, they use the 'CALL TRANSACTION ... USING itab' technique. Otherwise, the use of these objects is largely the same as the other migration objects.

13 Shosh Friedman

To define a BDC migration object, perform the following steps: 1. Select a transaction with the required scope 2. Record this transaction using the Batch Input Recorder (Transaction SHDB) 3. Create a migration object (menu path: Migration Object -> Create) Select a name for the migration object and the required recording (for example re-record a transaction) 4. The recording data is then displayed in an overview. If all the fields were not automatically set when the recording was copied then you must allocate field names to these fields manually. 5. Save the recording data. This creates the migration object, allocates the service module and generates both a dictionary structure and auto data from the fields. 6. Allocate a short description 7. Save the migration object Notes The system creates a field value with the processing type 3 (move) for all the fields in the auto data. To store the newly created keys in KSM, you can store a message number for the migration object, as well as the variable to which the transaction returns the number of the newly created object.Otherwise the system always uses the internal DB_UPDATE field (database updata complete) to update KSM.

Creating a Hyper Object To define a hyper object you must complete the following steps: 1. Specify the required features based on the migration objects already created in the migration company. 2. Create the migration object via menu option Mig. object -> Create and enter migration class hyper. You do not need to enter data for service function modules and transfer/return structures because they are generated automatically. 3. Create auto structures via menu option Automatic structure -> Create. You can choose between Automatic Structure Category: Substructure and Automatic Structure Category: Migration Object for a hyper object. When creating the stuctures, note that the names of the data types also have to be unique within a hyper object. Therefore, you must adjust the data types in the automatic structures of the referenced migration objects before you create the structures as Automatic Structure Category: Migration Object. 4. Generate Load Report. Note the restrictions for Maintenance of Hyper Objects and Maintenance of Referenced Migration Objects. SAP recommends that you activate the locks for dependent object data, when importing data for hyper objects. Locks prevent the import of data that cannot be consistently imported for a recall or due to incorrect data in the previously processed data records. See Special Technologies for a description of the lock concept.

Hyper Migration Object (Hyper Objekt)

A hyper object is a migration object with the migration class HYPER. You can use a hyper object to import the data of several migration objects with one import file. In this way, you can import dependent data that is described in separate migration objects at the same time. In a hyper object you can create references (auto structure type MigObject) to existing migration objects. The settings for the referenced migration objects are transferred to the loading report for the hyper object when the hyper object is generated. Examples for the use of hyper objects:

14 Shosh Friedman

Installation data history (device installation, removal, assignment...) Business partner data (business partner, contract account, relationships between business partners, etc.)

For information on the creation of hyper objects and the restrictions that apply to them, refer to Create hyper object.

Change
Calls the maintenance function for the selected migration object. Please refrain from changing the supplied (standard) definition of a migration object. The only modifications that are required during the migration are changing the blocking status and the settings for termination control. If you want to use customer exits, you can define these exits in for the migration object in change mode under Utilities -> Events. For more information, please refer to the chapter title Create Customer Exits in Migration Report. Create Customer Exits in Migration Report.

The IS-U load program offers the opportunity to include user-defined codes (events) at certain, exactly defined points in the program flow. This can be used, for example, to carry out additional changes in the auto data fields before a data object is created, or to perform additional actions after a data object has been succesfully created. When you generate a load report, these events are written into the program. In this way you do not have to manually re-enter them each time you generate a new load report. The following event categories are available:

Function: Call function module You can call the function module you have specified with CALL FUNCTION. You can provide the function module interface with parameters via a variant.

Perform: Call subprogram (FORM) You can call the FORM routine you have specified with PERFORM. If you have to provide parameters, you must create a variant. You must ensure that the FORM routine is in a userdefined include, which must be included via an event.

Include: Insert an include statement You include the include you have specified with INCLUDE.

Coding: Insert ABAP statements The ABAP statements that you want to insert have to be entered in the "Coding" field, and the "Change coding" function key has to be defined to the right.

After the event, you can add more coding. You must ensure that the included objects are available and free of check errors. Data declarations you have used may still have to be created as an event.

15 Shosh Friedman

The standard system already uses events to include general functions, as well as to generate object specific actions. They cannot be changed or removed. Special coding can be inserted in the load program immediately before the call of the subprogram entered in the event. You must assign a name to this special coding in event maintenance. The coding that is generated in this manner can be used in different events for the load program of a migration object (you specify its name). The standard package also uses events, both to include general functions and to generate objectspecific actions for the load report. You may not change or delete these standard events. Enhancements are currently supported for the following events:

INCLUDE Including include statements at the start of the report

CSTINCL Including additional include statements at the start of the report

START Before the data records are imported and processed

READ01 Importing a data record

FILL01 Before processing the field rule for a data record

FILL02 After processing the field rule for a data record

OTHERS Changing the data type

READ02 End of the processing loop for a data type

SERVI01 Before the service function module is called CALL01 Directly before the service function module is called CALL02 Directly after the service function module is called

SERVI02 After the service function module has been called

16 Shosh Friedman

SERVI03 After a data object has been created

LAST End processing of a data object

END Actions after the last data record has been processed

Special functions provided The migration package includes two subroutines that can be used for special functions in the events.

Subroutine (FORM) BREAK This event can be added to any generation location and processes a break point.

The events

Subroutine (FORM) DUMMY and CODE still exist for compatibility reasons. They are used to add coding WITHOUT a separate function module or subroutine. It has the same function as CODE, and is used only to ensure backward compatibility for existing events. The functionality has been replaced by the new event type CODE.

Display
The definition of the selected migration object is displayed.

Copy
This function copies the selected migration object with all its settings to a migration object

In the same company with a new name In another company with the same or a different name

This transaction copies the definition of the migration object and its automation data, all field rules, and all documentation to the target object. You must specify the name of the company, the name of the migration object, and the new abbreviation of this transaction.

Display object documentation

Documentation may exist for a migration object. This information could describe technical aspects or processing tips, such as dependencies and requirements for importing the respective migration object. If documentation is available for an object, it is displayed with this function. All the documentation objects for a migration object can be displayed with menu item Migration object Display manual.

17 Shosh Friedman

Display manual
All the existing documentation for a migration object can be displayed together. All the structure components of the automation data and all the fields contained therein are displayed. You can display both the F1 help (defined through its data element) and the migration documentation for each field. The migration documentation can also be printed.

Display Filter
All migration objects of a company are normally displayed by calling up the ISU Migration Workbench. You can hide certain objects from the company view. Use function Hide/Display to hide individual objects. This function only considers selected objects. Use function Set Display Filter to hide several objects.

Show/hide
In the default settings, all the migration objects for the selected company are displayed. You can, however, specifically exclude (hide) individual objects from the display. This IMG activity allows you to toggle between hide and display for the selected object. Note You can use IMG activity Set Display Filter to transfer this setting globally for all the company's objects.

Set Display Filter

This IMG activity is used to determine which migration objects must be displayed. It can be configured as user-specific and company-specific. Example The user only works with the transfer of technical device data. The user sets all objects with the exception DEVICE or INST_MGMT in his filter to hidden.

Display list
The display of migration objects in the IS-U Migration Workbench can be influenced by various settings. This enables you to adjust the level of detail displayed. The default setting when the IS-U Migration Workbench is called is to display all the migration objects.

All
This function displays all the migration objects for a company. Objects that have been hidden are also displayed.

Hidden On/Off
In the default settings, all the migration objects for the selected company are displayed. You can, however, specifically exclude (hide) individual objects from the display.

18 Shosh Friedman

This function switches from the display of all objects to the display of all objects including objects you have hidden. In the latter display, objects that have been hidden are indicated by a different background color.

Generate Report
The Load report for a migration is generated from the settings in the Migration Workbench. In the process, the field rules are translated into ABAP coding. The load report must be generated again after every change to the migration customizing for a migratino object. This is symbolized by an icon that appears next to each migration object. As soon as the load report is outdated (i.e. settings in the field rules were changed, for example), a yellow icon is displayed. No data import is possible with this status. The header of the report contains the generation time and generating user in comment lines. The load report for the selected migration object is regenerated by this function.

Data Import
This function can be used to call the data import for the selected migration object. The import can only be started when the load report for the migration object is current (indicated by the green icon).

More Functions
Further functions for the selected migration object are available via this submenu.

Display Report
The generated load report is displayed in the ABAP editor.

Check Customizing
When you transport migration Customizing, object inconsistencies may occur if, for example there is no fixed value definition in the transport target system. This function checks the selected migration object for completeness.

Compare
You can use this function to compare the selected migration object with another migration object. In the process, all the data - object definitions, automation structure definitions, field rule definitions, and migration events - is compared. You can perform the comparison with an object of the same company or a different company in the same system, or even across system boundaries if you specify an RFC destination.

19 Shosh Friedman

2.1.3. Menu Option - Auto structure This menu item groups together all the functions that are performed at the level of an individual part of the auto-structure.

Create
The supplied migration objects contain the complete auto-structure that can be processed by the involved service function modules. As a result, it is not necessary to create new structures, and the fields contained therein cannot be migrated despite their definition. Therefore, the function is only used in connection with creating new migration objects or modifying the service modules used.

Change
You can change the default settings of some migration objects with the result that some structures are ignored during the import. To do this, you must exclude the respective part of the auto-structure from generation (Reset the "Generation indic." field).

Display
The definition of the selected part of the automation data is displayed.

Display structure documentation

Documentation may be available for a part of the automation data of a migration object. This information may contain technical aspects or processing tips, such as whether data records with this structure must be present in the import file, or whether they can be copied only once or more than once. Any available documentation is displayed with this function. To display all the documentation objects for a migration object, select menu item Migration object Display manual.

Display list
The display of the automation data in the IS-U Migration Workbench can be influenced by various settings. This enables you to achieve different levels of detail in the display. The default setting for the IS-U Migration Workbench is to only display structures - but no fields - and to only display those structures that will be taken into account during report generation.

All
This function displays all the components of the automation data for the selected migration object. In the process, it does not matter whether fields or structures are involved. Components that have been specifically excluded from generation are also displayed.

Fields On/Off
20 Shosh Friedman

The components of the automation data that have been defined as fields are displayed. These are usually control fields that ensure that the interface of the service module is supplied with the correct values. Accordingly, these fields are not relevant for editing.

Nongenerated On/Off
The display of the automation data usually only includes the modules that are used during report generation. This function enables you to also display the non-generated components.

Field Rules of Structure Compare with DDIC

This function compares the fields of the Dictionary structure with the field information in the migration tables for the selected automation data structure. If a field has been added (e.g. through an upgrade or customer enhancement), then this field is added to the field list. Likewise, a field that is no longer defined in the Dictionary is deleted from the list. To call this function for a company or a single migration object, choose the following menu option: Utilities - Further Utilities - Total Comparison with Dictionary. This is especially recommended after a system upgrade.

2.1.4. Menu Option - Field This menu item groups together all the functions that are performed at the level of a single field of the auto-structure.

Create
The fields used in the IS-U migration are determined by the Dictionary structures of the automation data. If new fields are added (through customer exits, for example), then these are added to the field list through the "Compare with DD" function. In addition, you can also define customer-specific fields that can be used to pass on data to the load report. These fields are not processed by the load report; they can be viewed in a different field through a complex ABAP rule. Examples of this include very long character strings, which are chopped up into components and written to the appropriate fields in the IS-U environemnt (see chapter Transfer Customer-Defined or Additional Fields).

Change
The main instrument of IS-U Migration customizing is field maintenance. This function is called for the selected field. In the process, each field of the automation data is assigned a field rule (the default value for blank field rules is "Initial value"). This function calls field maintenance for the selected field. In addition, this function allows you to determine the following information for the edited field:

Technical information (field type and length, conversion exits)

21 Shosh Friedman

Documentation objects (IS-U Migration and Dictionary) Valid value ranges (check tables and fixed values) ----------------------------------------------------------| In IS-U Migration, field rule denotes the

| unique rule basis, with which an individual automation | | data field is processed during import | ----------------------------------------------------------Examples of field rules are:

Initial value (allocating the typical initial value) Supplying a constant value ( Fixed value) Allocating a value transfered from the legacy system Executing a series of ABAP statements (complex field rules) Mapping through a conversion table

Display
Displays the field rule for the selected field.

Display field documentation

Migration-specific documentation may be available for a migration object field. This information is different from the normal field documentation (through the data element). It describes technical aspects or processing notes that are only valid for the migration period. The (migration) documentation is displayed with this function. To display all the documentation objects for a migration object, select menu item Migration object Display manual.

Display field documentation: DDIC

This function displays the documentation of the dictionary field. This is the information that comes from the data element, e.g. the data that is displayed when you select F1 help for the field.

Display list
The display of the fields in the IS-U Migration Workbench can be influenced by various settings. This allows you to achieve different levels of detail in the display. In the default setting, only those fields that will be taken into account during report generation are displayed.

22 Shosh Friedman

All
This function displays all the fields of the selected structure of the automation data- regardless of their relevance to migration. Fields specifically excluded from generation are also displayed.

Nongenerated On/Off
The field display normally considers only those fields that are used during report generation. With this function, you can also display the non-generated fields.

Non-Migrated Fields On/Off

The field display does not usually consider the fields of an automation data structure that are not relevant for migration. With this function, you can display the non-relevant fields as well.

Sort list
With this menu option, you can affect the sequence of fields in the field list.

By field position
The fields of the selected part of the automation data are displayed in their defined order, in accordance with its position in the underlying Dictionary structure. This is merely a display variant; no physical changes to the migration tables are made.

By field name
The fields of the selected part of the automation data are displayed sorted in alphabetical order. This is merely a display variant; no physical changes are made to the fields of the migration tables.

Position as DDIC
If a field is added during the comparison with the active Dictionary structure, then this function allows you to take the correct position of the field into account during the migration as well. If the new field was appended to the end of the structure, this function has no effect.

23 Shosh Friedman

2.1.5. Menu Option - Utilities This menu item groups all the utilities functions together that are either generally valid or performed at the migration object level.

Maintain fixed values

The concept of fixed values ensures that fields in different migration objects are supplied with uniform data. Fixed values can be defined in field maintenance and through this function.

Maintain Conversion Objects

The concept of conversion objects was created to uniformly supply the fields in the different migration objects in accordance with a clear mapping rule. The conversion objects can be defined in field maintenance or using this function.

Structure display
With this menu option you can display descriptions of the structures used for import.

Display Customer Structure

This menu item generates a list that displays all the data for the customer structure. This structure is the result of the migration customizing, and represents the foundation for the import file. The different data types are displayed in the list. The data fields that are expected in the import file, together with ABAP type, field length, and processing type, are specified for each data type. You can also display layouts of the individual data records or a sample import file. You can also navigate to the field rule display of any field. The list can be downloaded to an external application (e.g. spreadsheet program or external mapping tool). The data records of the import file must be structured as required by this list. The data records of the import file The following special data records exist in the import file: 1. Header record : This has to be the first record in the import file. It can only appear once and has the following structure: Record length Old key Data type Data HEX 2 X'004F' CHAR 30 CHAR 6 (Length of corr. structr) (space) &INFO (Cust. structure data) The migration object and company are included in the data part of the header record. These are checked against the current selected company and migration object for the data import. In addition, the user name, date and time can also be transfered as information fields (you must take the exact structure from the dictionay structure TEMINFO). 2. Actual data records : The data is transferred in records. They have the following structure: Record length Old key Data type Data HEX 2 Length(hex) CHAR 30 CHAR 6 Old key Dt. cat. (Lgth of cust. struct.) (Cust. strctr. data)

24 Shosh Friedman

The length must correspond to the length of the data in the customer structure, plus 38 bytes (for record length field, OLDKEY, and DTTYP). A legacy system key must be entered for old key. It must be unique to an individual migration object. The value that you enter in the data category field is defined in the context of the module structure for the auto structure. The structure and length of the customer structure is the result of customizing for the corresponding SAP structure. You can view it in Utilities - Display customer structure . 3. Final record for an individual data object This record identifies the end of data record for a data object. After the data records of a data object the final record must be present. It has the following structure: Record length Old key Data type Data HEX 2 X'0026' CHAR 30 CHAR 6 (space) &ENDE (0) (space)

Display SAP Structure

This function displays all the fields of the automation data in a list. All fields with a processing type other than "Initial" - that is, the fields that will be involved in the IS-U migration, are highlighted. This information gives you a global overview of the entire migration object, which can also be downloaded for external use.

Export: Record Descriptions

Using this function you can generate a description of the structures required during an import with instructions in a programming language (for example COBOL, C, or ABAP). This list can then be saved locally in order to support the developers of the upload program in the legacy system, for example.

Copy Migration Object

Using this function you can copy several migration objects from the current company to another company simultaneously.

Delete Migration Object

Using this function you can delete several migration objects from the current company simultaneously.

Transport Migration Object

This IMG activity contains the functions for transporting migration objects. There are two transport options: 1. Transport all the settings of a migration object by PC download and upload. 2. Generate a transport request in the Change and Transport System (CTS) with the settings of as many of a company's migration objects as you require.

Create Tranport Request

In this IMG activity, you transport a company's migration objects.

25 Shosh Friedman

To do this, select the objects you want to transport from the company's objects. These objects are then included in a transport request in the CTS (Change and Transport System). Based on the transport control settings you have established, the definitions and values of the fixed values and conversion objects used in this object are transported. There are other objects you can include in the transport request, such as fixed values that are not used in the transported objects. This applies to all fixed values, conversion objects and ABAP includes. There is also a simulation mode that lists the transport functions, as well as the workbench organizer, in which you can further process the transport request you have generated. Special features are valid for the tranporting of hyper objects and referenced migration objects. Special Features of Hyper Object Transport The following special features apply to the transport of hyper objects and referenced migration object. 1. When transporting a hyper object, you must always include the referenced migration objects of this hyper object in the transport request. 2. When transporting a migration object, you must always include all hyper objects referencing the migration object in the transport request. To ensure consistency in the Customizing of the destination system, it is necessary to transport a hyper object and its referenced migration objects together. Referenced Migration Object Migration object that is referred to in at least one hyper object. In a hyper object you create a reference to a migration object in an auto structure of the auto structure type MigObject.

Transport migration object

This function allows you to transport the selected migration object. The transport process uses PC download and upload. The user can decide whether to also transport documentation and definitions of fixed values or not. You can either unload the object or import an existing transport file. The settings of the selected object are overwritten. The following functions are also available:

Display the transport file Compare the settings in the transport file with the system settings

Generate all Migration Objects

If basic settings - or the program that generates the reports itself - are changed, then all the load reports must be generated again from the migration customizing. This could be necessary after an upgrade of the IS-U Migration Workbench, for example.

More Utilities
With this menu option you can call functions that are only required in special situations.

26 Shosh Friedman

Check Customizing
When transporting Migration Customizing it is possible that some objects are no longer consistent, because a fixed value definition, for example, does not exist in the target system. You can use IMG activity Check Customizing to check the completeness of individual objects or all objects of a company.

Dictionary: total comparison

In this delivery version, the migration objects contain all the fields of structures of the automation data as they appear in the Dictionary When you copy an object into your own project, the field list may not be current in some cases, since the SAP structures may have been changed by importing patches or new fields may have been added through customer enhancements. The "Overall Dictionary Comparison" function examines all the migration objects to find differences between the field list and the Dictionary in your product. The synchronization itself is performed with menu function "Automatic structure - synchronize fields with DDIC"

Compare Objects
With this function you can compare one or more migration objects with other migration objects. In this way, you can compare all data including object definitions, automatic structure definitions, field rule definitions and migration events. You can compare objects:

From the same or a different company. In the same system or (indicating an RFC destination) in other systems.

Copy Migration Documentation

With this function you can copy documentation objects of a migration object from SAP. For further information see program documentation.

Delete Variants for Load Reports

With this function you can delete load report variants that are created at the start of every import run. For further information see program documentation.

Schedule import jobs

This menu option combines functions that simplify the scheduling and starting of a large number of import jobs.

Distributed import
The distributed import function acts as load distributor for the import of large quantities of data. For further information read the documentation.

Job Scheduler
27 Shosh Friedman

The job scheduler schedules import jobs that have dependencies to other import runs. In this way, you can define an import job that:

Consists of several steps to different migration objects. Is waiting for another import job to end. Is waiting for a background event.

You can trigger background events in the job scheduler.

3. How Do I Use Migration?

In this IMG activity, you learn about the essential processes in the IS-U migration environment. The individual sections contain detailed information about the activities that have to be performed, as well as about the handling of the IS-U Migration Workbench.

3.1. Procedure for Data Transfer

The most important steps in data transfer are: 1. Creating the migration user In addition to defining the parameters in user master data, you have to establish further settings per user in the migration workbench. 2. Creating your own company A company can be viewed as a migration project. It is therefore an action that only occurs once. 3. Copying the desired migration objects SAP contains the standard version. Consequently all the changes made within it are lost after each upgrade. Therefore you must copy all objects and transfer them to your own migration project. 4. Adjusting the field rules of the individual migration objects All auto data fields in which you have to enter values, require a special processing rule. Some rules are contained in the standard version. This action is by far the most costly part of migration, as you have to take the IS-U business processes into consideration here, that only occur later. 5. Generating the load report The field rules are not available in code until the load report has been regenerated. You can only use import with current reports. 6. Generating the import data file You can perform this action either externally with legacy system data, or with the IS-U migration workbench. With the workbench, the data has to be entered manually. 7. Importing data Flow of the import program, either in dialog or in batch. 8. Checking the result After the import run is complete, you can check the result with the migration statistics, application log and KSM display. 9. Repeating field maintenance, import, error evaluation As a rule, migration customizing only reaches its final status after several such test imports. Therefore you require a repetitive process.

Create Migration User

To create a migration user, proceed as follows:

The user has to be available in user master data The user has to be authorized for migration (authorization object E_MIGRATN)

28 Shosh Friedman

In the menu, choose IS-U migration - user parameters Make the following settings:

o o o o
Note

preferred company application server and working directory for import in the dialog work process application server and working directory for import in the background work process character set for the legacy system

save the settings

The working directory you have entered must be available on the specified (application) server. It is not a local PC or network directory. If the production migration uses several servers, a physical directory should be reachable under the same name from all the application servwers (NT: share; UNIX: NFS), to allow the load jobs to be distributed among all the servers. The user parameters for the data import can be used to override the settings for the selected company. For more information, please refer to the documentation on the import parameters.

Create Your Own Company

To create a migration company, proceed as follows:

Choose menu path IS-U Migration - Maintain company Perform the following settings:

o o o o o
Note

Company name Development class to use to generate the load modules Application server and current directory for import in the dialog work process Application server and current directory for import in the batch work process Code page of the legacy system

Save your settings

You can use the user parameters for the data import to override the company parameters. To perform the actual migration with multiple servers, a physical directory should be available to all application servers under the same name (NT: share; UNIX: NFS), to ensure that jobs for the data import can be distributed among all the servers. For more information, please refer to the documentation on the import parameters.

29 Shosh Friedman

Determine Project Scope

After you have analyzed which migration objects are required for the migration, you then have to create them in the defined migration company (migration project). A description of the available methods can be found in the following chapters: 1. Copying the migration objects from the SAP migration company 2. Creating migration objects using the project maintenance

Create Migration Objects in Project Maintenance

General Project maintenance supports the selection of migration objects and their Customizing. SAP provides question catalogs for this purpose. Each catalog contains questions involving an area of the master data or the transactional data. The answers to the questions and the rules defined in the catalog are used to generate an execution plan that creates or changes the migration objects and changes the Customizing of the migration objects in accordance with this generated execution plan. Project Project maintenance is called via menu path IS-U Migration - Project maintenance. Existing catalogs can be copied in a project. The categories assigned in the catalogs improve the clarity of the supplied catalogs. Catalog Each catalog consists of a number of consecutive questions. A question can be formualted as a query or a statement. To change an answer to a question (or to confirm the statement), select the question with the cursor and press the Answer button. You can also double-click on the answer icon to change the answer. When you press the Execution plan button, an execution plan is generated from the answers in the catalog and displayed. The following rules apply to the generation of the execution plan:

If the answer to a question is No, then all subordinate questions to that question are ignored in the execution plan. You can set a block to exclude a question from generation in the execution plan. To do this, select the question with the cursor and press the Block (or Lock) button. When you block a question, all the subordinate questions are also blocked.

You can display a legend of colors and icons using menu path Utilities - Color/Symbol legend. Execution plan The execution plan displays all the planned changes to migration objects in the defined rule set. You can display a legend of colors and icons using menu path Utilities - Color/Symbol legend. You can block the displayed changes individually for an execution. To do this, position the cursor on the question press the Block (or Lock) button. The migration objects are differentiated as follows in the displayed execution plan:

Create migration object The displayed migration object is created as a copy of the reference migration object defined in the rules. The reference migration object is usually the migration object of the same name from

30 Shosh Friedman

the migration company, SAP. The displayed changes are then performed on the Customizing of the migration object.

Change migration object Make sure that you really want the displayed changes to be performed. Changes displayed in the execution plan may change the Customizing settings that you have configured for the migration object. If you do not want the displayed changes to be performed, the following options are available:

o o

Enter a different name for the migration object (rename the migration object) Block the planned change in the execution plan To do this, position the cursor on the question and press the Block (or Lock) button.

Migration object cannot be changed The migration object is not compatible with the reference migration object defined in the rules. Incompatible migration objects cannot be changed. To display the incompatibilities, position the cursor on the affected migration object and press the Object status button.

Migration object is blocked

The displayed changes will not be performed unless you press the Execution plan button. Changes to existing migration objects must be confirmed.

Copy More Migration Objects

To copy a migration object, proceed as follows:

Select the migration object that you want to copy In the menu, choose Utilities - copy migration object Specify the name of the company, the migration object and a short description particular to the company. Choose the function key for copying the object Mark the newly created object for further processing

The new migration object is created with the blocking status '100'.This means you cannot import data to it for the time being. This should prevent new objects being unintentionally imported. Repeat this process each time you want to use a migration object from SAP as a model for your own customizing, for example.

31 Shosh Friedman

Adjust the Field Rules for Individual Migration Objects

To adjust the field rules, double-click on the corresponding field to select it. This calls up the field rule maintenance screen. Maintain the details of the field rule and save your changes. If the field you are looking for is not visible, you can use the display options (menu path Field - Display list - All) to display the complete field list. Alternatively, you can use mass entry (menu path Automation structure - Edit fields in structure) to edit several field rules at the same time.

Generate the Load Program

You need to generate a load report each time you make an alteration to:

the definition of the migration object auto data structure part of a field rule generation event the workbench or the generation program (for example SAP upgrade)

You can either choose the function key 'Generate' or the menu path MigObject - report - generate for generating the report. In the migration workbench you can see the situation of the load progam in the colored icon. A yellow icon means that you have to regenerate the report.

Generate the import data file

The import file is a binary file with a definite Structure that is predetermined by the IS-U migration workbench. When the data contained within the import file is transfered, it has to be arranged in accordance with the customer structure. The function Utilities - Structure display - Display customer structure offers help with the layout. If the import file has to be generated by an external program, you have to keep this layout. In addition, you have the opportunity to create example data in the migration workbench and build an import file using it. Here the user is assisted with layout information (for example sequence, length and category of the individual data fields, F1 help, F4 help where available). This function - called the File Editor - is available on the import screen. Correct configuration of the import parameters is a prerequisite for editing the files. It is also possible to download example data with migration data in a special format (speadsheet) onto your PC. The header data (data category &INFO) is not transported in this format. It is therefore possible to upload the data again for the same migration object, even in another import file.

32 Shosh Friedman

The field contents are still formatted in accordance with the customer structure and arranged separated by tab characters.

Data import
You branch to the data file via Migration object - Data import. Yon can select the import file in this screen. You still have to specify which work process category the import should use (dialog or background). If the import takes place in the dialog work process, you can start the corresponding load program RE3TR_cmp_objn (cmp = company, obj= identification code for the migration object) using the 'import object' pushbutton. If the import takes place in background processing, you have to choose the start time. A variant MIG_nnnnnnn is generated for the load program and a job. The job can start immediately after the release, or the user can specify a start time. The file is started on the displayed destination server. If several servers are available during the production migration, the directory that contains the physical files should be reachable under the same name on all the servers (NT: share; UNIX: NFS), so all the available application servers can be used for a parallel data import. The correct configuration of the import parameters is a prerequisite for importing the data.

Check Results of Data Import

During the runtime of a data import or after a data import, the result of the migration run can be checked using various functions. 1. Migration statistics A special statistics record is created for every import run, and is continuously updated during the import. With this display you can follow how many errors have already occured and which legacy system key the system is currently processing. In addition, the statistics contain the name of the import file; they also enable you to call the application log (see below). You call the statistics via a pushbutton on the import screen. 2. Application log At the end of the import run, all error messages that occured during processing are recorded in the application log. The message object is 'IUMI'. You can call the application log via a pushbutton on the import screen or using transaction code SLG1. 3. Key and status management All imported data records are stored in the so-called key and status management. Here, the newly placed IS-U key is allocated to every legacy system key (OLDKEY field in the import file). You can call the statistics via a pushbutton on the import screen.

3.2. Order of Migration Objects

You can call an overview of all the migration objects provided by SAP here. You can also call the documentation of each object in the list. Below are the two ways in which can you display the relationships between migration objects:

As hypertext

To do this reset the help display option as described here. To ensure optimum readability of the migration documentation and the migration user manual, you should choose Help -> Settings in the menu and set the Display in modal screen selection in F1 Help.

33 Shosh Friedman

You can then call the hierarchy display. The following diagram represents the individual migration objects with their dependencies. Read from above to below, the diagram displays the chronological order of migration.

| (1) ADRPSTCODE REGPOLIT | | |----------| ADRCITY-------| | | | | | | |

| (2) BANK

| | | | ADRCITYISU | ADRSTREET------| ADRSTRTISU |

| ----------------------------------------------------------------------DEVICE CONNOBJ ------- PARTNER -------| | | | NOTE_CON | | | | PART_REL

| | | | ------------------------------| | | | | | (5) | | | | | BCONTACT | PREMISE --| | ACCOUNT-- | | | | | | | | | BCONT_NOTE | | DEVGRP | | | | | | | | (3)--- DEVLOC -| | ----

| | | | | | -------------- NOTE_DLC | ACC_NOTE |

| | | | | | | | | INSTLN -------------- | -----------(7) | | | | | | | ----------------- FACTS | | | PROPERTY | | REFVALUES | | | ---- INST_MGMT | | | | | ( INSTALL) | LOADPROF | POD | | | | | METERREAD --------------------------CONSUMPT (6) | | STRT_ROUTE MOVE_IN PODSERVICE REGRELSHIP | | |

34 Shosh Friedman

(4) |

------------------------------------------| | | BBP* DOCUMENT BILLDOC SECURITY | | | - - - - - ------------- PAYMENT

| | | PAYMENT INSTPLAN INTCASHDEP

Remarks: (1)Creating a regional structure is not essential to the course of migration. (2)Creating banks is not essential to the course of migration. (3)This dependency exists when you allocate device locations to premises. (4)This means all actions for all forms of payment plans. It therefore contains all the migration objects that begin with BBP_ ( BBP_EXT, BBP_MULT). (5)The existence of the business parntner is only sufficient for creating customers when there are not object references to be created. Otherwise a dependency exists on all the migration objects used in the object references. (6)On the field level, the only direct reference is between MOVE_IN and INSTLN (as well as ACCOUNT). However, without a correctly installed device, (without implementing the INSTALL object), MOVE_IN delivers a combination that is not billable. Therefore you cannot install the device (INSTALL) after the move-in (MOVE_IN) has been carried out, unless a rate mainteance is started later (manually). (7)Owner allocations can be carried out on the CONNOBJ and PREMISE levels; you must then specify the dependencies of these objects accordingly.

Selective display of the object hierarchy using a network graphic

Call the REMIG_OBJECT_HIERARCHY report

3.3. Create/Change Conversion Rules

The central task of migration customizing is generating and administrating field rules. To maintain a field rule, proceed as follows:

Double-click the desired auto data field Choose Field - change from the menu You can choose the processing category on the maintenance screen. By setting the 'generation indicator', you ensure that during the next time the load report is generated the field rule is compiled into coding Some processing categories require you to make additional specifications to control the processing

35 Shosh Friedman

Save the settings

Field Rule: Initial

During the processing flow, a field with processing type '1' or 'initial' is provided with the corresponding initial value in accordance with the Dictionary definition. This means that before the service function module is called, the ABAP statement CLEAR struc-field. is executed for the field.

Field Rule: Fixed Value

During the processing flow, a field with processing type '2' or 'fixed value' is provided with the contents of the assigned Fixed Value. This means that before the service function module is called, the ABAP statement MOVE <fixed value contents> TO struc-field. is executed for the struc-field field . Examples Field rule using a fixed value with the contents '01' as a constant (string): MOVE '01' TO struc-field. Field rule using a fixed value with the contents 'sy-langu'as a field: MOVE sy-langu TO struc-field. A form routine is called for fixed values that are filled using program instructions; this form routine executes the instructions and the field is then set as follows: PERFORM fixvalue_<festwert> USING struc-field. &NOTES% You must ensure that the assigned contents correspond to the field definition in terms of field type and length.

Field Rule: Move

During the processing flow, a field with processing type "3" or "transfer" is provided with the contents of the corresponding field from the customer structure - that is, with the value from the legacy system. This means that before the service function module is called, the ABAP statement MOVE z_struc-field TO struc-field. is executed. Notes

36 Shosh Friedman

At present no type-specific inspections are carried out before the contents are assigned. If the field has a conversion exit defined in the Dictionary, it will be called with the destination field. If the field is internal data type P (packed number) or I (integer), you can decide whether the internal or the external (screen) layout is to be used for the data transfer.

Field Rule: ABAP Rule

In a field with processing type '4' or 'ABAP rule', the contents of the corresponding field from the customer structure, that is the value from the legacy system are set in a symbolic variable $C$ and user defined code is run. The automation data field is available in symbolic variable $S$. Example As the field rule the following code was entered if $C$ is initial. move '0001' to $S$. else. move $C$ to $S$. endif. In the generated code for the field struc-field it looks like this: if z_struc-field is initial. move '0001' to struc-field. else. move z_struc-field to struc-field. endif. Notes

For technical reasons the code that is entered cannot be tested for check errors. The syntactic correctness of the coding is not tested until a load report is generated. If the field has a conversion exit defined in the Dictionary, it will be called with the destination field. If the field is internal data type P (packed number) or I (integer), you can decide whether the internal or the external (screen) layout is to be used for the data transfer. You can change the length of the field for the file import. The data type of the field is then always C (character).

Field Rule: Via KSM

During processing, a field with processing type '5' or 'via KSA' is provided with the contents of the corresponding field from the customer structure, that is with the value from the legacy system. This value is interpreted as a legacy system key and with the help of the key and status administration is replaced by its corresponding IS-U key. Example

37 Shosh Friedman

The business partner with the old key '1234-567' has been successfully created in IS-U with the number '1000012345'. During the transfer of the contract account, the value '1234-567' exists in the GPART field.The KSA replaces this value with '1000012345'. Notes The value that is transfered must have already been processed and successfully created as an old key in a data record from the elevated migration object in migration. If this is not the case then an error message is displayed and processing continues with the next data object. You can enter up to five higher-level migration objects for a search in the KSM. For fields form processing type '5', the field length os automatically set at 30 characters. The data type is determined at CHAR regardless of definition of the field it is based on.

Field Rule: Convert

During processing, a field with processing type "9" or "Convert" will be given a value using the mapping rule that was defined by the corresponding conversion object. Here, the contents of the corresponding field in the customer structure - that is, the value from the legacy system is converted through the mapping rules to the destination field. Notes

The field length for fields of processing type '9' is automatically set to the input length defined in the conversion object. The same applies to the data type. At the present time, no type-specific checks are performed before the contents are assigned. After conversion, any existing conversion exit is executed.

Field Rule: Customer Field

During processing, a field with processing type '6' or 'customer field' is provided with the contents of the corresponding field from the customer structure, that is from the legacy system. There is no additional processing; the field is simply for transfering the contents from the legacy system. Notes: During runtime, the contents of this field are available under the name z_struc-field. You can process them further in ABAP rules for other fields, or in Events. As the field is not contained in the Dictionary. you must specify a field length. The data type is automatically determined at CHAR.

3.4. Transfer Customer-Defined or Additional Fields

If the IS-U system has customer enhancements (customer exits), then those fields that were included for this purpose in the relevant Dictionary structures are also included in the IS-U Migration Workbench. This is because of the of the auto data concept for an object and the defintion of auto data in Dictionary structures. To use these fields in the migration, you have to add them to the field list of the migration object. Use the "Dictionary synchronization" function, which is available under menu item "Auto structure -> DDIC synchronization". You must select the structure to synchronize.

38 Shosh Friedman

When you define user-defined structures in the IS-U objects, you must ensure that the NO DIALOG case is also included in the customer exit code. You can include additional fields, which are only used for migration purposes, in the customer structure as customer fields. These fields are read from the import set, however, they are not processed. This means you can access the field at other points in the form of an ABAP field rule and process the contents. You can also process these fields vis events (see section Create Customer Exits in the Migration Report).

3.5. Create Customer Exits in Migration Report

The IS-U load program offers the opportunity to include user-defined codes (events) at certain, exactly defined points in the program flow. This can be used, for example, to carry out additional changes in the auto data fields before a data object is created, or to perform additional actions after a data object has been succesfully created. When you generate a load report, these events are written into the program. In this way you do not have to manually re-enter them each time you generate a new load report. The following event categories are available:

Function: Call function module You can call the function module you have specified with CALL FUNCTION. You can provide the function module interface with parameters via a variant.

Perform: Call subprogram (FORM) You can call the FORM routine you have specified with PERFORM. If you have to provide parameters, you must create a variant. You must ensure that the FORM routine is in a userdefined include, which must be included via an event.

Include: Insert an include statement You include the include you have specified with INCLUDE.

Coding: Insert ABAP statements The ABAP statements that you want to insert have to be entered in the "Coding" field, and the "Change coding" function key has to be defined to the right.

After the event, you can add more coding. You must ensure that the included objects are available and free of check errors. Data declarations you have used may still have to be created as an event. The standard system already uses events to include general functions, as well as to generate object specific actions. They cannot be changed or removed. Special coding can be inserted in the load program immediately before the call of the subprogram entered in the event. You must assign a name to this special coding in event maintenance. The coding that is generated in this manner can be used in different events for the load program of a migration object (you specify its name). The standard package also uses events, both to include general functions and to generate objectspecific actions for the load report. You may not change or delete these standard events.

39 Shosh Friedman

Enhancements are currently supported for the following events:

INCLUDE Including include statements at the start of the report

CSTINCL Including additional include statements at the start of the report

START Before the data records are imported and processed

READ01 Importing a data record

FILL01 Before processing the field rule for a data record

FILL02 After processing the field rule for a data record

OTHERS Changing the data type

READ02 End of the processing loop for a data type

SERVI01 Before the service function module is called CALL01 Directly before the service function module is called CALL02 Directly after the service function module is called

SERVI02 After the service function module has been called

SERVI03 After a data object has been created

LAST End processing of a data object

END

40 Shosh Friedman

Actions after the last data record has been processed Special functions provided The migration package includes two subroutines that can be used for special functions in the events.

Subroutine (FORM) BREAK This event can be added to any generation location and processes a break point.

The events

Subroutine (FORM) DUMMY and CODE still exist for compatibility reasons. They are used to add coding WITHOUT a separate function module or subroutine. It has the same function as CODE, and is used only to ensure backward compatibility for existing events. The functionality has been replaced by the new event type CODE.

3.6. Create Sample File

In the test phase you have the opportunity to create an import file in the migration workbench with test data. To do this, proceed as follows:

Mark the migration object Go to the data import screen Specify a file name. (If the file already exists it will be displayed from the file header). Choose the pushbutton for creating the data. You get a list, in which the data header record is displayed. Choose the push button for creating a data record. The system will ask for the legacy system key. If you set the "Insert data record" field, the new data record is appended to the end of the file; otherwise the new data record is inserted before the data record selected with the cursor. After you have provided this, the fields are displayed of the auto data structure to be processed first. Fill in these fields and confirm. If the object requires more than one structure, then a corresponding amount of data entry screens run. After the last data record the system cancels the entry and you get a list of all the data you have entered.

Remarks:

You must enter a value other than SPACE in at least one field per structure. Otherwise the structure is ignored. If the structure can be supplied more than once, you must interrupt the entry with the pushbutton 'next structure' and branch to the next entry.

Editing function

Copying data records

41 Shosh Friedman

Position the cursor in any row of the data record to copy. Then press the button to copy a data record. The data record selected with the cursor is copied to the clipboard. To insert a data record from the clipboard, position the cursor on the data record below where you want to insert the new one. Then press the "Insert data record" pushbutton. The system prompts you to enter the new legacy system key. After you enter this key, the data record is inserted in the file.

Copying sub-structures Position the cursor on the sub-structure you want to copy. Then press the pushbutton for copying a sub-structure. The sub-structure you selected with the cursor is copied to the clipboard for sub-structures. To insert a sub-structure frmo the clipboard, position the cursor on the sub-structure below where you want to insert the new sub-structure. Then press the "Insert sub-structure" pushbutton. The sub-structure in the clipboard is inserted into the file with the legacy system key of the selected sub-structure.

Creating sub-structures

To create new sub-structures, press the pushbutton for creating a new sub-structure. After you select the data category, the fields of the automation data structure to be supplied are displayed. Fill these fields and confirm your entries. The sub-structure is inserted in front of the cursor position.

Import function

If an import function module was generated for the migration object, you can migrate a data record directly from the editor. To do this, select a data record with the cursor and press the pushbutton for the data import. Display Runtime Object A migrated runtime object can be displayed from the editor. To do this, use the cursor to mark a data record, and use the pushbutton to display the runtime object.

4. Transfer Strategies
This section contains notes on the migration strategy. Important dependencies are described as well as which data objects must be transferred by which migration objects.

4.1. General considerations

General The design of the IS-U migration allows you to transfer data on a key date, without requiring you to perform a final billing in the legacy system. All transferred data, where applicable for billing, is created in its correct historical validity. This guarantees that the subsequent billing run in IS-U/CCS covers the complete period since the last billing in the legacy system. Data that does not occur in the current billing period will not be transferred. Exceptions include data that is required for billing in the current period (such as installation facts) or data that can be included in the historical data (such as previous consumption). The following two migration objects are of special importance:

42 Shosh Friedman

Move-in - Migration object MOVE_IN Migration object MOVE_IN (move-in and create utility supply contract) is of critical importance in this concept. The assignment date of the installation for the contract, and therefore of the contract account and business partner as well, determines the start of billing period. Installation - Migration object INST_MGMT To make sure a register exists for calculating consumption from the new billing period starting on the move-in date, the installation must be performed on the same date.

4.2. Master Data

Master data is usually not defined time-specifically. As a result, objects like connection objects, business partners, and so on should be created with their current status in the legacy system at the time of the migration. Exceptions to this rule are:

Devices: can be created on any date that lies before the (migration) installation date. Installations: the start date of the installation should lie before the (migration) move-in. This is particularly important when you want to create installation facts for the period before the movein (that is, for old billing periods).

These two entities are delimited during device installation and move-in, respectively.

4.3. Move-in
The move-in (migration object MOVE_IN) links the technical data (installation object up to installation, including installed devices) with the commercial master data (business partner and contract account). To do this, a contract is created and assigned on a specific date to the contract account and installation. Therefore, this assignment date (move-in date, field EINZDAT) determines the first day of the actual billing period. Accordingly, this date must be set to the earliest date that has not yet been billed in the legacy system. Example The last billing of a contract in the legacy system billed up to June 15, 1999. Therefore, field EINZDAT in object MOVE_IN for this contract must be set to June 16, 1999. Object MOVE_IN also contains field XVERA, which indicates the move-in as a "migration" move-in. (Refer to documentation on field XVERA) During the first billing after the migration, this field ensures that the first billing is month-specific - as opposed to the usual day-specific billing.

4.4. Device installation

Device installation is used to set up the currently valid installation structure. During installation, you must specify one meter reading for each register. Example The last legacy system billing for a contract covers the period up to and including June 15, 1999. The move-in is therefore performed with EINZDAT = June 16, 1999. Therefore, in this case, you will also fill field EADAT in migration object INSTALL with June 16, 1999. As a result, the meter reading that is passed in field ZWSTANDCE for the individual

43 Shosh Friedman

registers will be used to determine consumption during the next billing run. It must therefore correspond to the last billed status from the legacy system. Any changes to the installation structure relevant to billing made between the start of the billing period (EADAT) and the migration date must also be transferred.

4.5. Contract Accounts Receivable and Payable

Several migration objects have been defined in the IS-U Migration Workbench for transferring data on the contract accounts receivable and payable. These objects can be used to implement a large number of possible scenarios: Examples of these scenarios include:

Simply transferring the balances Migration object DOCUMENT can be used to transfer the balance of every contract account in the legacy system as a receivable or a credit memo.

Transferring all open items Object DOCUMENT can also be used to transfer all the open items for the contract accounts. Here you can only transfer all partially cleared items with their open amount. You can also transfer them in their original amount, after which they are then partially cleared by a payment with the object PAYMENT.

Other required transfer methods include: 1. Budget billing plans In this case, the transfer depends on the budget billing plan method. For more information, see the documentation on transfer concept for budget billing plans 2. Security deposits Special objects are available for for cash security deposits, payments for them, and the calculation of their interest (migration objects SECURITY, PAYMENT, INTCASHDEP). Please also read the documentation on the Transfer concept for cash security deposits. 3. Installment plans In this case, an open item must be transferred in the amount of the payable, using object DOCUMENT. Object INSTPLAN transforms this open item into an installment plan. Please also read the documentation on the Transfer concept for cash security deposits. You should use separate transactions and separate accounts for the transfer to ensure that you can differentiate between the transferred documents and documents that were generated in IS-U/CCS. You must also neutralize posting totals generated in the transfer using appropriate adjustment postings or a reversal, since the amounts have already been transferred to the general ledger. For more information, refer to the documentation on Transfer concept for open items.

4.6. Consumption History

There are various aspects and functions of the consumption history that affect the data transfer from the legacy system. Data for the consumption history is required

44 Shosh Friedman

1. Information purposes You can use migration object FACTS to transfer installation facts to certain operands. You can then use transaction EAMACF to create a consumption history (database table DBERCHV). 2. Graphical consumption information on the bill Can also be provided through installation facts for certain operands. 3. Influence for the next billing. Can also be provided through installation facts for certain operands. 4. Estimating meter readings In this case, you should create individual period consumptions (migration object CONSUMPT) for the entire future period in which an estimation is not possible due to missing meter readings. Also see the transfer concept for historical billing documents.

5. Define New Migration Objects

This IMG activity describes the neccessary activities for determining user-defining migration objects. The IS-U Migration Workbench has an option for setting up your own migration objects that are not copied from the supplied objects. As a result, data objects whose transfer is not part of the standard migration package can be transferred using objects you define. You can create three types of migration objects

Migration objects based on a service (function) module Migration objects based on a BDC recording ( BDC objects) Migration objects based on existing migration objects ( hyper objects)

5.1. Create Migration Object

You must carry out the following steps to define a migration object: 1. Fix the desired functions of the migration object (for example, the function "create entries for table XYZ999") 2. Check whether there is already a function module that offers this scope of functions or whether you have to create a new function module for the required function. 3. Check the interface for the function module a) Are there unique interface parameters for auto data? b) Are there return parameters that return the key for the newly createdtable entry? c) In what form are possible mistakes returned (sy fields, exceptions, IS-U message objects) ? 4. Structure of the migration object via the menu item Migration objekt - create, using the data for the service function module being used, as well as the transfer and return structures

Create Autodata (Part Structure)

You must carry out the following steps to define the auto data of a migration object: 1. Analyse the auto data of the function module 2. Structure the auto data hierachy via the menu option Auto Structure - Create. In this way the names of the individual nodes you have to choose are exactly the same as those of the individual auto data. 3. Enter the Dictionary structure 4. If the structure can be supplied more than once (occurs attribute in the auto data definition), then set the indicator 'multiple'

45 Shosh Friedman

5. You create the auto data fields via the menu option Auto Structure- Compare with DDIC 6. Supply the individual structure fields with a field rule 7. Generate the load report

5.2. Create BDC Migration Object

To define a BDC migration object, perform the following steps: 1. Select a transaction with the required scope 2. Record this transaction using the Batch Input Recorder (Transaction SHDB) 3. Create a migration object (menu path: Migration Object -> Create) Select a name for the migration object and the required recording (for example re-record a transaction) 4. The recording data is then displayed in an overview. If all the fields were not automatically set when the recording was copied then you must allocate field names to these fields manually. 5. Save the recording data. This creates the migration object, allocates the service module and generates both a dictionary structure and auto data from the fields. 6. Allocate a short description 7. Save the migration object Notes The system creates a field value with the processing type 3 (move) for all the fields in the auto data. To store the newly created keys in KSM, you can store a message number for the migration object, as well as the variable to which the transaction returns the number of the newly created object.Otherwise the system always uses the internal DB_UPDATE field (database updata complete) to update KSM. Key and status management (KSM) Management of information about created data objects and their import status in IS-U migration. This management is implemented using the TEMKSV database table. The following functions are implemented using the KSM:

Check whether a data record on the import file was already transferred in IS-U migration. Linking external keys (that is, keys from the legacy system) with keys created during import into IS-U.

These checks are carried out for every processed data object during the runtime of the import program. The newly imported data records are also recorded in the TEMKSV table. You can evaluate via table TEMKSV and make changes to external keys using the KSM maintenance tool in the IS-U migration workbench.

5.3. Create Hyperobject

To define a hyper object you must complete the following steps: 1. Specify the required features based on the migration objects already created in the migration company. 2. Create the migration object via menu option Mig. object -> Create and enter migration class hyper. You do not need to enter data for service function modules and transfer/return structures because they are generated automatically. 3. Create auto structures via menu option Automatic structure -> Create. You can choose between Automatic Structure Category: Substructure and Automatic Structure Category: Migration Object for a hyper object. When creating the stuctures, note that the names of the data types also have to be unique within a hyper object. Therefore, you must adjust the data

46 Shosh Friedman

types in the automatic structures of the referenced migration objects before you create the structures as Automatic Structure Category: Migration Object. 4. Generate Load Report. Note the restrictions for Maintenance of Hyper Objects and Maintenance of Referenced Migration Objects. SAP recommends that you activate the locks for dependent object data, when importing data for hyper objects. Locks prevent the import of data that cannot be consistently imported for a recall or due to incorrect data in the previously processed data records. See Special Technologies for a description of the lock concept.

Create Autodate (Referenced Migration Object)

To define a referenced migration object in a hyper object, you must complete the following steps: 1. Analyze data categories for the migration object to be referenced. Note that after creating the reference, no data category exists more than once in the processed hyper object. You must have already created the migration object to be referenced, in the migration company of the hyper object. 2. Create auto data via menu option Automatic structure -> Create Choose automatic structure category MigObject and enter the name of the migration object to be referenced. A hyper object cannot be referenced by another hyper object. 3. Save the created substructure. The auto data for the referenced migration object is arranged below the created automatic structure with the name of the migration object. You can only maintain the generation indicator for automatic structures from the MigObject automatic structure category. See Restrictions for the Maintenance of Referenced Migration Objects and Restrictions for Maintenance of Hyper Objects. When creating an automatic structure from automatic structure category MigObject, new structures for the hyper object are automatically created, for each maximum input structure of the referenced migration object. The new structures include the maximum input structure of the referenced migration object. As a result, the system checks the coding of field rules when creating an automatic structure in the hyper object, to see whether the structure names of the maximum input structure or the auto data structure AUTO are used. It also checks whether the corresponding substitutions are transferred to the coding of field rules for the hyper object. If several migration objects must be referenced in one hyper object you must check that the same data object definitions do not exist more than once in the field rules. This can cause syntax errors when generating the load report for the hyper object. Use the prefix LV_ (local variable) for the definition of local data objects. This prefix is replaced in the hyper object by the combination of LV_ and the short name of the referenced migration object.

Generate Load Report for Hyperobject

The generation of the loading report for a hyperobject consists of the following steps: 1. Generate Type for Auto Structure AUTO The automation data of the hyper object is used to generate an auto structure type. The components of the auto structure type are generated based on the auto structures that are defined on the highest level of the auto structure data. Auto structure type MigObject Components: Name of referenced migration object Component type: Auto structure type of referenced migration object Auto structure type Substructure Components: Name of substructure Component type: Name of max. input structure 2. Generate of Type for Customer Structure INFO

47 Shosh Friedman

All auto structure data of both the hyperobject and the reference migration object is checked to see whether they have the Customer structure indicator. These are then generated in the customer structure type: Components: Name of substructure Component type: Name of max. input structure 3. Generate Coding from Field Rules The coding is analyzed and the following replacements are made as the coding is transferred to the hyperobject, both when a reference is created on a migration object and when later changes are made to the coding stored in the field rules of the referenced migration object. 4. Generate Service Function Module A service function module is generated in which the service function modules belonging to these migration objects are called based on the referenced migration objects. The events of call-up point CALL01 or CALL02 entered for the migration object are inserted both before and after the call-up of this service function module. The specific structure names of the transfer parameters belonging to the service function modules and the coding of the inserting events is analyzed for each migration object. The replacements described below are also carried for each migration object. 5. Generate Loading Report The loading report is generated from the settings for the hyper object and the created auto structures. Here, the coding of the event of both the hyper object and the referenced migration objects are inserted in the loading report as follows:

Event of the INCLUDE call-up point At call-up point INCLUDE (Integration of include statements at report start), first the include programs of the hyper object are transferred to the loading report and then those of the referenced migration object with an INCLUDE statement. INCLUDE programs with identical names are taken into account only once.

Event of the CSTINCL call-up point At call-up point CSTINCL (Integration of additional include statements at report start), first the include programs of the hyper object are transferred to the loading report and then those of the referenced migration object with an INCLUDE statement. Include programs with identical names are taken into account only once.

Event of the FILL01 call-up point At call-up point FILL01 (before processing of field rules for a data record), first the events of the hyper object and then the events of the respective referenced migration objects are inserted into the loading report. Events of the referenced migration object are only taken into account if they are not defined with the category Standard.

Event of the FILL02 call-up point At call-up point FILL02 (after the field rules for a data record are processed), first the events of each reference migration object are transferred to the loading report and then those of the hyper object. Events of the references migration objects are only taken into account if they are not defined with the category Standard.

Event of the call-up point SERVI01 At call-up point SERVI01 (before the service function module of the hyper object is called up), the events of the referenced migration objects within a case distributor are inserted into the loading report through a query of the current referenced migration object. Then, the events of the hyper object are inserted. Event of the referenced migration objects are only taken into account if they are not defined with the categories Standard and BDC.

Event of the call-up point SERVI02

48 Shosh Friedman

At call-up point SERVI02 (after the service function module of the hyper object is called up), first the events of the hyper object are inserted in the loading reports. Then the events of the referenced migration objects within a case distributor are inserted through a query of the current referenced migration object. Events of the reference migration objects are only taken into account if they are not defined with the categories Standard and BDC. Note Replacements of structure names in coding

Before the coding from field rules and events of the reference migration objects is transferred to the hyper object, the coding is analyzed and the following replacements are made:

Old: structure name AUTO New: structure name AUTO-<Name of the referenced migration object

Old: structure name of a customer structure New: structure name INFO-<Name of the customer structure>

Old: prefix of local variable LV_ New: prefix of local variable LV_<ID of referenced MigObject>_

Old: prefix of local internal table LT_ New: prefix of local internal table LT_<ID of referenced MigObject>_

Additional for coding from field rules: Old: structure name Z_<Name of input structure in referenced MigObjekt> New: structure name Z_<Name of input structure in hyper object>

Restrictions for Creating Maintaining a Hyperobject

The dependency between a hyper object and the migration objects referenced in the hyper object, causes the following restrictions when creating and maintaining a hyper object: 1. The maintenance of auto structures and fields of a referenced migration object is only possible in the referenced migration object. Changes made in the referenced migration object are automatically transferred into the hyper object after saving. The settings for the auto structures and fields can only be displayed in the hyper object. A comparison with DDIC and new positioning of fields is executed in the referenced migration object. 2. Hyper objects cannot be copied. 3. The transport of a hyper object always includes all referenced migration objects. 4. References for migration objects from the migration classes HYPER and NOTE can be created in a hyper object. 5. Migration Customizing cannot be uploaded for a hyper object.

Restrictions for Maintaining Referenced Migration Objects

The dependency between a hyper object and the referenced migration objects in the hyper object cause the following restrictions when creating and maintaining referenced migration objects: 1. The following procedures can no longer be executed:

49 Shosh Friedman

a) Change the short description of the migration object. b) Change the auto structure type c) Create and delete auto structures d) Maintain parameters for an auto structure (exception: generation indicator) e) Delete the migration object. This is only possible once you have deleted all concerned hyper objects that have a reference to the migration object you want to delete. 2. The migration object is always transported with all hyper objects that have a reference to this migration object. 3. It is not possible to upload the migration Customizing. 4. It is not possible to display mirgated data objects from the file editor. 5. When migrating objects with a hyper object, the entries for KSM (Key and Status Management) are updated for the referenced migration objects. Therefore, no entries for the hyper object are available in KSM.

Restrictions for Maintaining Referenced Migration Objects

The dependency between a hyper object and the referenced migration objects in the hyper object cause the following restrictions when creating and maintaining referenced migration objects: 1. The following procedures can no longer be executed: a) Change the short description of the migration object. b) Change the auto structure type c) Create and delete auto structures d) Maintain parameters for an auto structure (exception: generation indicator) e) Delete the migration object. This is only possible once you have deleted all concerned hyper objects that have a reference to the migration object you want to delete. 2. The migration object is always transported with all hyper objects that have a reference to this migration object. 3. It is not possible to upload the migration Customizing. 4. It is not possible to display mirgated data objects from the file editor. 5. When migrating objects with a hyper object, the entries for KSM (Key and Status Management) are updated for the referenced migration objects. Therefore, no entries for the hyper object are available in KSM.

5.4. Create BAPI Migration Object

You must perform the following steps to define a BAPI migration object: 1. Select a BAPI with the required features (using the BAPI Explorer, for example). 2. Create a migration object in the menu: Mig. Object - Create, enter the name of the new migration object and the migration class BAPI. 3. Enter the BAPI function module and a short description for the migration object. 4. Save the migration object 5. Generate the load report BAPI Migration Object Migration object created by specifiying a BAPI in the Migration Workbench. When creating a BAPI object, an automatic data structure is generated in the background. All fields contain the field rule of processing type 3 (Move). Function module BAPI_TRANSACTION_COMMIT is called instead of a commit work.

50 Shosh Friedman

6. Changes to Scope of Delivery 6.1. Changes in IS-U/CSS Release 1.2 New Migration Objects
The following new migration objects are included in Version 1.2: 1. ACCOUNT2 - Contract account (new version, replaces ACCOUNT) 2. ACC_NOTE - Notes on contract account 3. BBP_EXT - Budget billing plan with external scheduling 4. BBP_INT - Budget billing plan with internal scheduling 5. BCONT_NOTE - Notes on customer contact 6. BILLDOC - Billing document 7. DUNNING - Dunning items and creditworthiness 8. INSTPLAN - Installment plan 9. LOADPROF - Create load profile and allocate to installation 10. PAYMENT - Payment (open items) 11. PART_REL - Business partner relationships 12. REFVALUES - Reference values 13. SECURITY - Security deposit

Migration Object: ACCOUNT

The following changes have been made in migration contract account:

Notes:

It is now possible to allocate more than one business partner to a contract account In the VKP structure, fields have been added for the external address numbers The structure INIT has been added (header data) The structure VKLOCK has been added (discconnection data)

For this purpose, the ACCOUNT2 migration object is delivered in addition to the ACCOUNT object. The changes that have been carried out are only available in this object. If you have already created an ACCOUNT object in your own company, you should delete it and copy the SAP ACCOUNT2 object into your company under the name ACCOUNT. In IS-U Version 2.0, the ACCOUNT object will be adjusted the different settings of the ACCOUNT2 object.

Migration Object: PARTNER

The structure BUT0CC has been included in the auto data for the businesspartner. This structure is for transferring credit card data.

Migration Workbench
The following alterations have been made to the migration workbench for version 1.2: 1. Transporting migration customizing per download/upload 2. Customer enhancements

51 Shosh Friedman

a) Events: inserting code at certain points of the load report b) Customer field: inserting fields that are not defined in the Dictionary c) Customer structure: adding structures to auto data 3. Improved overview of customer structure, record structure and file layout 4. F4 help (display fixed values for domains and check tables) in the field rule screen 5. Improvements to the migration statistics a) Specifying the name of the imported data b) Branching to the application log for the import run 6. Including the user handbook in the migration workbench

6.2. Changes in IS-U/CCS Release 4.51 New Migration Objects/Changes

The following migration objects are new in Version 4.51: 1. CONSUMPT - Assignment of period consumption to register 2. DEVGRP - Create device group 3. INST_MGMT - Device movements 4. INTCASHDEP - Create interest document for cash security deposit - Create lot 5. LOT 6. METERREAD - Create meter reading 7. PROPERTY - Create owner assignment 8. REPLACE - Device replacement 9. STRT_ROUTE - Create street route Changes have been made to the following objects: 10. PARTNER a) New structure SHIPTO - SD ship-to party for delivery addresses 11. ACCOUNT a) The old ACCOUNT object that was shipped in Release 1.2 has been replaced by the configuration of object ACCOUNT2. b) New structure VKCORR - Correspondence data

Migration Workbench
The following changes have been implemented in the Migration Workbench in Version 4.51: 1. F1/F4 function in manual file processing On the screen for processing a single data record: a) You can use the F4 help to validate all the fields for which value help is available. b) The regular (data element) documentation can be displayed for all fields with F1. 2. New processing type "Conversion" This processing type is used to map discrete input values (import file) to a unique output value. The foundation for this is the conversion object. 3. Export of record descriptions in different programming languages A description of the customer structure - that is, the individual record layouts therein - can be generated in the programming languages C, COBOL, PL/1, and ABAP, and can be downloaded to a local file. This function is also available in the EMIGALL menu, through item "Utilities - Export record description". 4. Function "Total Dictionary comparison" Call this function with "Utilities - Total Dictionary comparison" 5. Enhancement of migration statistics/monitor function for batch runs The current throughput records for the import can be recorded in log records. This function can be activated in the migration user parameters. 6. New reports for re-forming and breaking down import files These functions are available on the import screen under menu path "Utilities" 7. Enhancements required for the RIVA migration

52 Shosh Friedman

6.3. Changes in IS-U/CCS Release 4.61 New Migration Objects/Changes

The following new migration objects have been included in release 4.61: 1. BBP_MULT - budget billing plans (several contracts) 2. REGRELSHIP - register relationships 3. SALES_STAT - copy sales statistics 4. DEVICEREL - create device allocation 5. CONNECTION - create connection 6. CONNCTINST - installation connection in connection object 7. TECHOBINSP - Allocate inspection date to technical object 8. LOTFINAL - completion work sample lots The following migration objects are now available for changing existing data: 9. PARTNERCHA - change business partner 10. ACCOUNTCHA - change contract account 11. INSTLNCHA - change utility installation The following migration objects were changed:

BBP_MULT You can now create budget billing plans for more than one contract. This has been achieved by enhancing object BBP_EXT to include the new structure T_EVER. You must copy a list of all contracts affected by the budget billing plan to this structure. The object BBP_EXT is still delivered.

DEVICE Classification data can now be copied when you create a device. To enable this, two new structures were included in the auto data: * Structure CLSHEAD - header entry for classification * Structure CLSDATA - characteristic-evaluations for classification

PARTNER Tax numbers of business partners can now be copied. To enable this, a new structure was included in the auto data: * Structure TAXNUM - business partner tax number

Migration Workbench
The followng changes habe been made to Migration Workbench for release 4.61: 1. Defining migration objects using the BDC recorder Transactions recorded using the Batch Input Recorder can be transformed into functional migration objects at the push of a button. These are called BDC objects. You can find this function in Migration object -> Create. For instructions, see Create BDC Migration Objects 2. Transporting migration customizing by transport requests The function Create Transport Request exists for transporting a company's settings between systems. The function creates a request in which you can include the settings of one or more migration objects. You can also include any additional objects required (such as fixed values).

53 Shosh Friedman

This function can be found in Transport -> Create Transport Request. It contains a simulation mode and the workbench organizer. 3. New file editor functions The new functions: * copy all data files of a data object in a legacy system key * insert a new data record in an existing object * delete data records from existing data objects 4. KSM maintenance tool Using the KSM maintenance tool, you can display entries in the key and status manangment, as well as display, change and delete new entries. You can reach the function by selecting a migration object. 5. Layout check/test run Using the layout check, you can check an import file for syntactic points (structure and sequence of data files, required entry fields, conversion values). An import does not take place. You can use the test run function for testing import files. This performs the requested changes and then reverses them using ROLLBACK WORK. You can find both functions on the import screen, on the Parameters tab strip. 6. Enhanced logging functions a) Error messages during the import job can now be stored in both job and error logs using a new user parameter. This means that you can start analyzing the error during runtime of an import job. b) You can also insert the event PROVIDE_FULL_ERROR_LOG (perform type) at the timepoint START. This ensures that all messages from the function module are retained in the error log, and, if required, in the job log. The additional messages can help you analyze the data records that the function module rejected. This results in a simplified error analysis, especially for migration objects from migration class INSTLN. Using this event results in a loss of system performance. We recommend you only use it during the test phase. 7. Flexible standard values for acccess paths to import files In the company parameters, you can specify standard values for the access path to the import files (file server/file directory). Using the same user parameters, you can override the standard values of the company parameters. The last processing type you selected for the data import is automatically saved in the user parameters and is automatically proposed the next time you call the data import function. 8. Changes to the behaviour of processing type 5 (via KSM) If you use this processing type, the KSM is only tested if: * the value in the output field is not initial * X was entered in the field's check indicator Previously the check was carried out without the check indicator. 9. Consistency check on migration Customizing of the object/company After a transport carried out by transport request, you can check the consistency of the field rules (menu path Utilities -> Check Customizing) 10. Down and uploading conversion values You can generate conversion values for a conversion object externally in a file. You can load the conversion values in the maintenance screen (menu Edit -> Conversion Values -> Upload). You can also process conversion values in Microsoft EXCEL (menu Edit -> Conversion Values -> Edit in EXCEL). To upload conversion values, enter the name of the conversion object that corresponds to the conversion values in the first line of the import file. 11. Enhancements as Prequisites for RIVA Migration

6.4. Changes Made for IS-U/CCS 4.62 New Migration Objects/Changes

The following new migration objects have been added to Version 4.62: - Billing document for consumption history 1. CONSHIST 2. DEVICERATE - Rate changes in the installation structure 3. DEVINFOREC - Create device info record - Create functional location 4. FUNCLOC 5. POD - Create point of delivery 6. PODSERVICE - Create point of delivery service

54 Shosh Friedman

Changes were made to the following migration objects:

DEVGRP The IS-U key of the created device group is now entered in Key and Status Management. In addition to creating a device group, you can now also use the migration object DEVGRP to terminate a device group or change the device combination in a created device group. For this purpose, the IS-U key of the created device group is entered in KSM. The ACTION field was added to the structure EMG_EDEVGR. This field is used to control the function of the migration object DEVGRP.

BBP_MULT Yearly advance payments can now be created for budget billing plans. To allow this, the object BBP_EXT now has the new structure T_EJVL in which to create a yearly advance payment for each participating contract.

METERREAD Specified error messages are now also issued to the error log during data import without the use of object-specific events.

Changes were made to the following migration objects in order to allow referencing with a hyperobject.

BBP_EXT Shift the event 'CODE' to call-up point SERVI01 in call-up point CALL01.

BBP_MULT Shift the event 'CODE' to call-up point SERVI01 in call-up point CALL01.

CONSUMPT Insert new event 'CODE' at call-up point CALL01. In addition, the interface parameters were adjusted to the service function module.

DEVGRP Shift the event 'CODE' to call-up point SERVI01 in call-up point CALL01. In addition, the names of local variables in the event were changed.

REGRELSHIP Shift event 'CODE' to call-up point SERVI01 in call-up point CALL01.

INST_MGMT Shift auto structure fields OKCODE and ZWSTAND below the auto structures INTERFACE, AUTO_ZW and AUTO_GER.

INSTALL Shift auto structure fields OKCODE and ZWSTAND below the auto structures INTERFACE, AUTO_ZW and AUTO_GER.

REPLACE

55 Shosh Friedman

SShift auto structure fields OKCODE and ZWSTAND below the auto structure INTERFACE, AUTO_ZW and AUTO_GER.

PREMISE Shift auto structure fields EVBSD_OKCODE and EVBSD_USE below the auto structure EVBSD.

Migration Workbench
The following changes have been made to the Migration Workbench for Version 4.62: 1. Definition of migration object as a hyperobject A migration object is created as a hyperobject by assigning the migration class HYPER. You can use a hyperobject to import the data of different migration objects in a single import file. 2. Enhanced event processing You can insert your own coding for data import with hyperobjects either directly before or after the service function module has been called. (Events CALL01 and CALL02). You can use the AUTO structure (automation data of the object), which is filled with the transferred data, for any further processing. 3. Description of auto structures You can now enter a descriptive text for each structure of the automation data. 4. Processing types a) Processing type 2 (Fixed value) 'Code' is now available as an additional fixed value definition. It is used to define a utility using ABAP program instructions. You can also assign a fixed value to a domain. This allows you to find this fixed value through the field domain using the field rule suggestion function. b) Processing type 5 (via KSM) Activation of locks for dependent object data. Locks prevent the import of data that cannot be consistently imported, even in a repeat run. For more information on the lock concept, refer to special techniques. You can run the check to see whether a legacy system key has been transferred to Key and Status Management for up to five migration objects at once. The legacy system key is replaced by the first found IS-U key. If no entry is found in Key and Status Management for any of the specified higher-level migration objects, an error message will be issued stating the migration object that was last checked in the Key and Status Management. c) Processing type 9 (Conversion) The field rule suggestion function can be used to search for conversion objects with the most suitable domain. The list of possible entries for the 'Conversion object' field will also only show conversion objects with suitable domain. 5. Migration control parameters To ensure that individual functions can be more easily influenced during migration, you can now use migration control parameters. Using a table, the user can influence individual company-specific and object-specific default parameters. To call this function, choose 'IS-U Migration - Settings - Customer settings' in the menu. 6. Display filter The user can define a display filter for the company to hide migration objects. To call this function, choose 'MigObject - Display options - Set display filter' in the menu. 7. Schedule Import Jobs You can now schedule an import job for several migration objects. To call this function, choose 'Utilities - Schedule Import Jobs' in the menu. Here you can define a job that includes several job steps. In each step you can load any migration object you choose. You can set the time of day, the end of another job or a triggered background event as the starting condition. Other functions include:

o o o

Import file split with simultaneous start of the import job Monitor functions such as job, server and work process overview Definition and trigger of background events

56 Shosh Friedman

8. Overview list of migration objects of a company You can display all the migration objects of a company in a list. To call this function, choose 'Utilities - Info System - List of MigObjects' in the menu 9. Downloading the key assignment of a company You can write the key assignment of the Key and Status Management to a file for external evaluation. To call this function, choose 'KSM - Key Assignment - Edit - Download'.

Additional Notes
To ensure optimum readability of the migration documentation and the migration user manual, you should choose Help -> Settings in the menu and set the Display in modal screen selection in F1 Help.

6.5. Changes in IS-U/CCS Release 4.63 New Migration Objects/Changes

The following new migration objects have been added in version 4.63: 1. DEVCAT - Create device category 2. DOC_INT - Allocate interest calculation date to open items. 3. FUNCLOCCHA - Change functional location 4. OBJCLASS - Create classification 5. OFFICEDOC - Create SAPOffice document 6. PREMISEWA - Additional premise data for waste management 7. GOODSMVT - Create goods movement 8. ROUTE - Create route 9. SERVFREQ - Create service frequency Changes were made to the following migration objects: 1. ACCOUNT - Create contract account The new structure VKTAXEX enables you to transfer tax exemption data. The same applies to the ACCOUNTCHA object. 2. CONNOBJ - Create connection object Following a change in the CO-PA-, UIS- and BW extractors regarding the REGPOLIT (element of political regional structure) and REGIOGROUP (regional structure group) fields, you must ensure that from release 4.63, this information is available in the address data of the connection object after migration in case it is required in the relevant functions. In migration, default values are determined by regional structure. Therefore, if no addresses are transferred from outside the regional structure, the provision of data is guaranteed. If this is not the case, fields REGPOLIT and REGIOGROUP are required in structure EHAUD. 3. DOCUMENT - Post document Structure ADD_INFO was added. This can help you to determine the allocation of the collective bill number from the legacy system as a reference to the collective bill number in IS-U. 4. FUNCLOC - Create functional location 5. INSTLN - Create installation The new structure POD now exists. This can transfer point of delivery data such as the external number and the structure category. 6. PARTNER - Create business partner Two new structures ECCARD and ECCARDH now exist. These can transfer concessionprocedure data. 7. POD - Create point of delivery

Migration Workbench
The following changes have been made in the Migration Workbench in Version 4.63: 1. Processing types a) Processing type 5 (via KSM)

57 Shosh Friedman

The higher-level migration object can be specified in the automation data when the Gen.KSM ObjFld flag is set in the field rule. When the higher-level migration object is specified in the automation data, this information can be used to override the higherlevel migration objects specified in the field rule. For a description of the functionality and its possible uses, please see Higher-Level Migration Object. 2. Flexible specification for code page and file name suffix during data import You can now specify the code page of the legacy system and the suffix of the import file name for dialog and background processing in the company parameters. The user parameters of the same name can be used to override the information from the company parameters. In addition, you can specify a code page in the parameters of the migration object to override the code page specified in the user and/or company parameters. In this context, please refer to the documentation of the import parameters 3. BDC objects It is now possible to re-record a BDC object. In the process, the existing field rules are used to the extent possible. If the new recording is based on a different transaction code, all the field rules are deleted and redefined with processing type 3 (transfer). 4. New event type CODE Program statements can now be added to an event directly, without event type PERFORM or parameter CODE. The ABAP statements to be included have to be defined using the "Coding" field and the "Change coding" button to the right of it. 5. Statistics of processed data types during data import The application log displays how often a data type has been read and processed. 6. Extended editing functions when creating sample files A comprehensive description of these functions is available in Creating a Sample File. 7. Mass processing for deleting and copying migration objects 8. Comparison of migration objects It is now possible to compare migration objects with one another. In the process, you can compare a single object or - using a mass function - several objects at the same time. The comparison can be performed locally or - via RFC connection - with another system. The function is available in the menu using MigObject - Compare or Utilities - Special functions Compare MigObjects. More information is available in the sections on the Compare menu option, the Compare objects menu option, and in the documentation for report REMIG_COMPARE_OBJECTS . 9. Distributed import You can now use the distributed import as an additional function for starting import runs. In the process, the import file is divided into several smaller files that can can be imported into a predefined number of work processes. For each completed partial import run, a monitoring program starts a new run. 10. Extension of the monitoring functions To enable more effective monitoring of the import runs, you can now call various system monitors from within the function Display migration statistics and from the Import screen. 11. Improved selection of migration statistics When you call the Display migration statistics function, you can now specify additional selection criteria to achieve a faster, more effective selection when a large number of statistics records are present. 12. Create migration objects in project maintenance Project maintenance supports the selection of migration objects and their Customizing by providing question catalogs. Each catalog contains questions involving an area of the master data or the transactional data. The answers are used to generate an execution plan that creates migration objects or makes changes to the Customizing of existing migration objects. 13. Display object hierarchy In the functions Display/Change Migration Object, the Relationship data tab page now contains a function that displays the object dependencies. These dependencies are determined using the KSM rules of the current object, as well as the use of the current object in the KSM rules of other objects. The current object is displayed in green.

6.6. Changes IS-U/CCS Release 4.64 New Migration Objects/Changes

The following new migration objects have been added to version 4.64: 1. PROFHEAD - Create profile header 2. PROFASSIGN - Allocate profile to register

58 Shosh Friedman

3. OBJSTATUS - Change user status of technical objects

6.7. Changes in IS-U/CCS Release 4.71 New Migration Objects/Changes

Version 4.71 includes the following new migration objects: 1. DISC_DOC - Create Disconnection Document 2. DISC_ORDER - Create Disconnection Order 3. DISC_ENTER - Enter Disconnection 4. CONTAINER - Create Container 5. CONTGRP - Create Container Group 6. CLEANOBJ - Create Cleaning Object 7. AREA - Create Area 8. SM_NOTIF - Create Service Notification for Connection 9. SM_NOTIFOK - Close Service Notification for Connection Changes have been made to the following migration objects: 1. INST_MGMT - Device Installation /-Removal /-Change Further information on the meter, in addition to the meter reading (for example, the actual meter reading type) can now be migrated through the additional structure IEABLU. 2. LOT - Sample lot Adjustment of the interface parameters to changed transfer parameters for service function module (AUTO-LOTD-DIVISION).

Migration Workbench
The following changes have been made in the migration workshop for version 4.71: 1. Generating Load Reports a) Required Entry Field Check The required entry field check for fields in a structure no longer immediately follows the processing of the respective field, for which the required entry field indicator is set. The check is now carried out in a separate step following the processing of all field values for a structure, and provided no errors occurred whilst processing the fields. The required entry field check is now run separately to the sequence, in which the fields for a structure are processed. b) Processing Type 4 (Rule) Instead of the field length defined in DDIC, you can define an alternative field length. The data type of the field in the customer structure is then C (Character). c) Coding at Structure Level ABAP code can now be defined at structure level. Code entered under Preprocessing is carried out before processing the field values for the fields in the structure. Code entered under Postprocessing is carried out after the field values have been processed, but before the required entry field checks. This makes crossfield processing possible at structure level. During generation of the load report, the symbol $C$ is replaced with the name of the customer structure, and the symbol $S$ is replaced with the name of the automation data structure. 2. Migration Control Parameters a) Transport of Migration Control Parameters Customer setting of control parameters can now be included in a transport order. This function is available at the maintenance screen for customer setting of parameters. b) Control Workflow Events and Statistic Updates The parameters P_STAT and P_EVENT in the load report selection screen are obsolete. You can now only control the 'updating of stock and transaction statistics' and 'updating of workflow events' through the control parameters PERF_STATS_OFF and PERF_EVENT_OFF. As default, update is switched off in both cases. Refer to the documentation for the respective control parameters. 3. Enhanced Error Log Evaluation

59 Shosh Friedman

You can now statistically evaluate error logs from import runs. To do this, during the evaluation of migration statistics, mark the statistical data records to be evaluated, then use the pushbutton Statistics. The error messages in the log are sorted by message number and frequency, and are displayed in a list. In the resulting lists, the messages can be sorted by message variable. 4. Analyse Import File You can now analyse import files. Along with the determination of the number of data objects (data type &ENDE), a statistic for the used data types will also be created. You can start the analysis from the import screen, by selecting Analyse. 5. Transport of Distributed Import Profile Data You can now include profile data for distributed imports in a transport order. This function is available at the maintenance screen for the distributed import, in the menu Transport Request Extras. The profile data includes import file entries, but not entries for job distribution. Job distribution data is not transported because the application servers in the target system have different names. 6. Changing the Migration Path at the Import Screen You can now change the migration path at the import screen. This is done by setting the indicator Changes to Migration Path OK in the user parameters. 7. New Functions in File Editor * Display of runtime objects if selected data object could be successfully created in the system.

6.8. Changes in IS-U/CCS 4.72 New Migration Objects/Changes

The following migration objects have been included in version 4.72: 1. DISC_RCORD - Create Reconnection Order 2. MOVE_OUT - Create Move-Out Changes have been made to the following migration objects: 1. PARTNER - Create Business Partner Adjustment of return parameters to transfer parameter Y_NEW_PARTNER for service function module ISU_M_PARTNER_CREATE_DARK. The category of the return structure has changed from ISU01_PARTNER_DATA to BUT000. The return field is now NEW_PAR-PARTNER (previously NEW_PAR-EKUN-PARTNER). New automation data structure BUT0ID (identification number). The structure BUT0ID replaces the structure BUT001. New automation data structure BUT0IS (industries). 2. PARTNERCHA - Change Business Partner Adjustment of return parameters to changed transfer parameter Y_NEW_PARTNER for service function module ISU_M_PARTNER_CREATE_DARK. The category of the return structure has changed from ISU01_PARTNER_DATA to BUT000. The return field is now NEW_PARPARTNER (previously NEW_PAR-EKUN-PARTNER). New automation data structure BUT0ID (identification number). The structure BUT0ID replaces the structure BUT001. New automation data structure BUT0IS (industries). 3. DOCUMENT - Create Open Items Calling event 0910 is replaced by calling event 3910. The previous function module ISU_SAMPLE_0910 and the customer-specific definition of the module can be called from event 3910. Calling event 0920 is replaced by calling event 3920. The previous function module ISU_SAMPLE_0920 and the customer-specific definition of the module can be called from event 3920. 4. PAYMENT - Create payments New posting area 1490 replaces posting areas T032 and R032. 5. INTCASHDEP - Create Interest Document for Cash Security Deposit The transaction code for the interest document is determined in event 1310.

60 Shosh Friedman

Migration Workbench
The following changes have been made to the migration workbench for version 4.72: 1. Changes to migration class methods a) Migration class PARTNER Method BUS1006, for displaying business partners, replaces method ISUPARTNER. b) Migration class ACCOUNT Method CA_CONTACC, for displaying the contract account, replaces method ISUACCOUNT.

6.9. Changes for ERP 2005

The following changes have been made in migration contract account:

Notes:

It is now possible to allocate more than one business partner to a contract account In the VKP structure, fields have been added for the external address numbers The structure INIT has been added (header data) The structure VKLOCK has been added (discconnection data)

For this purpose, the ACCOUNT2 migration object is delivered in addition to the ACCOUNT object. The changes that have been carried out are only available in this object. If you have already created an ACCOUNT object in your own company, you should delete it and copy the SAP ACCOUNT2 object into your company under the name ACCOUNT. In IS-U Version 2.0, the ACCOUNT object will be adjusted the different settings of the ACCOUNT2 object.

New Migration Objects/Changes

The following new migration objects have been added for ERP 2005: 1. DISC_RCENT - Enter Reconnection 2. DISC_CLOSE - Close Disconnection Order 3. DOC_DOUBT - Copy Attachments for Individual Value Adjustment and Doubtful Entries from FI-CA Documents to Trigger File 4. BILLDOCEBF - Create EBF Billing Document 5. BILLTRIGCR - Create Billing Trigger 6. BILLTRIGG - Billing Trigger for Installation 7. MOVE_IN_H - Create Historical Utility Contract Changes have been made to the following migration objects: 1. PARTNER - Create Business Partner Address-independent data must be transferred to structure BUTICOM. The fields used previously in structure BUT000 (field names starting with ICOM_) can no longer be used. The XDFADR field (default address indicator) of structure BUT020 is obsolete and can no longer be used. You can now use the BUT021-ADRKIND field in structure BUT021 to mark an address as the default address (address use: XXDEFAULT). If structure BUT021 is not tranferred, the first address transferred with structure BUT020 is used automatically as the standard address.

61 Shosh Friedman

Migration Workbench
The following changes have been made to the Migration Workbench for ERP 2005: 1. Distributed import a) Start with initialization phase To avoid lock-related problems when generating conflicting ABAP sources, you can reduce the number of import jobs per server for a specific period to one job on each server. b) Alternative job distribution Instead of allocating a special job distribution to every distributed import, you can now allocate a higher level job distribution, which can be used in multiple distributed imports. 2. Group import You can now collect distributed imports in an import group and start them as a group run. You can find this function in the menu under Utilities -> Schedule Import Jobs -> Group Import. 3. Definition of migration objects with BAPI as service module A BAPI can now be converted into a functional complete migration object ( BAPI objects). You can find this function in the menu under Mig. Object -> Create. You can also fin a brief description in section Create BAPI Migration Objects.

62 Shosh Friedman