SAP Note 25182 - Inconsistencies due to address transport

Symptom:

Inconsistencies can occur in the target system when you transport addresses between different systems or clients.

A) These inconsistencies can be avoided by taking organizational measures.
B) Inconsistencies already existing can be corrected with a combination of organization actions and clean-uo reports.
This note refers to the transport of Customizing data like plants/branches, sales organizations, company codes etc. with the corresponding address data.

This note only applies up to Release 4.5B inclusive.

Other terms

Address, number range, client copy, client transport, transport, storage location address, customer address, address data
BAS_CUSTOMIZING

Reason and Prerequisites

The address table key is an internal sequential number per system and client. Problems can arise when the same number is assigned to two different addresses in the source and target systems.
The transport does not add the address from the source system to the target system address file, the existing address in the target system (with the same internal number) is "changed", that is, in this case it is overwritten with the data of the transported address and is no longer available.

Example 1:
System A System B
Plant US01 has address number 4711 Plant US01 has address number 4584
Plant US02 has address number 4712 Plant US02 has address number 4711
Plant US01 is changed and transported.
Afterwards both plants in system B point to address number 4711. The address of plant US02 in system B has been overwritten.

Example 2:
System A System B
Plant US01 has address number 4711 Plant US01 has address number 4584
Plant US02 has address number 4712 Plant US02 has address number 4622
Number status: 4850 Number status: 4639
Plant US01 is changed and transported.
Afterwards address number 4711 appears in system B with the address of plant US01 although the number status in system B is lower.
If further addresses are created in system B a short dump with a duplicate record might occur when using number 4711. This does not happen automatically: due to the buffer of the number range it is possible to omit numbers; also, the numbers are used as keys for several different tables.

Normally, addresses of Customizing objects (plant, company code, sales organization and so on) are transported by copying the Customizing data in the maintenance transaction into a transport request. This way, the address data belonging to it can also be copied into the transport request.
In the Customizing maintenance transactions of the extended table maintenance (SM30) a warning message appears referring to the conflicts described in this note containing a checklist for avoiding the problem. This warning message appears for all objects with an address, as long as the client must be recorded or the transport mode is used.
Up to and including Release 4.5 the table keys from the source system, that is the internal numbers used there, are used to transport the address data.

As of Release 4.6 the address data is transported via shadow tables. This avoids conflicts with the transport of internal numbers.
If you have problems in Release 4.6 B/C, refer to Note 385440.

Solution

A) Avoiding by means of organizational actions
B) Error correction

If numbers from the same number range have been used in the source and target clients, the complete error correction needs to be performed as described under B). Otherwise, the measures for avoiding future inconsistencies described under A) are sufficient.

A) Avoiding by means of organizational actions
The easiest way to avoid the problem is to execute the following organizational measure:
When maintaining addresses in various systems and clients, make sure that no two number range intervals for the number range object "ADRNR" overlap.
Address maintenance numbers are generally issued internally via the number range 01, for addresses from customizing objects as well as for most addresses from master and transaction data. The number range 01 must thus be maintained in each client in each system before addresses can be entered.
The number range 10 is only used for transaction data that is not transported (for example addresses in SD documents, which deviates from maintenance data or CpD addresses) and should remain unchanged in the context described here.
To avoid these difficulties, you should change the number range interval in each client in each system, so that no two of these intervals for number range 01 (in various systems/clients) overlap.

Proceed as follows:

1. Call Transaction SNRO.

2. Enter the object name "ADRNR".

3. Choose "Number ranges".

4. Choose "Change intervals" on the next screen.

5. Change the number range interval of the number range 01 on the next maintenance screen so that no two intervals in any of the systems and clients overlap.

6. Save the change. (These changes require a particular authorization).

Example:

System A, Client 001: 0.000.000.001 - 0.049.999.999
System A, Client 100: 0.100.000.001 - 0.149.999.999
and so on.
System B, Client 001: 1.000.000.001 - 1.049.999.999
System B, Client 100: 1.100.000.001 - 1.149.999.999
and so on.
To avoid future interval changes, enough space should be left for future systems and clients.
The number ranges in clients 000 (SAP default values) and 066 (Early Watch) are irrelevant and do not have to be changed.
To all addresses which are created in this client in the current SAP system after the interval change a sequential number is assigned from the new interval as a key.
All address numbers assigned before the change remain unchanged.

Please note: The changes of the upper and lower interval limits described are only possible if the number status is initial, that is, 0.
If the number status is not 0, you can, if you have the required authorization, change the number status as follows:

1. Call Transaction SNRO.

2. Enter the object name "ADRNR".

3. Choose "Number ranges".

4. Choose "Change status" on the next screen.

5. Overwrite the status with 0 in the "Number status" field on the next screen.

6. Save the change.

7. You must then make the interval limit changes as described. When the number status has been reset to 0, the new interval must not contain the numbers already assigned. The already assigned numbers are the numbers which lie between the lower limit and the number status of the old interval.

Before reseting the number status in the production system make sure that no data can be entered during this time.

