Skip to Content

Frequently Asked Questions about Alerts in SAP Convergent Charging 3.0


When working in SAP Convergent Charging (SAP CC) 3.0 implementation projects with notifications such as amount alerts and expiration alerts, several questions can arise. The purpose of this document is to provide consultants with answers to the frequently asked questions about alerts in SAP CC 3.0.

How does SAP CC send its alerts to SAP ERP?

SAP CC Raters write down the amount alerts and expiration alerts into files. The SAP CC Bulkloaders read the alerts from these files and then send the alerts to SAP ERP calling the 'FKK_PREP_MESSAGE' function. Expiration alerts and amount alerts are respectively transmitted as FKK_PREP_MESSAGE_STATECHANGE and FKK_PREP_MESSAGE_AMOUNT.

Whatever the alerts are, they include at least of the following properties:

·         the prepaid account id (PPACC) for which the alerts have been  triggered;

·         he business partner id (GPART) owner of the related prepaid account;

·         the id of the alert (ALERTCODE).

The FKK_PREP_MESSAGE_AMOUNT has these specific properties:

·         the amount above which the current prepaid account amount is (ALERTAMOUNT, CURRENCY);

·         the balance of the prepaid account when the alert has been triggered (BALANCEAMOUNT, CURRENCY).

The FKK_PREP_MESSAGE_STATECHANGE has these specific properties:

·         the target state (TARGETSTATE);

·         the date when the state of the prepaid account will be changed (STATECHANGEDATE, NUMBEROFDAYS).

There is a specific implementation of the Notifications Framework (which exists since CC1.0 and before) which allows to produce files that the bulkloader can read and push to the ERP system using JCO. By using the Notification Framework:

·         Notifications can be sent to a file using the bulk mechanism;

·         Notifications can be filtered by name, argument value and/or instance type;

·         Notifications are bound to the current transaction.

Is there a framework within SAP ERP/CI to handle these alerts?

The alerts are stored in SAP ERP/CI. On a customer specifications based project the alerts may be used for customer messaging to send SMS or email to the customer but this isn't implemented in standard.

The amount and expiration alerts can only be sent to ERP/CI or to CRM but not both?

SAP CC sends its alerts to one and only one system. SAP CC sends its alerts to SAP CRM if SAP CC is integrated with SAP CRM. SAP CC sends its alerts to SAP ERP/CI otherwise.

Is the number of notification handlers per alert limited to 1?

No, there can be several handlers (com.highdeal.hci.NotificationHandler) for one alert, e.g. one for SNMP, one for CI etc. However, it is recommended to generate only one IT_MESSAGE. As mentioned before, the IT_MESSAGE must be loaded in SAP CRM if SAP CRM is integrated with SAP CC or in SAP ERP otherwise.

Are amount and expiration alerts the only types of alerts?

SAP CC sends to SAP CRM or SAP ERP/CI only expiration alerts and amount alerts. 

Are the alerts being sent directly from the rater or though the bulkloader?

The raters write the alerts in files. The bulkloader reads the files to extract the alerts then loads the IT_MESSAGEs in SAP CRM or SAP ERP.

Are the alerts generated in the regular BIT file format or another file format?

The format of the files is the same as the BIT file format (CSV + header). 

Are the alerts sent via JCO in both cases (to ERP and to CRM)?


Do we no longer support sending alerts in a real time charging API response? Can we no longer send alerts asynchronously to a listener that listens on a SAP CC port?

To store the alerts in SAP CRM/SAP ERP is only a NEW option how SAP CC alerts can be managed. It doesn't replace the already possible options like "asynchronous sending" to a java notification client. The choice of a given option is described in the notification policy.

So even when SAP CC is integrated with SAP CRM/SAP ERP it isn't mandatory to process the alerts in SAP CRM/SAP ERP. You can configure SAP CC to send the alerts to another system listening on the message notification service if that fits better to the customer project. 

Have we enhanced the alerts so that they can include more information from the Subscriber Account such as customer information fields?

In CC 2.0 we don't have this information in the alert unless we add this into the subscription as a parameter and this would be redundant since we already have this on the subscriber account. Alternatively, the listener program has to do a lookup in some external database to be able to route an alert to a customer or include the customer identifiers in the message.

It would be ideal if the alert component allowed including some of the built-in fields that we have access to in the Charged Item Classes as this would solve this issue. For example:

External Account Code


In case of postpaid service charging, it is the code of the postpaid account to be charged. It is defined in the external account of a subscriber account.

Account Code is already in the message but not other fields.

The structure of the amount and expiration alerts is static (i.e. hard coded) and isn't customizable. The structure of the user alert can be defined directly in the charge. Unfortunately even the user alert triggered by the charging plan still doesn't handle charging information like the subscriber account and the external account. This requirement should be included in the list of enhancements for future CC releases.