This wiki is to explain the error message 'AM605 - Assignment of usage AD_DEFAULT to communication type * not unique' that is seen when there is an data exchange (e.g. replicating Business partners, Vendors, etc.) between systems. If you do any change to the communication data and transfer it to another system then there is always a possibility that the consnumber will keep on increasing. Please be aware that the wildcard represents the communication method with which there is an issue.
This error is raised if the field CONSNUMBER in the relevant communication database tables reaches the value 999. For example if the error message is "Assignment of usage AD_DEFAULT to communication type TEL not unique" then the issue lies with address table ADR2. A full list of the business address services communication tables can be found here .
In the communication tables only 999 entries can be stored for the combination of address number, person number and communication type. The highest consnumber is stored in the ADRCOMC table (Communication Data Serial Number Counter). If it is attempted to enter a new entry into a communication table it look for the ADRCOMC entry. If it is found that the entry in the ADRCOMC table has a HIGH_VALUE equal to 999 then the system will throw the AM605 error.
To solve the issue, please run the report Z_OSSNOTE_1070798 from note 1070798 in your target system. This will free the unused CONSNUMBER in the system by re-arranging the consnumbers in the communication table ADR2 to ADR13, by filling up the missing/deleted consnumber in between. It also updates the value in ADRCOMC table. The report produces the log with the address number and Person number in which it has done the repair. If you execute the consnumber adjustment report without specifying the address numbers then all addresses for which the consnumber has reached 999 for a particular communication type will be selected for the report. However if you provide an address number as input to the report then only consnumber related to that address number and that particular communication type will be adjusted. In this case the maximum consnumber need not be 999.
Consnumbers in different systems
Consnumbers are not unique across systems and are generated every time a change is made to communication data. Updating communication data between systems on the basis of consnumber would thus lead to an inconsistency. There is no other field that can uniquely identify the individual communication details across different systems. The 'consnumber' is used by business address services as a counter to maintain the same.
To avoid this scenario in the future, please also ensure that the notes 1406915 and 1487518 are implemented in the target system. These notes are important in order to create unnecessary CONSNUMBERS in future scenarios and so this will help prevent the issue.
Once all these steps are done, please replicate the failed Business partners, Vendors, etc. again and the error should no longer occur.
SAP note 1070798 - Repair the consnumber in communication tables
SAP note 1406915 - Communication data is always time dependent
SAP note 1487518 - Communication data of contact person is not always TD