AttachmentHinweisMigrationV4 5 EN PDF

Migration from Classic RE to RE-FX
Short Documentation and Descriptions of Possible Error Messages
History
Version Date Status (Comments)
Version: 4.5 1.0 02.05.2006 Released
Author: SAP AG 2.0 22.05.2006 Released
3.0 07.06.2006 Released
4.0 31.07.2006 Released
4.1 04.08.2006 Released
4.2 09.08.2006 Released
4.3 05.09.2006 Released
4.4 21.09.2006 Released
4.5. 08.12.2006 Released
© 2005 SAP AG AttachmentHinweisMigrationV4_5_EN.doc Page 1 of 27

Dietmar-Hopp-Allee 16, D-69190 Walldorf
Migration RE-Classic -> RE-FX
Migration from Classic RE to RE-FX

Short Documentation and Descriptions of Possible Error Messages
This document describes the steps of the migration. It also outlines how you can handle error messages that
may occur during the migration. To display the errors, choose Log (icon next to the text of each step). Set
up the display in the log so that the message class (ID) and message number (No.) are visible on the lower
part of the screen, in addition to the message text.
Before you execute a step, read the documentation for that step. To do this, choose the information
icon in the Information column.
The following error message might occur.
REMICL 88 (error)
Dependent steps do not have "no errors" status
In that case, correct the errors that occurred in the previous step. Then repeat the previous step, so that its
status is set to "no errors" or "no errors with warnings." Then repeat the follow-on step.
Note:
Usually a number of test runs are performed before the actual migration. Therefore you set up a test client
as a copy of a live client. If your live client is not already running on release ERP 2005, it is advisable to
wait until after the upgrade of the test system to copy the client. The advantage of this is that you do not
have to repeat the entire upgrade during later repeat runs of the migration.
The names below are used in this document for the clients that play a role in the migration:
- Test client:
Client in which you are currently running the test conversion. You have to set up this client so that
Customizing is recorded automatically.
- Live client
Client in which Classic RE is running live at the moment. This client can be on Release ERP 2005
or earlier.
- Customizing master client
Client which supplies Customizing to the live client. This client is on the same release as the live
client.
- Reference client
Client that is used as a reference for building the test client during the following test runs. The
reference client can be the live client. If the live client is not yet on ERP 2005, it makes sense to
set up a separate system with a copy of the live client and to make a test upgrade to ERP 2005 in
this system. The copy of the live client in this ERP 2005 test system is then the reference client.
If changes to the starting data are needed in order to correct errors, follow these guidelines:
Changes in Classic RE Customizing
Make these changes in the Customizing master client and transport them to the other relevant clients. In this
way, you ensure that already corrected Customizing settings do not cause errors during the next test run and
during the live run.
Changes to Application Data in Classic RE
Make these changes in the test client, live client and reference client.
Manual Changes in Conversion Customizing

Make these changes in the test client and enter them in a transport request. Export this transport request
before you rebuild the test client, or create a BC set with settings from this transport request.
Generated Conversion Customizing/Generated RE-FX Customizing
The system automatically generates most of RE-FX Customizing. You should also save this Customizing in
a transport request, so that you can import it later to the new RE-FX Customizing master client. However,
you do not need this Customizing during the migration test. It is sufficient to save it when the final
migration of your live client is completed.
Preparations in Test Client

Using transaction SE09, create five Customizing requests with the following names:
Request 1: <Test Run ID>: Customizing for Business Partner Conversion
Request 2: <Test Run ID>: Basic Settings
Request 3: <Test Run ID>: Conversion Customizing
Request 4: <Test Run ID>: Manual Customizing Settings RE-FX
Request 5: <Test Run ID>: Automatically Generated Customizing Settings RE-FX
Also create a workbench request with the following name:
Request 6: <Test Run ID>: Application Decisions
When you have carried out the migration completely in the test client, and have tested all follow-on
processes, you have two options:
1. You export Customizing settings from the requests. For requests 5 and 6, you should export in any
case.
If you repeat the test later, you can always import Customizing from the appropriate request for
those steps where Customizing has to be set up or imported.
2. You create BC sets. This approach is especially useful for requests 1 – 4. Create a BC set
(transaction SCPR3) for each request from 1 – 4.
If you repeat the test later, you can always activate Customizing from the appropriate BC set
(transaction SCPR20) for those steps where Customizing has to be set up or imported.
It may be simpler, from an organizational perspective (for instance, authorizations), to activate a
BC set rather than to import Customizing requests.
Reminder:
Before you perform the individual steps, read the documentation for each one (choose the information icon
for the given step).
Step 1: Analyze Dataset

In this step, the system checks if the data of Classic RE is consistent.
If errors occur, you have to correct them before you start the next steps. Not all errors that are found in this
test are critical for the migration. Nonetheless, you should correct the errors before the actual conversion,
since follow-on errors can otherwise occur in the dataset being converted.
Correct the errors as described in the following examples, and then start the Analyze Dataset step again.
The following explains the most important error messages and how you can handle them:

RECACU 11 (error):
<Text>: Value <value> is not allowed for field <table>-<field> (not from <table>)
The system found that there are values in the <field> field in a Customizing table of Classic RE and these
values are not defined in the <table> value table. In some cases the text of the message is too long, so that
the <table> is not displayed. To correct the error, correct Classic RE Customizing (as described earlier)
and transport the correction to the test client. Note: the inconsistencies reported here relate to problems in
your Classic RE data that have to be corrected regardless of the migration process. Therefore, you can also
start this step even if you do not want to migrate data.
Correcting Errors:
a) Select transaction SM30. In the Table/View field, enter the table name from <Tab>. Choose
Customizing. In the dialog box, choose your Customizing project or Continue w/o Specifying
Project. The parts of the Implementation Guide (IMG) of the Classic RE appear where you can
make entries in the table. Select the appropriate activity. To call the maintenance dialog, choose
Continue.
b) In many cases, the system already shows which entries are inconsistent when you scroll through
the maintenance dialog. If this is not the case, then look for the entries for which the <value> value
is in the <field> field. For large tables, you can filter for the value by choosing Selection Æ By
Contents.
If it is a maintenance dialog with a work area, then you have to decide before you enter the
maintenance dialog (in the dialog box) which work area you want to work in. In this case, you can
use transaction SE16 to determine which work areas have entries with errors. The table name for
transaction SE16 is usually the same that you used for transaction SM30.
c) Delete or change the entries with errors. If the entry was mistakenly deleted in the foreign key
table <Table>, then maintain the table (as described in b): SM30 with Table/View <Table>).
REMICL 100 (error):

Conversion error in row <Row> of rep. list of rents control table
An error occurred in row <Row> when the system tried to convert the control table for the representative
list of rents. During this conversion, the old variable names have to be converted to new ones. Not only
that, but it is necessary to enter quotation marks at certain places in the formula text. The system does this
automatically. However, it sometimes happens that the converted string is longer than allowed by the RE-
FX control table.
Change Classic RE Customizing (as described before) so that the string is shorter. To ensure that the
string expresses the same logic as before, it is advisable to get assistance from someone who is familiar
with the logic of the control table.
One possible method for shortening an expression is to use auxiliary variables for storing interim results.
You can access the control table of Classic RE in the standard Implementation Guide (IMG). Choose
Real Estate Æ Rent Adjustment Æ Rent Adjustment Methods Æ Representative List of Rents Æ Special
Calculation Rules
REMICL 26 (warning):
System not able to derive measurement type for apportionment unit <ApUn>
The system found that an additional Customizing setting is required for apportionment unit <ApUn> so that
this apportionment unit can be converted. Normally apportionment units are transferred on a 1:1 basis to
measurement types. However, this is not possible if you had area types in Classic RE that had the same key.
This message informs you that you have to specify new measurement types for the apportionment units
listed here. You do this in the Set Up Conversion Customizing step. You do not have to take any action
until you reach this step.

