Scribd
Upload
201 views4 pages

General Configuration On Approval Alerts and Notifications in SAP SRM

This document explains the differences between process-controlled (PC) and application-controlled (AC) workflows in terms of approval alerts and notifications. For PC workflows, notifications are only sent at the end of the approval process, while for AC workflows, notifications can be sent for any document changes or deletions. It also describes how recipients and deadlines are configured for different event types, and provides details on customizing alerts and notifications using BAdIs.

Uploaded by

arunkota
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
201 views4 pages

General Configuration On Approval Alerts and Notifications in SAP SRM

This document explains the differences between process-controlled (PC) and application-controlled (AC) workflows in terms of approval alerts and notifications. For PC workflows, notifications are only sent at the end of the approval process, while for AC workflows, notifications can be sent for any document changes or deletions. It also describes how recipients and deadlines are configured for different event types, and provides details on customizing alerts and notifications using BAdIs.

Uploaded by

arunkota
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

General Configuration on Approval Alerts

and Notifications
Purpose
Usually there is a confusion about approval alerts and notifications. The purpose of this
document is to explain more or less the system behaviour.
Overview
There are some differences between Process Controlled WFL (PC) and Application Controlled
WFL (AC) regarding the way that notifications are dealt. Here you will be able to see Badis and
deadlines alerts that can be used.
Current system behaviour
The application-controlled workflow is quite unrestricted with respect to document changes:
Anyone with valid authorizations may change the document or even delete it. Thus it is
necessary to send out notifications for these events.
With the process controlled workflow, there are strict rules ensuring that all involved parties get
workitems, during the approval process, when documents have been modified.
Therefore there is no need for the sending of notifications during the approval process. However
the process controlled workflow still uses the events 'document approved' and 'document
rejected' at the end of the approval process. So notifications will be sent out at the end of the the
approval process if maintaining the required customising.
Recipients
The intention of the deadline alerts/notifications is to remind the approver who has not approved
in time. Thus they are only sent out to the approver in question.
The configuration for the event framework allows to set recipients "Contact Person",
"Approver", and "Reviewer". These options are only valid for the events Document approved,
document rejected (process-controlled workflow) Document approved, document rejected,
document changed, document deleted (application-controlled workflow).


For any other event the recipients are hard-coded. This also applies to the recipients of deadline
events. Here, if an approver is late in approving, only he will receive a notification/ alert.
We don't allow to extend these configuration options via configuration. However, there is the
BaDI BBP_ALERTING. With its interface method IF_EX_BBP_ALERTING_BADI
~BBP_EVENTS_DET_RECIPIENTS you can add additional recipients or change the
recipients for a certain event.
The BaDI also has another method
IF_EX_BBP_ALERTING_BADI~BBP_EVENTS_DET_CLASS_NAME.
Here you can define a custom class which must be a subclass of
CL_BBP_MESSAGE_CREATE.
This message class is used to call smartforms. By default, the class would call the smartform
"BBP_OUT_EXCEPTION". You can redefine that in method
DETERMINE_FORM_AND_PARAMS and define your custom smartform and any
parameters that you need to pass to the smartform.
Alerts/Notifications (only valid for Process controled workflow)
For event notifications, basically we have the following events:
APPROVAL_PROCESS_DOC_APPROVED
APPROVAL_PROCESS_DOC_REJECTED
APPROVAL_PROCESS_DOC_DELETED
APPROVAL_PROCESS_DOC_UPDATED
In the IMG "SAP Supplier Relationship Management/ SRM Server/Cross-Application Basic
Settings/ Event and Event Schema for Alert Management/ Define Event Schema" at least one of
the events must exist:


For deadline-monitoring of approval work items the following needs to be configured:
In the IMG "SAP Supplier Relationship Management/ SRM Server/Cross-Application Basic
Settings/ Event and Event Schema for Alert Management/ Define Event Schema" at least one of
the events must exist ( note that are approval events and completion events):
WF_APPR_LATEST_END (for an approval level)
WF_APPR_LATEST_START (for a approval level)
WF_APPR_REQUESTED_END (for an approval level)
WF_COMPL_LATEST_START (for a completion level)
WF_COMPL_REQUESTED_END (for a completion level)
WF_COMPL_REQUESTED_END (for a competion level)
And column "deadline" must have an entry in hours. It is possible to have more than 1 entry set.
E.g. you can set
WF_APPR_LATEST_START, 1 hour, notification
WF_APPR_REQUESTED_END, 2 hours, notification
WF_APPR_LATEST_END, 5 hours, alert
This would send 2 notifications after 1 and 2 hours, respectively, and an alert after 5 hours.

For specific requirements it is possible to use the BaDI /SAPSRM/BD_WF_DEADLINES.
Note that the BaDI must return absolute date/time. This allows you to consider weekends,
holidays, and vacations.
PS.: For AC workflow this deadline monitoring is not applicable.
Related Content
Related Documents
Events
Triggering of notifications or alerts - debugging tips
Deadline Monitoring

You might also like