SAP ABAP IMG Activity REFXMIV_TIVMIMAPVZSO (Define Transfer of User Fields)
Hierarchy
☛ EA-FIN (Software Component) EA-FIN
   ⤷ RE-FX-MI (Application Component) Migration
     ⤷ RE_MI_CL (Package) RE: Migration RE Classic => RE-FX
IMG Activity
ID REFXMIV_TIVMIMAPVZSO Define Transfer of User Fields  
Transaction Code S_AER_95000227   (empty) 
Created on 20060428    
Customizing Attributes REFXMIV_TIVMIMAPVZSO   Define Transfer of User Fields 
Customizing Activity REFXMIV_TIVMIMAPVZSO   Define Transfer of User Fields 
Document
Document Class SIMG   Hypertext: Object Class - Class to which a document belongs.
Document Name REFXMIV_TIVMIMAPVZSORT    

Use

Generic user fields were available in Classic RE. You could enter up to 12 field contents for each master data object in these fields. The name and meaning of these fields was dependent on a field key that you defined in Customizing.

This logic is no longer used in RE-FX. Instead, you can add any number of fields to the master data tables in an append structure.

Requirements

Standard settings

Activities

In the Analyze Customer Enhancements step, the system checked if you made use of user fields at all in your Classic RE data. If user fields were used in your system, you received the following message in the log:
REMICL 094
There are user fields - check if you want these to be migrated

If you are not certain what user fields were used for in Classic RE, then use transaction SE16 to display the contents of table VZSORT.

You can also use this table to migrate fields that were in the standard system in Classic RE, but which RE-FX does not recognize (example: VIMI01-SGEBSWENR/VIMI01-SGEBSMENR).

For those fields that you want to copy as APPEND fields, you have to add your own user-defined fields to the database tables where they appear. Proceed as described in SAP Note 690900. Before you actually make the conversion, you have to make the database enhancements described in this SAP Note.

The first two characters of the field SOBJEKT of table VZSORT represent the following database tables:


IW - VIBDBE (business entity)
IG - VIBDPR (property/land)
IB - VIBDBU (building)
IM - VIBDRO (rental unit/rental object)
IV - VICNCN (lease-out/general contract)
For the user fields from VZSORT, the field SLWID (key ID) specifies the name of the field in Classic RE, and thereby also its meaning for business purposes.

The following explains the different options for migrating user fields.

  • If you do not enhance the database tables, then user fields are not migrated at all. This is recommended only if you no longer need the values in your user fields. Of course you can always migrate the values in these fields later using programs you write yourself.
  • It could be you do not need a migration that is dependent on the field key (for example, because you only used one field key). In that case, you only need to enhance the database tables for objects with entries in table VZSORT (as in above list) as described in SAP Note 690900. For each field from VZSORT that you want to migrate, add a field with the name ZZ<field name>. <Field name> here is the field name of the field in table VZSORT. For example, you add the fields ZZUSR01 and ZZUSR02 for the rental object in INCLUDE CI_VIBDRO. In this case, you do not have to make any settings in the view for this IMG activity.
  • You may want to do one or more of the following
    • Name the fields in CI Includes yourself
    • Have fields for VZSORT data transferred to various database fields using different key IDs (SLWID) (this is useful in order to later be able to evaluate in reporting correctly)
    • Have field contents transferred that are not in table VZSORT, but are instead located directly in Classic RE master data tables

      In these cases, you have to specify, in this IMG activity, which VZSORT or master data table source fields correspond to which new fields.

      When migrating the data of VZSORT, the system proceeds as follows:

    • For each VZSORT data record and each filled field in this data record, the system first checks if there is an entry where the object type, field key, and field name of the source field agree with the object type, field key, and field name of the field being considered.
    • If a record meeting this criteria is not found, then the system searches again using only object type and field name of the source field.
    • If this record is also not found, then the system searches using only the field name of the source field.

      If the system finds an entry using one of these searches, it then checks if the field is contained in the "Target Field Name" column in the database table belonging to the object type of the VZSORT data record. If the answer is yes, then the field contents are written to this field. If the answer is no, then the system checks if the field ZZ<field name of source field> exists (see above). If the field does not exist, then the field contents are not migrated. You should be aware that the system does not issue an error message in that case!

  • To transfer data that is in the master data tables rather than in table VZSORT, the system proceeds as follows:
    • If the name of the source field does not begin with USR, then the system does not search for the field name in table VZSORT, but searches instead in the given master data table of Classic RE. The field involved can either be a field that you added to the table yourself in Classic RE (makes sense if this field should receieve a different name for the RE-FX migration), or it is a field that existed in Classic RE, but does not exist in RE-FX.
      Leave the field key blank for fields that do not come from table VZSORT.
    • There must be a field with the name "target field" in the CI Include of the RE-FX table. The system migrates the contents of the source field to this field.

Example

  • Example 1 - Fields from VZSORT:
    You used two SLIWDs for Classic RE. SLWID A is named "Management;" the user fields are named
    USR01 - Area
    USR02 - Person responsible
    SLWID A is used for business entities, buildings and properties
    For property (land ) you also have SLWID B, with only one user field
    USR01 - Local subdistrict


    You want to migrate all these user fields. Therefore you enhanced the Includes CI_VIBDBE, CI_VIBDBU and CI_VIBDPR by adding the fields:
    ZZBEREICH
    ZZVERANTW

    You also enhanced the Include CI_VIBDPR by adding the field
    ZZGEMARKUNG


    Make these settings in this IMG activity:

    Type Fld Key Source Field Name New Field Name
    A USR01 ZZBEREICH
    A USR02 ZZVERANTW
    IG B USR01 ZZGEMARKUNG
  • Example 2: Other Fields
    You want to transfer the following fields:
    VIMI01-SGEBSWENR -> VIBDRO-ZZSGEBSWENR
    VIMI01-SGEBSMENR -> VIBDRO-ZZSGEBSMENR
    VIOB03-RPGENR -> VIBDBU-ZZSUPERBDNO
    The contents are "Rental unit linked to" and "higher-level building". These fields no longer exist in RE-FX.

    To transfer these fields to user-defined fields, proceed as follows: In DDIC, you add fields with the appropriate name (for the new field, it must be in the customer name range) to the appropriate CI Include of database tables VIBDRO or VIBDBU. In addition, make these entries in the Customizing table:

    Type Fld Key Source Field Name Target Field Name
    IM SGEBSWENR ZZSGEBSWENR
    IM SGEBSMENR ZZSGEBSMENR
    IB RPGENR ZZSUPERBDNO

Business Attributes
ASAP Roadmap ID 152   Design data acquisition 
Mandatory / Optional 2   Optional activity 
Critical / Non-Critical 2   Non-critical 
Country-Dependency A   Valid for all countries 
Maintenance Objects
Maintenance object type C   Customizing Object 
Assigned objects
Customizing Object Object Type Transaction Code Sub-object Do not Summarize Skip Subset Dialog Box Description for multiple selections
V_TIVMIMAPVZSORT V - View SM30  
History
Last changed by/on SAP  20060428 
SAP Release Created in 700