SAP Basis Tech Supports

Symptom
Errors in Time dependent Address communication data.
Other terms
BAS_COMMUNICATION
TIME DEPENDENCY, ADR2, ADRU,R3_USER,
INTERNAL ERROR
AM 086
AM 897
Reason and Prerequisites
This is due to data inconsistency in the address communcation tables ADRU and respective Communication tables like ADR2, ADR3, ADR4, ADR5….ADR13
ADR2….ADR13: Stores communication data with the VALID_FROM &VALID_TO.
ADRU: Stores the corresponding DEFAULT_FROM & DEFAULT_TO.
NOTE:This is not a standard report and hence should always be executed after approval from SAP Development support. This report is a work around to avoid the problems/errors that occurs with time dependency in communication data usage(e.g. Telephone number/mobile number). SAP is not considered as responsible for any improper use of this report.

Prerequisites:
It cannot bring upon the same entries as it was created especially for the inconsistent time dependent data where there are different validities maintained for different communication number.It only tries to adjust ADR2 (or any comm. table) & ADRU with the available validity periods to avoid further errors.If there are overlapping of default from & to in ADRU then this report will delete the existing ADRU entries and creates newly with the reference of ADR2. Incase of default dates are different from validity dates then ADRU default dates will be lost.

It is suggested to run in the batch mode or background job.
This report can also act as a substitute for the report Z_ADRU_CREATE given in the note 966185.
Solution
Z_COMMUSAGE_UPDATE

Copy the source code of report Z_COMMUSAGE_UPDATE from the correction instruction.
——————————————————————-
Z_COMMUSAGE_UPDATE_PRL
For Bulk number of addresses (say above 1 million addresses).
The concept of Parallelization (running the Function Module in various threads simultaneously) has been implemented in this report to maximize the performance. The execution time of this report depends on the Hardware configuration of the Application Server.
Manual activities required.
1) Create a seperate function group in the customer namespace.
for eg. (ZSAP)
2) Then create a function module Z_ADRU_ADJ_PRL in that function group. Please note that in the attributes of this function module you need to choose the processing type as ‘Remote-enabled module’.
3) Add the given import parameters and one table in the Function Module which are given below.
Import parameters:
PARAMETER_NAME TYPE ASSOCIATED_TYPE PASS_ VALUE
IV_COMMTYPE TYPE AD_TABTYPE yes
TABLES:
PARAMETER_NAME TYPE ASSOCIATED_TYPE
SEL_TAB LIKE ADDR_ADDR_PERS_CP_LINE
3) Copy the source code from the correction instruction which is available for function module Z_ADRU_ADJ_PRL.
4) Save and Activate the whole function group.
5) Now you have to copy the report source code into the system. Please create a report Z_COMMUSAGE_UPDATE_PRL and copy the report which is available in the correction instruction. Save it and activate the report.
6) Please run the report (in background job preferred) with the desired variant.
———————————————————————–
Input Parameters to the report:
PCKGSIZE:Which determines number of records to be processed in one thread/cycle. The default value is 1000. This value can be increased depends on the SAP Internal memory.
SERV_GRP:(Z_COMMUSAGE_UPDATE_PRL)
This determines the Application server Group. If there is any special application server given for Background jobs, you can give it here. Default value is SPACE, it picks up the default Application server.
JOB_CNT:(Z_COMMUSAGE_UPDATE_PRL)
This parameter determines the maximum number of threads that should run parallely. This depends on the Hardware capacity of the Application server. Default is ‘10′. Increasing the number to more than 10 will makes the run report finishes more quickly.
SELADR:To Filter the address numbers. Run the report only for the specified Address numbers. If blank, All address numbers will be considered.
ADRU_CRE:In the case where only ADRU entries would be required to create, not to modify/change the existing ADRU entries. If checked, it will create ADRU entries for those Address numbers where ADRU does not exists.
Report performs the following functionalities:

1. This report will update the standard/default Telephone & mobile numbers i.e. ADR2-r3_user, FLGDEFAULT, HOME_FLAG according to the validities maintained for corresponding records in ADRU table. To perform this action correctly, ADRU should have consistent validity periods maintained for the given address number & person number.
Permissible values for ADR2-r3_user are 0, 1, 2&3. It can change between 0 <-> 1 or 2 <-> 3. But not in any other way – meaning 0 cannot become 2 or 3 and likewise.
2. This report also creates entries in ADRU when there is an upgrade from 620 or lower releases to 640 or above releases.
3. Adjust the ADRU entries according to the validities maintained in the ADR2 table. It tries sync up the time dependency validities between ADR2 & ADRU.
In case of inconsistencies in ADRU, with the available validity information in ADR2, it tries to correct the data in ADRU.In case of inconsistencies in both ADRU & ADR2, then this report cannot fix exactly rather it tries to repair with the available validity periods in both ADR2 & ADRU.
4. For records having consistent communication data, no updates will be done.
Suggestions:
For better performance, we suggest you to create an index on ADR2 table with ADDRNUMBER, PERSNUMBER.Run in the batch mode or as background job.