In the last weeks I got lot of questions regarding unexpected read notification if some sap application send email to external recipient.
Here I would like to highlight how the behavior was changed/not changed 🙂
There are 2 important SAP notes which helps to understand the situation:
1734732 and 2065802.
If the note 1734732 implemented or the SAPKB70212, SAPKB72008, SAPKB73008, SAPKB73105 than the ‘transferred’ notification can be requested
without requesting ‘read’ notification at the same time. After this behavior also the standard setting (understanding) was not to request read notification.
I the sender application doesn’t set this property (read notification) than the receiver doesn’t get the popup in his mail client.
After 2 years the note 2065802 was introduced with the following symptom :
“As of SAP NW 7.0 Enhancement Package 2, you can request “Transferred” notifications without requesting “Read” notifications at the same time. SAP Note 1734732 contains required changes that support this function. If the application passes no value or an incorrect value for the request of status notifications, a default setting is used. This always used to encompass the request of all possible status notifications. The changes delivered with the aforementioned SAP Note changed this default behavior so that no more “Read” notifications were requested. However, they are still required, so the new behavior is incorrect”
This means if the note 2065802 or the SAPKB70217, SAPKB72008, SAPKB73013, SAPKB73115, SAPKB74010 applied and the application doesnt set the
request for notification or incorrect value is set, default value will be used. This values are:
deliver = ‘X’.
not_deli = ‘X’.
mailstatus = ‘E’.
read = ‘X’.
I hope this blog helps to understand the old/new behavior of read notification.
The application can set the ‘Send Status’ in the used Output type somewhere here:
A side effect of all of this is that the Confirmation of receipt" setting in SCOT is ignored now and the default setting becomes requesting status notifications for all sent emails. However, note 1607686 provides a solution (a new entry in table SXPARAMS) which corrects this.