Enter a maximum number of ROs per collective lease-out
New contract <contract number> would exceed maximum number of ROs, cannot create main
contract
You did not yet make a setting in migration Customizing for the maximum number of collective lease-outs
of Classic RE that can be grouped together in a contract in RE-FX. Therefore, the system does not make
any grouping. If you want the system to group collective lease-outs together, then set the maximum number
of contracts that can be grouped together. You make this setting in step 4, Make Basic Settings. The
warning REMICL 76 then appears only if there are main contracts that contain more individual contracts
than you set.
REMICL 56 (warning)
<m> modernizations exist – no conversion takes place
REMICL 57 (warning)
<n> expert opinions exist – no conversion takes place
The system determined that <m> modernizations and/or <n> expert opinions exist in Classic RE. These
were created in Classic RE for the purpose of rent adjustment, and it is not possible for them to be migrated
automatically.
Normally it should not be necessary to migrate them, since the adjustment was already run in Classic RE.
The Classic RE adjustment data and the expert opinion or modernization are still available for display.
If there are modernizations or expert opinions, for which an adjustment was not yet performed in Classic
RE, then create the necessary adjustment measures in RE-FX after the migration.
REMICL 40 (warning)
Account determination value <value> also used in Customizing <Tab1> and <Tab2>
For account determination values, Classic RE differentiates among these contract types: lease-out,
management contract, and Real Estate general contract. In RE-FX, the system uses the same account
determination values for all three contract types. You have to take further action in the following case: you
use condition types that are allowed for more than one of these contract types, and you want the system to
differentiate the account determination for these condition types using the account determination values. In
that case, you have to define different account determination values in RE-FX, and change the account
determination value of the contracts (either manually or automatically) after the migration using your own
user-defined report.
RECABC 10 (warning)
Assignment of sales-based rent condition types <no.> does not exist
REMICL 44/REMICL 45/REMICL 46 (warning):
Condition type <type>: no <sales-based rent condition type> entered
Here the warning merely informs you that, in migration Customizing, you still have to set up how you want
the sales-based rent conditions to be converted.
REMICL 96 (error)
Starting from <date> both plan and actual items are in cash flow for <contract>
The Classic RE contract still has plan records up to the date <date>. During the migration, the system
determines the date up to which the debit position/periodic postings were run for each contract. The system
sets the Date of First Posting for the new RE-FX contract based on the date determined. This error occurs

when, in Classic RE, follow-up postings are generated, for example, due to retroactive changes to
conditions and these follow-up postings are not yet posted. In this case, it is not possible to correctly
migrate the difference between the old condition amount and the new condition amount. Start the debit
position or periodic posting for the contract in Classic RE. Have the system post as receivables all records
with a Calculation To date that is before the date on which you want the migration to take place. (The
default is selection by the due date - you need to change this.) After this repeat the Analyze Dataset step.
REMICL 107 (Warning)

At least 1 contract has subsidy => BAdI must be activated
For at least one contract condition, you defined that a part of the condition is not paid by the main tenant,
but is instead paid by a subsidizer. To be able to reflect this circumstance in RE-FX, you have to activate a
calculation formula that is implemented using internal calculation formula 1000 – BAdI. Read the long text
of the error message and follow the procedure described there. For more information, see SAP note
996300. You have to create and activate the calculation formula in the Convert Dataset step, at the latest, in
order for the data to be converted correctly and for the cash flow to then be generated correctly.
Step 2: Analyze Customer Enhancements

In this step, the system checks if enhancements were made in your Classic RE system (insofar as this can
be determined automatically). It might be necessary for you to implement these enhancements in RE-FX.
For enhancements and modifications that the system is not able to recognize automatically, you also have
to check if you need to make them in RE-FX, and if so, how this needs to be done.
RECABC 47 (warning)
Field <field name> from table/structure <Classic table name> does not exist in <RE-FX table name>
If you still need the field in RE-FX, proceed as described in the long text of the message.
REMICL 54 (warning)
There is an implementation of BTE <number name> event <event>
The system found that a Customer Exit (BTE) was programmed in Classic RE. Check if this customer-
specific logic can be achieved in RE-FX using standard methods (such as Customizing settings). If not,
check if there is a suitable BAdI for this purpose in RE-FX. The BAdIs available in RE-FX are described in
the Implementation Guide for each given topic in the Implement Enhancements (BAdI) IMG activity.
REMICL 94 (warning)
There are user fields - check if you want these to be migrated
You have user fields in your system. From the long text of the message, jump to the appropriate IMG
activity. The text of the activity describes how you can migrate user fields. You normally make the
necessary settings for this in step 6, Set Up Conversion Customizing. If you decide to make these settings
now, save them in Request 3.
Step 3: Convert Business Partner

In this step, you convert the Treasury business partner, which was used in Classic RE, to the SAP business
partner. The procedure for this is dependent on how you used the Treasury business partner up to now. For
more information, see the documentation for the IMG activities related to this step. In Classic RE, the terms
"real estate business partner" and "Treasury business partner" were used as synonyms. The new business
partner used by RE-FX is called the "SAP business partner." Save the settings you make in Request 1. If
you already made settings in a previous test run, then import the settings from Request 1 before you
execute any further steps in the IMG.

a) If you used the Treasury business partner up to now only for Classic RE, and have not yet
implemented the SAP business partner, choose Conversion: Phase I Æ Execute Conversion Æ
Execute Conversion Reports. A table appears. You have to process the steps in this table one after
the other. To execute a sub-report, position the cursor on the report and choose Execute.
Most of the sub-reports have a test mode. It is advisable to start each report in test mode first, and
then to ultimately start it without setting the Test indicator.
Process the reports in the given sequence. The reports that can be executed are highlighted in
green. The text in the Status column indicates if the report was already executed. To see all the
error messages, expand the logs for each step completely.
Sub-report RFTBUP01 performs the actual conversion. Check conversion Customizing here by
choosing the option Check of Conversion Customizing Only and Test Run. Choose Expand All in
the log, and check for error messages. If errors occur, you have to fill the affected mapping tables.
To do so, choose the IMG activities that are before the Execute Conversion Reports step. When no
further errors occur in this step, execute the report again and choose the Create new SAP BP
option in the Create SAP Business Partner section.
SAP strongly recommends that you use the same numbers for your new business partners.
Therefore you should set the SAP BP No. from TRBP indicator. If you already have many SAP
business partners that are not identical to your Real Estate business partners from Classic RE, but
nonetheless have the same numbers, then it may be useful to choose Standard Number
Assignment. In that case, you have to also execute Phase II of the conversion. But if you chose
Same Numbers and are only converting partners for the Real Estate application, then you do not
have to execute the steps in Phase II.
b) If you perform the RE-FX migration immediately after the upgrade to ERP 2005, and you also
have to perform business partner migration for other areas of Treasury with this migration, then
perform the migration in the Treasury applications. The Real Estate business partners are
converted at the same time.
The Implementation Guide for the migration contains more information. To reach this IMG: in the
RE-FX migration menu, choose the Convert Business Partner step. In the documentation for this
step, choose the Business Partner Conversion link.
c) If you already performed the migration of the Treasury business partner, then you are only allowed
to convert the Classic RE business partner in this step. In this step you proceed as described in step
a), but in sub-report RFTBUP01 you also select the IMMO grouping in the Selection of Treasury
Partner area. If entries are still missing in the mapping tables, this is reported in the log when you
expand it completely.
d) You want to convert the Treasury business partner (TR-GP) and you implemented your own
enhancements, or you were already using the SAP Business Partner for other applications. In that
case you can perform the conversion as described in points a), b) or c), but using in addition the
IMG activities under Conversion: Phase II. Here you have to make settings for which
Customizing values of the Treasury business partner (TR-GP) are converted to the values of the
SAP Business Partner (SAP-GP).
After the business partner conversion, set up Customizing correctly for the new SAP business partner,
especially for customer and vendor roles. Also refer to SAP Note 882801 and Release Information
RE_ECC600_BP. In addition, execute the reports described in SAP Note 851445 in order to adjust the
converted business partner to the requirements of ERP 2005.
This step is placed so early in the overall conversion because the Customizing conversion tables are also
used in part in RE-FX (for instance, address types). These tables also have to be filled for the Convert
Customizing step. The business partner has to be converted, at the latest, by the Convert Dataset step.

Step 4: Import/Make Basic Settings