Do not change the number status directly before an upgrade; otherwise, the error described in Note 305365 can occur. If the change is nevertheless made before an upgrade, it suffices if you pick a number the normal way; the error described in Note 305365 does not occur then. Problematic case:

If the following two conditions are fullfilled at the same time, you must first clean-up the data before being able to transport data:

1. Address numbers whose addresses you want to protect from being overwritten were already assigned in this target system client.

2. Address numbers from the same number range were used in source system clients.

Do not carry out number range changes during the time when conversion RSXADR21 is running prior to the upgrade (if that report is executed; see Note 97032).
Before starting Report RSXADR21, all number range changes have to be finished.

B) Error correction

To correct existing errors please proceed as follows:

1. As described under A), make sure that the number range intervals of the address numbers do not overlap in any of the systems involved.

2. In Release 4.0B: Correct the following error:

• Error in function module ADDR_MAINTAIN_COMPLETE: See Note 113242 (corrected by 4.0B Hot Package 03);

• Error in function module ADDR_DELETE: See Note 116008 (corrected by 4.0B Hot Package 05).

3. Make sure that you have the current version of Report RSADRNNR installed in your system. Please note the following:

• Caution: This report is part of the standard programs but this is often an old version which does not take into account a series of special cases which may lead to follow-up problems Therefore, make sure at first that you have the current version installed in your system.

In any case, as of Release 4.0, compare the version number (is given as source code comment at the beginning of the report) of the correction instructions to the version number in your coding. If your coding does not contain any version number, it is obsolete in any case and must be replaced by the correction instructions.

The Support Package specifications in this note do not apply to Report RSADRNNR!

• Report RSADRNNR can be implemented via SNOTE. Please note, however, that the old version of the report is not deleted but the new version is just inserted at the beginning of the source code. Therefore, after implementing via SNOTE, manually delete the old program source code using Transaction SE38.

For manually changing Program RSADRNNR using SE38, you need to enter a modification key. In the program source code, search for key word REPORT. You will find two postitions, the first one in line 1 (beginning of new coding) and the second one in line 795, for example, (beginning of old coding). Delete the coding from line 795 until the end. [The second line number depends on the number of lines in the new coding and may therefore vary]. Afterwards, save and activate the changes.

• If you have user-defined tables that need to be transported containing table fields that refer to addresses in Table SADR (up to Release 3.1I) or ADRC (as of Release 4.0B), you must extend the source code accordingly.

4. Run Report RSADRNNR in the source system.

Report RSADRNNR converts the customizing addresses already maintained (including the reference in the customizing tables) to a new number interval.

If necessary, you can start the program repeatedly.

The parameter 'Address Number from New Range' has the following meaning:

• The parameter is set (default):
  For each address number it is checked whether during runtime it is contained in the then valid number range interval.
  The only address numbers that will be converted are the ones that are not contained in the current interval.
  Reason: If the interval was not redefined or not defined as 'without overlap', conflicts with numbers already in the database might occur again. If the interval was defined correctly, an address number can only be contained in the interval when the program has already been run once so that this number does not have to be converted a second time.
  It is noted in the output log of the report how many address numbers were not converted because they are contained in the current interval.

• The parameter 'Address Number from New Range' is not set:
  It is not checked whether address numbers are contained within the valid range.
  In any case new numbers are drawn from the number range interval which is current during runtime.

The report must run in the source system to have the initial data of all transports cleaned up.

If required, the report may also run in the target system to solve any conflicts existing there - starting it in the target system is not sufficient, however, you also always need to clean up the data that may be imported in other transports from the source system.

5. Check the customizing addresses and maintain them, if required.

6. Only after that, new transports with the data to be transported may be created and transported. Report RSADRNNR must run already before the transports are created. For this reason, delete any transports containing customizing addresses already created since they still contain the old address numbers.

In Release 3.0/3.1 the following errors are known and should be corrected before executing report RSADRNNR:

• If the same address number occurs in SADR and SADRP, the SADR record is not read correctly and thus not converted. This constallation is a data inconsistency. Refer to Note 27846. You can find the corrections in Notes 84893 and 84894.
  Both corrections are implemented as of the following maintenance level:
  3.0D HP 52
  3.0F HP 38
  3.1H correction instruction 84894 as of HP 24, correction instruction 84893 as of delivery 3.1H
  3.1I

• If the SAPoffice default company address (SOPR-USRADR) is also referenced to in a customizing table that is to be converted, the assigned SAPoffice user addresses are deleted.
  You can find the correction in Note 84895. It is implemented as of the following maintenance levels:
  3.0D HP 52
  3.0F HP 38
  3.1H HP 24,
  3.1I
  If the program RSADRNNR was executed without this correction, the following error message is issued when maintaining the SAPoffice user address: 'User is not entered in the address management'.
  In this case proceed as follows:

• Start report RSSOUADD (Transaction SO52) to dissolve the link of the SAPoffice users to the old address numbers.

• Start report RSSOUADR (Transaction SO51) to enter missing addresses in the SAPoffice users from the address management.