Changes to the address are not stored when you maintain addresses for organizational units in Customizing or when you maintain business or private addresses of customer contact persons.
If the addresses are on organizational units in Customizing, the note only applies if exactly the following symptom occurs:
If, from the overview of Customizing maintenance (for example, company codes or plants), you choose Edit -> Address (or, on the detail screen, you press "Address" or F17 "Address"), you reach the maintenance screen for addresses.
You make a change and save it (F11).
- 1. The dialog returns to the overview screen of the Customizing maintenance without generating a message;
or
- 2. the misleading message SM810 is generated: "Unable to delete address $" (up to Release 3.1G).
As of Release 3. 1I message SM813 is displayed: "Data inconsistency, address & in table SADRP. Change not possible".
If you branch to the address maintenance screen again, the changes no longer exist but instead the original status before the change.
The error can occur for the following Customizing objects:
- Company codes (Table T001) Transaction OX02
- Plants/branches (T001W) OX10
- Organizational unit: Sales offices (TVBUR) OVX1
- Organizational unit: Sales organizations (TVKO) OVX5
- Organizational unit: Shipping points (TVST) OVXD
Additionally in 2.2 and 3.0:
- Taxes on sales/purchases groups Address OBCM
Address tax office (T007F) OBCF
Additionally in 3.0:
- Personnel areas (T500P)
- Organizational unit: Transportation planning points (TTDS)
- Tax district and reference details (T5G52)
A corresponding error can also occur in Transaction FSAP (company code-dependent reply addresses) since the same address maintenance module is used.
However, here the address maintenance is not called up via the maintenance of an organizational unit but from a separate transaction, which you can find in the Customizing tree under Financial Accounting -> Accounts Receivable and Accounts Payable -> Business Transactions -> Closing -> Count -> Balance Confirmation Correspondence -> "Define reply addresses for balance confirmation".
The note also applies, if business addresses or private addresses are changed by customer contact persons and the following phenomenon occurs:
- 3. If you change data on the address maintenance screen and save the changes (F11), the dialog returns to the preceeding dialog screen without message. If you then goto the address maintenance screen again, the changes you made before no longer exist.
This may, for example, occur when you maintain debtor contact persons (Transaction XD02).
Cause and prerequisites
- 1. Option (screen change without generating a message after saving on the address screen):
Inconsistency in the central address table SADR generally caused by a transport.
The SADR-STDCOM field (type of communication, under the "Country" field) is empty or contains a value other than 'LET'.
The central function module also used for other address maintenance transactions expects a valid entry from table TSADC here.
If you use the maintenance dialog itself, this inconsistency does not occur; the entry 'LET' is always generated in this case.
This problem can occur up to Release 3.x; Release 4.0 uses a new function module for address maintenance in the Customizing.
- 2. Option (message SM810 is generated after saving on the address screen):
Inconsistency between the address tables SADR and SADRP (the same address number is contained as a key in both tables). Also generally caused by a transport.
- 3. Option (Maintenance of business or private addresses of contact persons):
This has the same cause as in Case 1.
This problem can occur in the contact address maintenance up to Release 4.0B. As of release 4.5, the system uses a new function module.
//////////////////////////////////////////////////////////////////////
Caution: This note does not describe the error that two Customizing objects point to the same address number (see 'Related notes').
Solution
- 1. Solution for the first error cause (screen change without generating a message after saving on the address screen): :
The inconsistency can be corrected as follows:
- a) Check whether the entry with key 'LET' exists in table TSADC. The 'Maintain' indicator must have the value 'X' in this case. You can maintain the table using Transaction SM31. As of Release 3.0, also by means of the IMG Transaction SADC (Customizing -> Cross-Application Components -> General Task Functions -> Address Management -> Maintain communication types).
- b) Determine the address number of the address allocated to the organizational unit. This can be found in the "Address" field which is generally called 'ADRNR' and refers to the domain 'ADRNR'.
Example: The address for company code 4321 is specified in the T001-ADRNR field under the key T001-BUKRS = 4321.
You can display the contents of the respective table using Transaction SE16.
Further fields with address reference are:
Plants/branches T001W-ADRNR
Sales/purch.tax grps Address T007F-ADRNR (only 2.2 and 3.0)
Address tax office T007F-FAADR (2.2 and 3.0)
Personnel areas T500P-ADRNR (only 3.0)
Organizational unit: Transp.plan.points TTDS-ADRNR (only 3.0)
Organizational unit: Sales offices TVBUR-ADRNR
Organizational unit: Sales organiz. TVKO-ADRNR
Organizational unit: Shipping points TVST-ADRNR
- c) Call the address maintenance Transaction SAD0, enter the address number determined above in the field provided (with leading zeros) and choose "Change".
Enter the value 'LET' in the "Communication type" field (SADR-STDCOM) in the maintenance screen that follows.
Fill any further required fields with useful values, if necessary.
Save the changes.
- d) The inconsistency is now eliminated. Check whether you can now make the required changes to the address from the Customizing maintenance, and whether these changes are saved permanently.
- e) In Release 2.1 and 2.2, it might be necessary to make a further table setting for the address maintenance Transaction SAD0.
If the error message SM306 "Maintain table TSAVT" is output after you have entered the address number and chosen "Change", maintain the table TSAVT using Transaction SM31.
Include the following entry:
- Language: Your logon language
- Version: Blank (SPACE)
- Description: "Standard"
After saving the value with 'ENTER', the error message SM306 may no longer appear.
Upon completing Transaction SAD0, you can delete the entry from table TSAVT.
- 2. Solution for the second error cause (message SM810 or SM813 after saving on the address screen):
Change the number range interval ADRNR 01 as described in the OSS Note 25182 and then apply report RSADRNNR as described in the OSS Note 25182.
For this, you must use the latest version of report RSADRNNR as described in Note 25182 in order to consider the special inconsistency with message SM810/SM813.
This corrects the data inconsistency.
Additional explanation:
At the program position where error message SM810 is issued up to Release 3.1G, another error message ought to be issued.
The following modification is necessary for this:
Replace the message I810 in Include LSAD2U08 with the message I813. (approximately at line nnn).
Create the message SM813 with the text:
"Data inconsistency, address & in table SADRP. No change is possible"
This program correction is not absolutely necessary to correct the error since the misleading message SM810 does not normally appear, except for the described data inconsistency.
It is sufficent to correct the data inconsistency.
As of Release 3.1H this program correction is contained in the standard system.
- 3. Solution for the third error cause (Maintenance of business or private addresses of contact persons):
If only individual addresses are concerned, proceed as described in the solution for error cause one.
If several or many SADR records in field SADR-STDCOM do not contain any entry, create report ZRSADR27846 in your system and transfer the source code from the attached correction instructions 117861. After executing the report, all SADR records in the field SADR-STDCOM receive an entry and address maintenance will be possible again.
In addition, Note 122916 describes a correction which results in an s message after successful storage.
Additional key words
FSAP, SM810, SM813, T5G52
BAS_OLD
No comments:
Post a Comment