In this step, you make certain settings that the system needs for the migration. Open the window containing
the documentation for this step. Keep the window open and execute the step. Then you can read the
documentation for the individual fields while you make your settings.
Save the settings you make in Request 2. If you already made settings in a previous test run, then import the
settings from Request 2. Then check, by executing the dialog, if you want to make any changes.
Step 5:
Propose Conversion Decisions for Customizing
In this step, the system analyzes your application data and Classic RE Customizing, and proposes how
Customizing should be converted. You change the results to suit your needs in step 6, Set Up Conversion
Customizing. The system could issue the following messages, among others:
RECABC 10 (error):
Basic settings for migration do not exist
The system found that the you did not yet make basic settings for the migration.
You did not yet perform step 4. Proceed as described there.
REMICL 48 (Warning)
No new SC key for directly assigned costs for SC key <SC key> and app. unit <AU>
In Classic RE, a settlement unit can be "directly posted" (or assigned) if the appropriate indicator is set for
the apportionment unit assigned to it. In RE-FX, a settlement unit can be directly posted if the appropriate
indicator is set for the service charge key.
When analyzing the data, the system found that there are settlement units in your system that can be
directly posted. To be able to convert these settlement units, you have to specify which service charge key
you want to use for them. You specify this in the Import/Specify Conversion Customizing step. The system
cannot automatically use service charge key <SC key>, since it could be that this service charge key is used
in other settlement units that are not for direct posting. You have to enter the service charge key you choose
in RE-FX Customizing (Service Charge Settlement ( Master Data of Settlement Unit ( Define
Service Charge Keys) in the Direct Cost Posting column.
Step 6: Import/Specify Conversion Customizing

In this step, you set up conversion Customizing. Read the related sections of the Implementation
Guide. You can decide to already make the settings here for RE-FX-Customizing that are referred
to in the text – but it is also possible to make these settings later in the Set Up RE-FX
Customizing step.
Save the settings you make in Request 3. If you already made settings in a previous test run,
then import the settings from Request 3. Then check, by calling the appropriate IMG dialogs, if
you want to make changes to these settings. Possibly you could have a different combination of
application data in the current run as compared to the test run, so that it may be necessary to
make more settings than those you saved previously.

Step 7:
Propose Conversion Decisions for Application Data
In this step, the system analyzes your application data and Classic RE Customizing, and
proposes how your application data should be converted. You can change the results to suit your
needs in the Import/Specify Conversion Decisions for Application Data step.
The messages that are issued here are largely due to the fact that you did not make necessary
settings in a previous step. For example, some of the messages listed below might appear.
(Some messages from the previous steps can also appear here, if you did not yet make the
necessary settings in the meantime. These repeated messages are not described again here.)
New contract type required for old contract type <V> and own usage
The system found that an additional Customizing setting is required for contract type <V> so that
this contract type can be converted. For this contract type, there are contracts for both own use
and third-party use. Therefore, you need two contract types in RE-FX.
This message informs you that you have to specify a new contract type for the contract types
listed here. You do this in the Set Up Conversion Customizing step. You do not have to take any
action until you reach this step.
RECABC 10 (warning)
Assignment of sales-based rent condition types <No.> does not exist
REMICL 46 (Warning)
Condition type <No.>: no minimum rent condition type entered
Both messages are displayed when you have sales-based lease-outs in Classic RE, but you did
not specify in migration Customizing which sales-based rent condition type is to be used, or which
condition type is used for minimum rent. If you do not enter the necessary information in
Customizing before the actual migration, the system does not consider the affected sales-based
lease-outs.
Step 8: Convert Customizing

In this step, the system fills the Customizing tables of RE-FX that are affected by the migration,
based on the settings you have made and your Classic RE Customizing. The errors that can
occur include:
REMICL 86 (error)
Company code <CoCd>, country <Ctry>: tax code <TC> is invalid
or
REMI50 14 (error)
CoCd <CoCd>, zero tax code <TC>: cannot determine tax type/tax group
You did not define a tax type/tax group in conversion Customizing for one of the tax codes that is
entered in the company-code-dependent settings in Classic RE (see long text of the error
message).
REMICL 33 (error)
Measurement type <Mtyp> was assigned 2 times

In the Set Up Conversion Customizing step, you assigned the same measurement type to an
area type and apportionment unit that were not linked with each other in Classic RE. You have to
correct this setting by assigning different measurement types before you repeat step 7.
REMICL 68 (error)
Measurement type <meas> for <purpose> does not exist in Customizing
In migration Customizing, you entered a measurement type for the reference area or for volume
that cannot be derived from Classic RE Customizing. Create the measurement type in the Set Up
RE-FX Customizing step. Choose RE-FX Standard Implementation Guide ( Master Data ( Basic
Settings ( Measurements and make the necessary settings. At the minimum, the measurement
types should be set as allowed for rental objects. For the reference area, check if it not more
useful to use a measurement type that can be migrated automatically from Classic RE (such as
the measurement type that was assigned to the standard apportionment factor, "Living/Usable
Area").
REMICL 93 (error)
No address type entered for address ID <ID>
For the conversion of the business partner, you did not enter an address type for address ID <ID>. Enter the
address ID (Convert Business Partner step, choose IMG activity: Conversion Phase I Æ Assign TR BP to
SAP BP Æ Assign Customizing Settings Æ Address ID).
Note:
If this error occurs, then it could mean that the mapping tables are also not filled for other Customizing
settings. Therefore, you should also check the other settings that come before the Execute Conversion
activity in the IMG.
The log for the business partner conversion shows that there are missing settings. However, you only see
these messages when you expand the log completely.
Choose the following step:
Conversion: Phase I -> Execute Conversion -> Execute Conversion Reports
Position your cursor on sub-project RFTBUP01, then choose Last Log. Expand the log
completely. The log displays warning or error messages about the missing settings. Make the
needed Customizing settings. Save your changes in Request 1. Then update the converted
business partner data by starting sub-project RFTBUP01 again, with the same options you used
for the original business partner conversion. On the Create SAP Business Partner tab page, this
time choose the Correct SAP BP option Then check the fully expanded log to see if all errors are
now corrected.
Perform the Convert Customizing step of the Classic RE conversion again.
Step 9: Set Up RE-FX Customizing

In this step, you add to and complete the settings that were automatically made by the system. Read the
documentation of the related IMG activities.
At this point the whole RE-FX Implementation Guide is available to you, so you can also make settings
that are not related to the migration. The documentation of the first IMG activities describes specifically
what settings are absolutely required so that your system behaves the same after the migration to RE-FX as
it did before the migration.
Save the settings you make in Request 4. If you already made settings in a previous test run, then import the
settings from Request 4. Then check, by calling the appropriate IMG dialogs, if you want to make changes
to these settings.

Step 10: Check Customizing

In this step, the system checks the settings you made up to now to see if they are complete and consistent.
The system checks both table contents that were generated by the migration and table contents that you
entered manually.
The system could issue the messages below, among others. Keep in mind that some messages, which are
still warnings in this step, could still lead to error messages during the later steps of the conversion!
Therefore, you should also correct the causes of warning messages!
REMICL 89 (warning, possible error later)

Status profile <Profile> is not assigned to the real estate contract
When contracts are migrated, the user status is also migrated. In order for the status profile to be copied on
a 1:1 basis, the status profile <Profile>, which you used for the contract with the object number entered, has
to be defined as allowed for real estate contracts. If the status profile <Profile> is also used in application
data, you have to make sure it is allowed for real estate contracts, otherwise the later conversion is not
possible. The procedure to follow is described in the long text of the message, and also in the
documentation below for message REMICL 87.
This warning leads to an error in the Convert Application Data step, if the status profile <Profile> is
assigned to lease-outs or management contracts.
REMICL 58 (error)
No reference flow type for object transfer was assigned for <FlType> <FlType Text>
Flow type <FlType> is found in the application data. In order for the application data to be converted
correctly, you have to assign a reference flow type for object transfer (relationship type 30) to this flow
type.
In the Set Up RE-FX Customizing IMG activity, create the missing flow type, and assign it as a reference
flow type. Read the IMG documentation for both activities. In the dialogs linked to this documentation, set
up the account symbols and account determination for these flow types. You have two options for the
account for transfers: You can either use the same account that the document was posted to originally, or
you can use a separate account, so that you can distinguish the original revenue posting from the transfer
posting. In the second case, you may have to have your accounting department set up the account first.
Note: the transfer has to be posted with same tax code as the original costs or revenue posting, so you have
to make sure that the correct tax type is set up for the account.
Also keep in mind that this message always appears if you customized your cash deposit flow types in
Classic RE. If this is the case, then set up the requested flow types. You then have to correct any affected
contracts manually after the migration has taken place.
REMICL 59 (error)
Service charge key <SC key> is not designated for directly assigned costs
See warning REMICL 48 in the Propose Conversion Decisions for Customizing step. There is also a
description there of how to correct the error.
RECABC 14 (warning)
List status profile per object type is empty for partial key ISC

Lease-outs are converted to real estate contracts. As part of this process, the system also copies the user
status of the lease-out. Therefore, it is necessary that all user statuses that were previously allowed for
object category IVT are now also allowed for object category ISC.
Choose transaction SE16, table TJ21, object category IVT. On the next screen, check which status profiles
are assigned to the object category.
In the IMG for the Set Up RE-FX Customizing step, choose:
General Settings for Master Data and Contract Æ User Status Æ User Status and Activity Control
Position the cursor on status profile <Profile> and choose Goto ( Object Types. Scroll down to the
RE: General Contract entry (this is the technical name for the general contract in Classic RE and
the real estate contract in RE-FX). Set the indicator for this entry. Save.
Step 11: Export RE-FX Customizing

In this step, the system places the whole of your RE-FX Customizing (including the settings that
the migration program itself generated) in a transport request. Use Request 5 for this. You need
this transport request so that you can import it to your Customizing clients after the migration of
your live system. Therefore, it is sufficient if you generate the request after the actual conversion.
For you to be able to export your Customizing, the setting for automatically recording changes in
Customizing must be active for the clients in which the conversion is performed. If you export
from your live client, set this indicator before the export and reset it as soon as the export has
taken place.
If you want to repeat the test conversion more than once, it is not necessary to import the
Customizing settings stored in this request for each new test. Instead you simply have to save the
Customizing settings, which you make manually, in a transport request or BC Set (one request or
BC Set per step). Then, in the next test run, you can import the transport request or activate the
BC Set rather than executing each "Set Up" step. The system automatically records the settings
in a transport request, if the client is set up accordingly. If you want to use BC Sets, you can
create a BC Set from each generated Customizing request after the test migration is completed.
Step 12:
Specify Conversion Decisions for Application Data
In this section, you specify the contract numbers for new contracts. The system proposes the
contract numbers, for which you need to make a decision. One category that you have to make
decisions for are all contracts, for which the contract numbers were duplicated (for example, the
number was used for both a lease-out and a Real Estate general contract). In this case, you have
to decide which contract should have which number after the conversion. You are only allowed to
keep the old number for one of the two contracts.
In addition, you have to make decisions for all contracts that were assigned to a collective lease-
out in Classic RE. You need to decide if you want to transfer them to RE-FX as collective
contracts (the new contract number is the number of the collective contract), or if you want to
have a separate contract in RE-FX for each individual contract in the collective lease-out. The
system proposes that you treat the contracts as collective contracts. In the basic settings (step 4),
you specified the maximum number of contracts that can be transferred to a contract in RE-FX. If
you have collective lease-outs that contain more individual contracts than the number you
specified, then the system proposes that all of these individual contracts be transferred to RE-FX
as separate, independent contracts (Independent Contract). But you might want to group them
together nonetheless. In that case, specify that one of the contracts is a leading contract. For the
contracts belonging to the leading contract, enter the new contract number of the leading contract

in the New Contract No. column. Then choose Contract Is Merged or Canceled in the Coll.LO
column.
On the other hand, you might want individual contracts, even though the system proposes
grouping contracts together. Then, in the New Contr. No. column, enter the value from the Old
Contr. No. column, and choose Independent Contract for the contract in the Coll. LO column.
Theoretically, you can also change the numbers for other contracts here. However, we
recommend you do so only in exceptional cases, for example, if the number of a single old
contract does not agree with the convention you used otherwise throughout the system.
Save the settings you make in Request 6. If you already made settings in a previous test run,
then import the settings from Request 6. Then check, by calling the appropriate IMG dialogs, if
you want to make changes to these settings. This is especially necessary if new collective lease-
outs were added since the last conversion that the transport request belongs to.
Step 13: Export Conversion Decisions for Application Data

In this step, the application decisions are placed in a transport request. Use Request 6 for this.
You can immediately set this step to Completed if you already placed the application decisions in
a transport request in the previous step. (The system does this automatically, if you set up the
client as recommended.) You can also set this step to Completed if you want to enter the
application decisions again manually during the next test conversion.
After you perform this step, check if the entries are really in the transport request by using
transaction SE09. If the client is not set up for automatic transport, then creating the transport
request does not work. For technical reasons, however, the system does not issue an error
message in that case!
Step 14: Convert Dataset

In this step, the system actually converts your Classic RE dataset to the new tables in RE-FX.
Most of the errors that can occur here are due to your not having made settings that should have
already been made before. Analyze the error log and correct any errors.
Then leave the transaction (so that the Customizing buffers can be initialized).
Call transaction REMICL again, and execute this step again. Repeat this procedure until no more
errors occur.
Possible errors, if not already described above:
REMICL 87 (error)
Status profile <profile> is not allowed for <profile>
When contracts are migrated, the user status is also migrated. In order for the status profile to be
copied on a 1:1 basis, the status profile <Profile>, which you used for the contract with the object
number entered, has to be defined as allowed for real estate contracts.
In the IMG for the Set Up RE-FX Customizing step, choose:
Position the cursor on status profile <Profile> and choose Goto -> Object Types. Scroll down to
the RE: General Contract entry (this is the technical name for the general contract in Classic RE
and the real estate contract in RE-FX). Set the indicator for this entry. Save. The error no longer
occurs after that.
REDB 2 (error)
Key <Key> (INTRENO) in table <Tab> does not exist
REDB 3 (error)
Key <Key> (OBJNR) in table <Tab> does not exist

REDB 4 (error)
Key <Key> (IMKEY) in table <Tab> does not exist
REMICL 24 (error)
Not possible to convert table <Tab> due to previous error
This error can occur if the table <Tab> could not be generated due to another error. For example, the
system writes each migrated lease-out to table VIMIMAPINTRENO. Then, when the system builds the
contract-object relationship table, VIOBOV, it reads from table VIMIMAPINTRENO which new object
number the old lease-out has. For example, if the contract could not be migrated due to error REMICL 87,
then the entry in table VIMIMAPINTRENO was also not written, so that the above error message is issued.
First correct all other errors and then restart the conversion. If this error is the only one that occurs during
the conversion, contact SAP Support.
The following message has the same cause, and you handle it in exactly the same way:
REDB 1 (error)
<Text> <Text> does not exist
(For example, mapping of old internal key fields to new <Number> does not exist)
RECABC 14 (warning)
List status profile per object category is empty for partial key ICG
Comparative groups of apartments have a status object in RE-FX, but do not have one in Classic RE. If you
want to use user statuses for this status object, define a status profile in Customizing. Choose:
Choose Goto Æ Object Types. Scroll to the RE: Comparative Group entry. Set the indicator for
this entry in the first column. Save. Note: the status profile is only automatically assigned to the
comparative group if the status profile was already uniquely defined before the conversion step.
Since no user statuses were defined in any case in Classic RE, you can also set the status profile
manually when you need a user status.
REMICL 92 (error)
No leading contract <New Contr> for contract <Old Contr>
You specified that the <Old Contr> should become part of the <New Contr>. However, there is no <New
Contr> . It is also not entered in the conversion decisions as New Contract Number and designated as
Leading Contract or Independent Contract. It could be that you made a typing mistake when entering the
new contract number. If you want the contract to be generated by the system, then specify that the contract
is an Independent Contract in the Specify Conversion Decisions for Application Data step.
REMICL 93 (error)
No address type entered for address ID <ID>
This message and the procedure for it were already described above.
RECAAP 10 (error)
No number was entered (despite external number assignment)
When converting a Classic RE master data table, the system found that the logical key of the table was
empty. There is a data inconsistency in Classic RE. Use the detailed error log to check which table the error
occurred in (for instance, VIMI15 – Comparative Apartments). Display the table using transaction SE16,
and look for the record with a blank key. Delete the data record using a program or the enhanced functions
of transaction SE16N.

60 599 (Warning
Area for rental unit <Business Entity> <Rental Unit> not found
When trying to convert an area-based condition type, the system could not find the reference area. The
error most likely occurred because Customizing in Classic RE was changed after the contract/rental object
was created.
The system issues only a warning here. When converting this condition, the system uses the area type you
entered in the basic settings for the migration. If you do not want the system to use this area type for this
condition, you have two options. You can change the condition in Classic RE so that it is no longer area-
based. (Whereby you also might need to enter the "correct" non-area-based condition value.) Or you can
change Classic RE Customizing so that the condition type is assigned to the desired area type, or so that the
reference area can be used.
RECABC 10 (error)
Assignment of sales-based rent condition types <No.> does not exist
REMICL 44/REMICL 45/REMICL 46 (error):
Condition type <type>: no <sales-based rent condition type> entered
You have sales-based lease-outs in your system, but you did not specify which condition types are used for
their conversion.
You have to group all condition types appearing here into condition groups manually, if they come into
play with sales-based rent lease-outs. If SAP Note 951073 is implemented in your system, then the system
automatically recognizes unassigned condition types in the Run Required Postprocessing step and issues
error message RECD 241. However, it is still better to set up Customizing correctly before you start the
Run Required Postprocessing step.
REMICL 99 (error)
<Contract>: Sales-based rent agreement begins ( <date>) before contract start ( <date> )
For the Classic RE contract <contract>, the start date of the sales-based rent agreement is before the
contract start date. Correct the contract in Classic RE.
Step 15: Run Required Postprocessing

Some data required for RE-FX is not transferred directly from the corresponding Classic RE tables, but is
instead generated by the system from migrated data. The system generates this data in this step. (This
includes, for example, settlement participation, cash flow, tax information for FI documents, advance
payments for service charges from Classic RE.) To generated this data, programs are needed that have as a
prerequisite that RE-FX is active. Therefore, activate the RE-FX component, before you execute this
step. The documentation for this step contains a link to the IMG activity for making this setting.
If you also want to migrate land registers, then activate Land Use Management (LUM) in addition.
(These functions are country-specific for Germany at the moment. In the IMG, choose Country-Specific
Settings Æ Germany Æ Land Use Management Æ Central Settings Æ Activate Subapplication).
Call the migration again.
Caution: Do not, under any circumstances, call the dialogs for creating and changing RE-FX data or
RE-FX reports before you have successfully completed this step! Otherwise the migrated data could
become inconsistent.
Particularly if you used parallel processing for the conversion, it makes sense to use program
RFREMILOGVIEW to evaluate any errors. This program displays an ALV grid showing the error
messages and the objects where the errors occurred. You can define your own variants, for example to
display the total number of errors per object or the total objects for each error message.
Any errors that mean that the target object cannot be generated (for instance, during migration of the land
register) are not recorded in this log – the prerequisite for being shown in the log is that an object was

generated. Errors that mean that the target object cannot be generated are recorded in the main log for the
step where they occur.
You can view details about the errors in the normal error log. If there is a message with a "detailed log" for
a main error message, you can access this detailed log using the detail button of the message. Here you can
see, for example, the object for which the error occurred.
The system could issue the following messages, among others:
REDSBD 007 (error)

Rental object <MO>: occupancy history does not exist
REDSBD 004 (error)
Rental object MO <No.>: Occupancy <Date 1> to <Date 2> for contract <Contr> does not exist
This error can occur if you changed the attributes of the automatically generated contract types. The new
contract types, which are used for Classic RE lease-outs, have to be set up so that the objects are rented and
the Offerer/User field is set to Offerer. For general vendor contracts, the Offerer/User field has to be set to
User and the contract reference has to be Objects are leased-in or Other Reference. For management
contracts, the Offerer/User field has to be set to Offerer and the contract reference has to be Objects are
managed.
RECD 077 (error)
Sales tax data does not define input tax
The tax data assigned to the contract does not agree with the Offerer/User field of the contract type. The
cause for this is either the same as for errors REDSBD007 and 004, or else the conversion table for the tax
code was maintained incorrectly. In the second case, check which tax type is assigned to the posting term of
the contract with the error. And check which tax code is assigned to this tax code in Customizing. Choose
Accounting ( Integration FI-GL, FI-AR, FI-AP ( Taxes ( Assign Tax Codes.
If Offerer is set in the contract type, then the tax code has to be for output tax.
If User is set in the contract type, then the tax code has to be for input tax.
RECD 241 (error)
Condition type <Condition Type> is not assigned to condition group <Condition Group>
Customizing for conditions is not correct. A condition type, which is used in a contract or rental object, is
not assigned to the correct condition group. Normally, the assignments of condition types to condition
groups is migrated automatically, based on your Classic RE Customizing. However, this does not apply to
condition types that did not exist in Classic RE, such as the sales-based rent condition type. Check the
rental object or contract for which the message was issued, and assign the condition type to the correct
condition group in RE-FX Customizing. For more information, see the long text of the message.
REBPBP011 (error)
There are gaps in assignment of required role <Role>
This error occurs, for example, for contracts, when a role was specified as mandatory in Customizing, but
this role is missing on the contract (or other object). In the case of contracts, it could also be that the main
contractual partner role for the contract type is missing on some contracts. Either assign a partner with the
necessary role to the contracts, or correct the Customizing settings. You can access the roles in
Customizing for RE-FX. Choose:
Business Partner Æ Relevant Settings for Business Partner in RE Context Æ Business Partner Roles Æ
Assignment of Role Categories to Real Estate Applications Æ Make Settings for Roles per Object Type

To specify the role for the main contractual partner for the contract, choose:
Contract Æ Contract Type Æ Define Contract Types
RELM xxx
If you had land registers in Classic RE, the system tries to convert these automatically. The system uses the
standard BAPIs for data transfer. In RE-FX there are considerably more consistency checks in the land
register (especially with regard to date fields). Therefore, it is possible that a land register number cannot be
transferred because the Classic RE data was inconsistent. Some typical errors are explained below.
In this case, you can either change the land register manually, or you can change the Classic RE data of the
land register and then run the conversion again. If you want to change the Classic RE data, you first have to
deselect the RE-FX indicator. To most easily see the changes that have to be made, choose the hierarchical
log in the upper part of the screen. The system displays the land register number of the Classic RE land
register there. The new external number is not the same!
Any changes you make for the test conversion also have to be made in your live data and possibly in the
reference client. This is necessary so that you do not encounter the same errors during the next test run and
later when you migrate your live client.
Before you start this step again, you have to again activate RE-FX, and then call the migration transaction,
REMICL, again.
RELMLR 77 (error)
Rights and easements <Sect.><Entry>: RE register entry <No.> canceled <Date>
In the Classic RE land register, choose Real estate register. Double click on the entry with the number
<No.>. On the date <Date> , the entry is designated as deleted (= For indicator not set); in other words, the
entry is canceled. If the indicator was not set due to an oversight, than set the indicator. Otherwise, check
the date starting from which the entry is referenced in <section>, and correct the date entries as needed. The
determining date is the date of the change. You can see this date in Sections 2 and 3, by double clicking on
the given entry.
RELMLR 75 (error)
Rights and easements <Sect.><Entry>: No servient tenements assigned
There is an entry in section <Sect.> that does not have a valid parcel assigned to it. Assign a number from
the real estate register to the entry, or else delete the entry.
RELMLR 30 (error)
<Sect.><Entry>: Enter date of addition or removal
The date of the addition or removal is missing in section <Sect.>. Enter this date.
RECABC 10 (error)
Unit of measure does not exist
The system could not convert a land register because a necessary specification for the area is missing. Most
likely the basic settings are not complete in Customizing for Land Use Management.

RELMLR 34 (warning)
Owner <Name> is not assigned in the land register
This is just a warning. Owners are assigned to the Classic RE land register in Section I, although there is no
entry in Section I. In the migrated land register, the system copies the owner to the partner list, which is not
referenced in the sections of the land register. Therefore the system issues a warning message.
Step 16: Check Converted RE-FX Dataset

In this step, the system performs formal checks of all master data that was created. The checks are the same
as those performed when you choose Object Æ Check when displaying the given object. The simplest way
to correct any errors that occur is to correct them in the master data dialog of the object.
A helpful approach is to start transaction RE80 in a second session and display the object for which the
error was reported. You receive the error message, when you choose Check. Then you can use the detail
button to jump directly the application data that caused the error.
Note: The first time you start the dialog for a given object type, the system generates all necessary technical
data for the dialog, so that the call can sometimes take several minutes. To speed things up, it is advisable
to first generate the technical information for all master data dialogs. To do so, start report
BDT_DELETE_DYNPROS and select Delete All Subscreen Containers. Then start transaction BUSP. In
the Application object field, enter RE* and BUPA using multiple selection. Choose All screens and execute
the report.
To analyze the errors that are found when the system checks the dataset, you can also use program
RFREMILOGVIEW to systematically display errors for each generated object. From there you can double
click on the object ID (key of the object) to go directly to the object.
If the same error occurs for a large number of master data objects, and you do not know how to correct
these errors efficiently, contact SAP Support. SAP Support can give you tips on how to avoid or correct the
error. At the same time, you are helping us to improve this documentation.
After the errors are corrected, start transaction REMICL again (to delete the Customizing buffer). Start the
check again to ensure that the objects really do not have any errors.
Some errors that may possibly occur are described below:
REBDOA 005 (error)

Objects of type <Object Type> are not allowed to be assigned to <Object>
In Classic RE, object assignments were entered that are not allowed based on RE-FX Customizing. To
improve performance, the system does not check all Classic RE application data at this point during the
migration of Customizing.
The problem can be solved easily: Either jump from the message long text directly to the IMG
activity, or in Customizing for RE-FX, choose General Settings for Master Data and Contract Æ
Assignment of Objects from Other Components Æ Assign Functional Locations/Fixed
Assets/Projects/CO Orders.
Change the Customizing settings so that the assignment is allowed.
If <Object> is a real estate contract, then you have to keep the contract type in mind when
making your settings.

REBPBP 023 (error)

Enter the value of a coownership share
In the standard system, RE-FX assumes that when an owner is assigned to an object, then the
coownership share belonging to the owner is also entered. However, this share was not entered.
Either enter the ownership share on the partner screen of the objects involved, or enter the
ownership share in your Classic RE data in your live system.
If the message affects a very large number of objects, or the ownership shares are not known,
you can also change the message to a warning or information message in Customizing. In
Customizing for RE-FX, choose Tools Æ Configurable Messages Æ Change Message Control.
RESCHS 007 (error)

Assignment of measurement type to basic component is missing
There are three basic components for the settlement of external heating expenses: heating, hot water and
other. If you have settlement units that are settled externally (in Classic RE these were called heating
systems), then you have to assign at least one of these basic components to a measurement type in
Customizing for the measurement types. During the conversion of Customizing, the system copied the
setting from Classic RE. However, in Classic RE, it was possible to have multiple assignment of the same
basic component to more than one different apportionment unit. (The apportionment unit that was actually
used was selected randomly.) For Customizing in RE-FX, this is no longer consistent. Correct the
Customizing settings by assigning a given basic component to only one measurement type. It is best if you
also correct Classic RE Customizing in the Customizing master client at the same time, so that the error is
avoided in the next test run and in the live run.
RESCSP 011 (warning)

There is no suitable settlement participation for condition <Cond> RO <RO> from <Date>
Condition types, which are defined as advance payments or flat rates, are assigned to a lease-out. However,
based on the current Customizing settings and the existing settlement units, this condition will never be
considered during a settlement. Although this is only a warning, you nonetheless need to take action! In
Classic RE, the system considered all advance payment conditions during a full settlement of heat expenses
and service charges, even if the conditions were not included in the settlement participation. But RE-FX is
more exact in this regard. If you do not make any changes, then any advance payments posted for this
condition remain open as special G/L items on the credit side after the settlement. The system does not
transfer them as payable credit memos, and they are not displayed in any correspondence. The simplest
method of getting around this problem is to create a settlement unit for the business entity for the next open
settlement period, and ensure that the service charge key of the settlement unit agrees with condition type
<cond>. The participation group for this settlement unit must contain rental unit <MO>. The service charge
settlement then settles the costs. For the next settlement period, it is advisable to change the contracts so
they only use service charge settlement condition types that agree with the service charge keys.
RECACU 011 (error):

<Text>: Value <Val.> is not allowed for field <Field> (not from <Table>)
Follow the procedure described in Step 1.
Step 17: Postprocessing

Here the system converts data that is uncritical with regard to the following test (see the next unit,
Additional Steps in Text System). The following are converted:
- Memos for master data
- Transfer of directly assigned costs from Classic RE

- Transfer of advance payments made (for service charges and sales-based leases) from Classic RE
The Postprocessing and Required Postprocessing steps are separate in order to improve performance. For
example, you can already test periodic postings in the test system before the Postprocessing step is run.
You can also choose to run periodic posting while the Postprocessing step is still running.
However, testing service charge settlement and sales-based settlement does not make sense until the
Postprocessing step is completed.

Additional Steps in Test System

Once all formal errors in your application data have been corrected, then begin testing your processes. (The
following contains only a limited selection of some important processes. Naturally, you only need to test
those processes you actually use.) While testing your processes, it could be that you notice Customizing
settings are still missing, or that there are additional Customizing settings you should make to be able to use
RE-FX most effectively. Save any entries of this kind, that you make during the test, in Request 5.
Master Data:
Before you test the processes, you should first make random checks of some objects to see if all data was
transferred correctly. Select a few representative business entities, buildings, land, and rental objects. For
the rental objects, choose a few different usage types. For contracts, choose different contract types. If you
had them in your system, choose contracts that were (collective) lease-outs, Real Estate general contracts,
and management contracts in Classic RE. (For management contracts, there is important additional
information below.) Also check settlement units, business partners, and other master data.
For comparing the master data in Classic RE and RE-FX, it is best to use transaction RE80 in RE-FX. For
the Classic RE master data, you can use the display transaction for the given object, which you choose from
the SAP Easy Access screen.
If problems arise with the business partner, first search for SAP Notes that can help. Some common errors
are described in SAP Notes 851445 and 931355.
Giving Notice on Contracts

Simulate the possible notice dates and check if the results agree with your expectations. Give notice on
some contracts. Check if the contract terms of the individual objects are correct, especially for contracts
that were grouped together.
Manual Changes to Contracts

Call various types of contracts in change mode. Compare the displayed data with the data of the Classic RE
contract. Create new contracts for objects that you gave notice on previously.
Periodic Posting
First simulate periodic posting for the first RE-FX period (starting with the date you set in the basic settings
in Customizing). Then execute the periodic posting in update mode.
If you forgot to completely enter the account determination for any newly defined flow types for transfer
repostings, then the system issues error messages to that effect.
Another error message that might be issued here is
REEXFI 001 Account assignment not possible until object released
This message is issued when there is an active lease-out in Classic RE for a rental object that is not
released. In RE-FX, newly created rental objects are released automatically, based on the assumption that
you create rental objects in order to assign them to a contract at some point in time. The rental object has to
be released, because distribution postings from the contract are assigned to the rental object. (This was not
the case in Classic RE.) Release the affected rental objects in the master data dialog. If you need to release
a relatively large number of rental objects, follow this procedure:
- Choose transaction RE80. On the upper left hand side of the screen, choose Find Object.
- Choose the Rental Object object type, and choose Find.

- Select the objects.

- Click on the object IDs one after the other and choose Release.
Another method would be to change the distribution formula in the contract so that there is no longer any
distribution to the rental object. However, you should keep in mind that distribution, at least at the level of
the business entity or building, is advisable for object-related Controlling. For rental objects that participate
in service charge settlement, you always need a distribution formula that distributes to the rental object in
any case.
To prevent the problem from appearing again during the next test run, release the rental objects in the
Classic RE reference system and in the live system.
F5 788 – Reconciliation account <Account> or short key 00 is not permitted

If this error occurs, you most likely assigned an asterisk (*) as an account symbol to a reconciliation
account in Classic RE.
In RE-FX, to have the system use the reconciliation account of the customer or vendor, you have to make
sure that no account is assigned to the account symbol. Check in the Assign Account Symbol to Flow Type
IMG activity to see if the same account symbol is used for debit and credit flow types for the subledger
account side. If it is, then delete the account assigned to this symbol in the Replace Account Symbols IMG
activity. The system then uses the account that is in the vendor or customer master data for the posting.
You might want to use a fixed reconciliation account instead. In that case, define different account symbols
for debit and credit postings. Assign them to the corresponding flow types and enter the reconciliation
account you want to use.
After periodic posting, call the Period Overview - Actual for the fiscal year (transaction REISCOCSTACT)
and check if the data appears correctly in CO.
Service Charge Settlement:

In Classic RE, you can make certain settings when executing service charge settlement, but these same
settings are part of the settlement parameters in RE-FX. Therefore, before you test service charge
settlement, you should first check if the settlement parameters automatically created during the migration
meet your requirements. (In Customizing, choose Service Charge Settlement Æ Settlement Process Æ
Define Settlement Parameters). You have to make your own country-specific settings for the settlement
parameters, for example, if you want to use the current occupancy principle or have special needs for
changing tax rates (common in Switzerland). Note: If your first settlement in RE-FX needs to consider
advance payments that were posted in Classic RE, it is not possible to use the actual principle (recognizing
only actual payments). If you selected the actual principle in the settlement parameters, the system ignores
this setting during the first settlement. We recommend that you set the Post Balance indicator, unlike in
Classic RE.
In some countries, you also need surcharges (for example, in Switzerland or in Germany for the
apportionment loss risk). If you need surcharges, you have to define a surcharge schema and assign it to the
settlement parameters. For commonly used settings for surcharges in Germany and Switzerland, there are
reference surcharge schemas in standard Customizing. You can use these as a reference.
Once you have checked your settings, simulate a service charge settlement for the next open period. Pay
particular attention to whether the advance payments for service charges were taken into account.
Remember that for migrated advance payments, it is only possible to use the planned principle. Perform an
update run for service charge settlement, and check the results. Look particularly at several rent accounts to
see if the open items are correct.

If Customizing for service charge settlement is not yet fully complete, then the system issues messages to
that effect.
RECABC 10: Reference flow type <Cat.> <FlType> does not exist
If this error occurs, you forgot flow types when setting up RE-FX Customizing. Call transaction REMICL
again. Choose the IMG in the Set Up RE-FX Customizing step. Read the documentation for these activities:
Define Flow Types and Assign Reference Flow Types. This documentation explains which reference flow
types you need for service charge settlement, and how to set them up. Remember to also set up the
corresponding account determination.
If the test company code opts (with regard to input tax - applies primarily in Germany), then the following
error can also occur during final settlement).
REITOR 14: No option rates have been determined for period <From> to <To>
RE-FX, in contrast to Classic RE, allows the option rate for rental objects and occupancy contracts to differ
from 0% and 100%. Therefore, you are required to perform option rate determination before executing
settlement. Normally this would take place monthly, along with option rate determination for the other
objects. After the migration, you can use report RFREIT_OPT_RATE_CALC_SCS to copy the option rate for
rental objects and contracts for settlement periods that were not yet settled.
Option Rate Determination and Input Tax Distribution

Start the option rate determination for the next posting month, and check if the results are plausible. Post
invoices related to real estate objects (in the form you anticipate for invoices in the live system after the
migration) and perform input tax distribution for them. Check if the input tax is distributed correctly.
In RE-FX, input tax distribution is also possible for projects, orders and cost centers that are assigned to a
real estate object. If you want to use this function, you have to set up Customizing accordingly, and assign
these objects to real estate objects as needed. For more information, see the documentation, the Release
Information, and the Implementation Guide.
If you want to use one-time postings for posting invoices, you also have to set up Customizing for that. You
can use standard Customizing as an example.
Sales-Based Settlement
Enter sales reports for the next reporting period. First simulate the settlement and then execute the actual
settlement. Check the results, especially the clearing of down payments and handling of minimum and
maximum rent.
Note:
In Classic RE, it was necessary to post minimum rent as an advance payment. From an accounting
viewpoint, it makes more sense to post minimum rent (and possibly the additional advance payment) as
revenue. If you want to post in this way, set up the conditions for this for a test contract, starting with the
next settlement period. Test if the results of periodic posting and settlement meet your expectations. If you
want to have the system convert all your sales-based lease-outs automatically, you can use API module
API_RE_CN_CHANGE to change the conditions.
Adjustment of Conditions (Various Adjustment Methods)

Check if the results are plausible. For index adjustments, we recommend that you enter the probable index
status for the next period in the test system, and then check if the adjustment results are plausible. For
adjustment using a representative list of rents, you can easily compare the results of a test run in RE-FX
with the results in Classic RE – the same rent should result for the same rental objects. Check to make sure
the minimum intervals and rent caps are properly adhered to when contracts are adjusted.
Management Contracts
Note that it is not possible to migrate management contracts completely. For each management contract,
the migration program creates a real estate contract. To convert the fee types, you have to assign conditions
with suitable calculation formulas. A few common calculation formulas for management contracts are
predefined in standard Customizing. If these do not meet your needs, you have to implement your own
calculation formulas using the BAdI BADI_RECD_CONDITION.
Also be aware that management contracts can only post either on the debit side or the credit side. If you
need both debit and credit postings, you have to create a second contract and link the conditions of the two
contracts.
Appendix
Data That Is Not Migrated
The following describes the most important data that is not migrated by the standard migration programs.
This explanation is not from a technical viewpoint, but instead is based on the perspective of the end user.
Be aware that only the most important tables and fields are described here. If you are not sure if a particular
table is migrated, then perform a test migration and then check to see if the table was migrated.
In the table below, the last column contains the name of the transaction you can use to create the data
manually, and the name of the function module that can be used to create the data automatically. Before
you can use these options, you have to make the necessary Customizing settings for the given function.
Function Not Migrated Because … As Required

Rental Request Most of the data is no longer needed TA REORRR /
for current day-to-day activities FB BAPI_RE_SR_CREATE
Offer Most of the data is no longer needed TA REOROF
for current day-to-day activities1) FB BAPI_RE_OF_CREATE
Expert opinion Most of the data is no longer needed TA REAJAT
for current day-to-day activities FB BAPI_RE_AT_CREATE
Modernization Most of the data is no longer needed TA REAJAT
for current day-to-day activities FB BAPI_RE_AT_CREATE
Security deposit data Represented in the system by a TA RECN /
separate contract in RE-FX FB BAPI_RE_CN_CREATE
Rooms There are different options for Add using SAP Note 969234 or
representing these in the system in use the architectural view (TA
RE-FX. There are no system functions REBDAO /
that use rooms2) FB BAPI_RE_AO_CREATE)
Completed service charge Migrating completed processes is -
settlements unnecessary and also not possible for
technical reasons
Completed rent adjustments Migrating completed processes is -
unnecessary and also not possible for
technical reasons3)
Correction items/correction No corresponding functions in See SAP Note 968671
objects standard RE-FX in ERP 2005

Land Use Management Classic RE functions not in standard Contact SAP Germany
Addon system
Condominium Management Classic RE functions not in standard Contact SAP Germany
Addon system
Individual fields, such as No function for this in RE-FX Create the fields as user fields
Rental unit linked to for the rental object (as
Higher-level building described for "User Fields")
1)
Migration of offers will be made available by the end of 2006 with delivery in a Support Package.
2)
However, migration is available for the number of rooms of a room type that exist for a rental unit.
3)
However, the system does migrate data for rent adjustments that were not yet activated in Classic RE.
Excluding Certain Datasets from Migration

Some customers have data in their Classic RE system that is not needed in RE-FX. This could be the case,
for example, if the entire real estate holdings of a company (company code) were sold. The data of that
company code is then no longer needed for day-to-day operations. .
However, for technical reasons, this data is initially transferred to RE-FX. (The conversion is made for each
database table, and not for each business object. Therefore it is difficult to exclude individual data records
without reducing performance.) However, you can have the system delete this data before you run
postprocessing in RE-FX.
To do so, you have to make entries in table TIVMIBODEL, which you maintain in the view
V_TIVMIBODEL.
In the first "Type" field, enter the type of object that you do not need any longer in RE-FX. The system
only considers those object types that are in the following table. The Key column shows how many
characters a field of the concatenated key consists of. (The letter A stands for the number of characters of
the first field, the letter B for the number of characters of the second field, and so on.) The third column
indicates which fields these are (do not enter the slashes): The name shown is the technical name of the
field in the RE-FX table.
OT Object Type Key Fields in Key (A/B/C/D) Cnv

IW Business entity AAAABBBBBBBB 4/8 BUKRS/SWENR Cust
IG Land AAAABBBBBBBBCCCCCCCC 4/8/8 BUKRS/SWENR/SGRNR Cust
IB Building AAAABBBBBBBBCCCCCCCC 4/8/8 BUKRS/SWENR/SGENR Cust
IM Rental object AAAABBBBBBBBCCCCCCCC 4/8/8 BUKRS/SWENR/SMENR Cust
IS Real estate contract AAAABBBBBBBBBBBBB 4/13 BUKRS/RECNNR Cust
I4 Participation group AAAABBBBBBBBCCCCCCCCCC 4/8/10 BUKRS/SWENR/PGID Yes
I1 Settlement unit AAAABBBBBBBBCCCCDDDDD 4/8/4/5 BUKRS/SWENR/SNKSL/SEMPSL Yes
I7 Comparative group of AAAABBBBBBBBBBBBB 4/14 BUKRS/COMPGRP Yes
apartments
IU Land register AAAAAABBBBBBBBBBBBBBB 4/15/15 LRDISTRICT/LRVOLUMENO/ No
CCCCCCCCCCCCCCC LRPAGENO
Note:
- Enter the BOR key of the migrated object. In some cases, this key can have more characters than the
corresponding key in the Classic RE object (for example, for comparative group of apartments). If the
object is converted (see last column of table: "Cust" means that this can be set up in Customizing), then
the system automatically generates leading zeros for a numeric key, and you have to enter these
leading zeros when entering the key. For example, you do not want rental object 1, of business entity
47, in company code 0001 to be transferred to RE-FX. Then, with conversion switched on, you have to
enter object type IM and key 00010000004700000001. If, however, conversion is switched off, then
the key receives 6 spaces (number of places for SWENR minus actual number of places of business
entity, that is, also 8 – 2): 000147 1.
- You can make a generic entry for part of the key using an asterisk (*). For example, if you do not need
rental objects for company code 0005 and business entity 4711 in RE-FX, enter object type IM and key
000500004711*.
- Or, for example, if you do not need the transferred data for an entire company code 0005, then enter
0005* for each of the object types listed above (with the exception of the land register).
- You have to ensure that your system data does not become inconsistent. For example: If you exclude
business entity 000100004711 from the transfer, but do not make any settings for buildings, property,
rental objects and contracts belonging to this business entity, problems occur. The checks in the Check
Converted RE-FX Dataset step find errors, for instance, because there are rental objects in the system
that relate to a business entity that no longer exists.
The contents of the table have to be available at the latest in the Run Required Postprocessing step. Objects
with the necessary keys are deleted in this step. You might have contracts in your system that need to be
neither migrated nor checked (because no debit position was run for them in Classic RE for a long time). In
that case, make sure that the table is filled with the appropriate contract numbers for them before the first
step. The system then does not check these contracts.
Utility Programs After Migration

Generating Pooled Spaces and Rental Spaces
If you want to create pooled spaces and rental spaces for the data you migrated, you can use the program
below.
RFREBDCREATEPSFROMRU
This program converts rental units to pooled spaces. The rental unit must exist already. This report is useful
if you were using the CRE Addon. In that case, your "vacancy rental units" were transferred during the
migration, and it makes sense to convert these to pooled spaces. Even if you created rental units for other
reasons in Classic RE for later use as pooled spaces, you can use this report for creating pooled spaces from
those rental units.
However, it could be that you did not already create objects analogous to pooled spaces, and you want to
create new pooled spaces for certain buildings, for example. In that case, it is simpler to create them
manually using transaction REBDRO, or automatically using function module BAPI_RE_RO_CREATE.
The report displays the selected rental units. In the first column, you can select the rental units you want to
convert to pooled spaces. Choose Save to convert the rental units to pooled spaces. You should be aware
that it is not possible to reverse this action! Therefore we strongly recommend that you first execute a test
run (this is the default).
The error log indicates if a conversion is not possible due to incorrect data. A possible reason for such an
error could be that the usage type of the rental object is not allowed for pooled spaces. In that case, correct
your RE-FX Customizing before running the report again.
RFREBDCREATERSFROMRU
The program converts rental units to rental spaces, and assigns the rental spaces to a pooled space. You
have to start the report again for each pooled space you want to assign rental spaces to. It does not matter
whether you created the pooled space manually, using a BAPI, or using program
RFREBDCREATEPSFROMRU.
The procedure here is similar to the procedure for program RFREBDCREATEPSFROMRU. However, you
have to enter the pooled space, to which you want to assign the selected rental units, on the initial screen of
the report. In addition, you can specify how measurements are updated on the assigned pooled space using
the Increase Measurements on Pooled Space indicator.
If you set this indicator, then the capacity of the pooled space is increased by the measurements of the
assigned rental spaces. The pooled space then has its original measurement amounts, plus all measurements
of the rental spaces assigned to it. You should use this setting if the pooled spaces is based on a vacancy
rental unit from CRE, or if the pooled space was created without measurement values.
If this indicator is not set, then assigning rental spaces to the pooled space does not change the capacity of
the pooled space. The available size (= measurement amount not yet divided into rental spaces) is reduced
by the measurements of the assigned rental spaces.
If the size of the pooled space is not large enough to allow this, the system issues error message:
REBDMS027:
Measurement amount <Meas.> (from <Date>) is not available on pooled space <No.>
This indicator is not allowed to be set, if the overall capacity of the pooled space was correctly entered
when it was created.


AttachmentHinweisMigrationV4 5 EN PDF

Uploaded by

Copyright:

Available Formats

You might also like

AttachmentHinweisMigrationV4 5 EN PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AttachmentHinweisMigrationV4 5 EN PDF

Uploaded by

Copyright:

Available Formats

Migration from Classic RE to RE-FX

Short Documentation and Descriptions of Possible Error Messages

© 2005 SAP AG AttachmentHinweisMigrationV4_5_EN.doc Page 1 of 27

Migration from Classic RE to RE-FX

© 2005 SAP AG AttachmentHinweisMigrationV4_5_EN.doc Page 2 of 27

Preparations in Test Client

Step 1: Analyze Dataset

© 2005 SAP AG AttachmentHinweisMigrationV4_5_EN.doc Page 3 of 27

REMICL 100 (error):

© 2005 SAP AG AttachmentHinweisMigrationV4_5_EN.doc Page 4 of 27

© 2005 SAP AG AttachmentHinweisMigrationV4_5_EN.doc Page 5 of 27

REMICL 107 (Warning)

Step 2: Analyze Customer Enhancements

Step 3: Convert Business Partner

© 2005 SAP AG AttachmentHinweisMigrationV4_5_EN.doc Page 6 of 27

© 2005 SAP AG AttachmentHinweisMigrationV4_5_EN.doc Page 7 of 27

Step 4: Import/Make Basic Settings

Step 6: Import/Specify Conversion Customizing

© 2005 SAP AG AttachmentHinweisMigrationV4_5_EN.doc Page 8 of 27

Step 8: Convert Customizing

© 2005 SAP AG AttachmentHinweisMigrationV4_5_EN.doc Page 9 of 27

Step 9: Set Up RE-FX Customizing

© 2005 SAP AG AttachmentHinweisMigrationV4_5_EN.doc Page 10 of 27

Step 10: Check Customizing

REMICL 89 (warning, possible error later)

© 2005 SAP AG AttachmentHinweisMigrationV4_5_EN.doc Page 11 of 27

Step 11: Export RE-FX Customizing

© 2005 SAP AG AttachmentHinweisMigrationV4_5_EN.doc Page 12 of 27

Step 13: Export Conversion Decisions for Application Data

Step 14: Convert Dataset

Key <Key> (OBJNR) in table <Tab> does not exist

© 2005 SAP AG AttachmentHinweisMigrationV4_5_EN.doc Page 14 of 27

Step 15: Run Required Postprocessing

© 2005 SAP AG AttachmentHinweisMigrationV4_5_EN.doc Page 15 of 27

The system could issue the following messages, among others:

REDSBD 007 (error)

© 2005 SAP AG AttachmentHinweisMigrationV4_5_EN.doc Page 16 of 27

© 2005 SAP AG AttachmentHinweisMigrationV4_5_EN.doc Page 17 of 27

Step 16: Check Converted RE-FX Dataset

REBDOA 005 (error)

© 2005 SAP AG AttachmentHinweisMigrationV4_5_EN.doc Page 18 of 27

REBPBP 023 (error)

RESCHS 007 (error)

RESCSP 011 (warning)

RECACU 011 (error):

Step 17: Postprocessing

- Transfer of directly assigned costs from Classic RE

© 2005 SAP AG AttachmentHinweisMigrationV4_5_EN.doc Page 20 of 27

Additional Steps in Test System

Giving Notice on Contracts

Manual Changes to Contracts

© 2005 SAP AG AttachmentHinweisMigrationV4_5_EN.doc Page 21 of 27

- Select the objects.

F5 788 – Reconciliation account <Account> or short key 00 is not permitted

Service Charge Settlement:

see if the open items are correct.

Option Rate Determination and Input Tax Distribution

Adjustment of Conditions (Various Adjustment Methods)