Several alerts can be set up to monitor the mandates management module. SPS will generate alerts when the following conditions apply:
| An R-Transaction was received | |
|---|---|
| Object | When the application received a R-transaction, an alert is send to the creditor |
| Information | > Information about the R-transaction: - Creation date - Scheme - Reference - SCI - Due date - R-Transaction stat - Cause of the reject - UMR - UIR - Remittance - Information - Debtor name - Debtor external id |
| Template | [ALERT] An alert based on the rule [R-transaction reception] has been detected. The transaction was rejected due to the reason [{rejectreason}]. Creation date: {creationDate}/UNKNOWN Reference: {originalEndToEndId}/UNKNOWN Due date: {dueDate}/UNKNOWN Amount: {amount}/UNKNOWN R-Transaction status: {status}/UNKNOWN Remittance Information: {remittanceInfo}/UNKNOWN SCI :{sci}/UNKNOWN UMR :{umr}/UNKNOWN UIR :{uir}/UNKNOWN Debtor name : {debtorName}/UNKNOWN Debtor external id : {debtorExternalId}/UNKNOWN Source: {source}/UNKNOWN |
| An SDD/SCT creation failed | |
|---|---|
| Object | > When the creation of a When the creation of a transaction failed (SDD or SCT), this alert notifies the reason of the rejection to the creditor. Caution: if the creation fails because of missing E2EID, no alerts will be raised because in that case it is not possible to identify the failed transaction |
| Information | > Information about the SDD/SCTReject: - Due date - Reference - Scheme - Status - Amount - Payment reason - Cause of the reject |
| Template | The template for SDD creation failed is : [ALERT] An alert based on the rule [SDD Creation Failure] has been issued. The creation of the SDD failed due to the reason [{rejectreason}]. The related SDD is: Reference: {endToEndId}/UNKNOWN Amount: {amount}/UNKNOWN Remittance information: {remittanceInfo}/UNKNOWN Due date: {dueDate}/UNKNOWN Scheme: {scheme}/UNKNOWN Status: {status}/UNKNOWN Source: {source}/UNKNOWN The template for SCT creation failed is : [ALERT] An alert based on the rule [SCT Creation Failure] has been issued. The creation of the SCT failed due to the reason [{rejectreason}]. The related SCT is: Reference: {endToEndId}/UNKNOWN Amount: {amount}/UNKNOWN Remittance Information: {remittanceInfo}/UNKNOWN Due date: {dueDate}/UNKNOWN Status: {status}/UNKNOWN Source: {source}/UNKNOWN |
| A “Waiting” SDD/SCT was created | |
|---|---|
| Object | When the creation of a transaction is on “waiting” status because the associated mandate is waiting his validation, incomplete, or waiting accessibility, this alert notifies the creditor that he must validate the transaction. |
| Information | Information about about SDD/SCTReject: - Reference <br- Amount <br- Cause of the reject <br- Due date <br- Scheme <br- Status <br- Cause of the reject |
| Template | [ALERT] An alert based on the rule [Creation of a SDD with Status WAITING] has been issued. The SDD which has triggered the alert is: Reference: {endToEndId}/UNKNOWN Amount: {amount}/UNKNOWN Remittance information: {remittanceInfo}/UNKNOWN Due date: {dueDate}/UNKNOWN Scheme: {scheme}/UNKNOWN Source: {source}/UNKNOWN |
| Set a transaction to the status “obsolete” | |
|---|---|
| Object | A transaction is “obsolete” when the due date or the SDD date is invalid. This alert notifies the creditor that he must change the due date. |
| Information | Information about the SDD/SCT: Reference Due date Amount Scheme Cause of the reject Cause of the reject |
| Template | The template for SDD in obsolete status: [ALERT] An alert based on the rule [Creation of a SDD with Status Obsolete] has been issued The related SDD is: Reference: {endToEndId}/UNKNOWN Amount: {amount}/UNKNOWN Remittance information: {remittanceInfo}/UNKNOWN Due date: {dueDate}/UNKNOWN Scheme: {scheme}/UNKNOWN Status: {status}/UNKNOWN Source: {source}/UNKNOWN The template for SCT in obsolete status: [ALERT] An alert based on the rule [Creation of a SCT with Status Obsolete] has been issued. The related SDD is: Reference : {endToEndId/UNKNOWN Amount : {amount/UNKNOWN Remittance information : {remittanceInfo}/UNKNOWN Due date : {dueDate}/UNKNOWN Source: {source}/UNKNOWN |
| A mandate creation failed | |
|---|---|
| Object | This alert notifies the creditor when a mandate creation failed. |
| Information | Information about the mandate: - SCI - UMR / UIR - Scheme |
| Template | [ALERT] The creation of a mandate failed for the reason: [{rejectreason}]: {rejectReasonMessage}. The mandate reference associated with this alert is: UMR: {umr}/UNKNOWN UIR : {uir}/UNKNOWN SCI: {sci}/UNKNOWN Scheme: {scheme}/UNKNOWN Source: {source} |
| An SDD that previously failed was resubmitted | |
|---|---|
| Object | This alert notifies the user if an SDD that previously failed for insufficient funds was resubmitted by the system |
| Information | Information about the SDD: - SCI - Reference (old new) - Scheme - Amount |
| Template | [ALERT] An alert based on the rule [Automatic reissuing of a rejected SDD] has been issued The SDD which triggered the alert is: Reference: {endToEndId}/UNKNOWN Amount: {amount}/UNKNOWN Remittance information: {remittanceInfo}/UNKNOWN Due date: {dueDate}/UNKNOWN Scheme: {scheme}/UNKNOWN Source: {source}/UNKNOWN |
| Mandates were purged from the system | |
|---|---|
| Object | This alert indicates the number of the purged mandates |
| Information | - SCI - Number of the purged mandates - Root Organization : organization label and external ID |
| Template | [ALERT] The mandate cancellation has been successfully handled by the SPS system Root Organization: {organization label} ({externalID}) SCI: {sci} | Number of cancelled mandates: {mandatetotal} SCI: {sci} | Number of cancelled mandates: {mandatetotal} SCI: {sci} | Number of cancelled mandates: {mandatetotal} … Source : {source}/UNKNOWN |
| An SDD’s due date was changed | |
|---|---|
| Object | This alert informs the creditor that the due date of an SDD was changed. |
| Information | Information about the SDD: - Reference (old new) - Amount |
| Template | [ALERT] An alert based on the rule [Adjustment of the payment date] has been issued The related SDD is: Reference: {endToEndId}/UNKNOWN Amount: {amount}/UNKNOWN Remittance information: {remittanceInfo}/UNKNOWN Due date: {dueDate}/UNKNOWN Scheme: {scheme}/UNKNOWN Source : {source} |
| A PSR file referring to an unknown pain.002 was received | |
|---|---|
| Object | This alert notifies the creditor that a PSR file referring to an unknown pain.002 was received |
| Information | Information about the payment status file: - Reference - Type |
| Template | [To Do] |
| A PSR file referring to an unknown collection was received | |
|---|---|
| Object | This alert notifies the creditor that a PSR file referring to an unknown collection was received |
| Information | Information about the SDD Collection: - Reference - Number of transactions - Total amount |
| Template | [ALERT] The following RTransactions file contains an unknown/incorrect collection reference. Reference: {orgnlPmtInfId}/UNKNOWN Number of transactions: {orgnlNbOfTxs}/UNKNOWN Amount: {orgnlCtrlSum}/UNKNOWN Source: {source}/UNKNOWN |
| Set a collection to the status “obsolete” | |
|---|---|
| Object | An alert is sent if the status of the collection is « obsolete » because of the invalidity of the due date |
| Information | Information about the SDD Collection: - Due date - Reference - Scheme - Number of transactions - Account number - Total amount - Sequence type |
| Template | [ALERT] An alert based on the rule [Transaction Collection is obsolete] has been issued. The transaction collection related to this alert is: Reference: {collectionRef}/UNKNOWN Number of transactions: {collectionObjectSize}/UNKNOWN Amount: {collectionTotalAmount}/UNKNOWN Due date: {dueDate}/UNKNOWN Scheme: {scheme}/UNKNOWN Sequence type: {sequenceType}/UNKNOWN Source: {source}/UNKNOWN |
| Update of a mandate after the integration of a CAI | |
|---|---|
| Object | This alert notifies the creditor if a mandate was update after the reception of a CAI |
| Information | - UMR / UIR - Name file of ACMT 022 |
| Template | [ALERT] The debtor account of the mandate {umr} has been updated after integrating an ACMT022 message. The originating filename is : {source} |
| Update of a bank account after the integration of a CAI | |
|---|---|
| Object | This alert notifies the creditor if a bank account was update after the reception of a CAI |
| Information | - Name of the third-party - Name file of ACMT 022 |
| Template | A bank account has been updated for the ThirdParty {name} after integrating an ACMT022 message. The originating filename is : {source} |
| Creating/Editing several mandates with the same UIR | |
|---|---|
| Object | When an existing Active Mandate is automatically switched to Suspend because of a new Active Mandate or an existing Mandate becoming Active, an alert is raised to user to inform him if the Organization subscribed to alert “MANDATE_AUTOMATICALLY_SUSPENDED”. |
| Information | - UMR - Statuses of the mandates with the same UIR |
| Template | [ALERT] The mandate with UMR : {umr} has been automaticallay suspended because the mandate with UMR : {umr} became active for UIR : {uir}. |
| Summary of the automatics notifications to the debtor | |
|---|---|
| Object | Every day, notifications are automatically sent to the debtor to inform the migration of his mandate, to remind him that he must complete and return the mandate, or to notify the change of information of his mandate. This alert notifies the creditor the number of automatic notifications which was sent for each type |
| Information | - Current date - Number of reminders sent - Number of migration notifications sent - Number of mandate change notifications sent - Number of UMR change notifications sent |
| Template | [To Do] |
| End of event report generation | |
|---|---|
| Object | This alert is sent at the end of the generation of an event report |
| Information | - Name of the report - Name of the organization - Total number of events |
| Template | [ALERT] The event report generation “{name}” for organization “{orgaName}” is finished with {totalEvents} event(s). |
| Obsolete SCT collection | |
|---|---|
| Object | An alert is sent if the status of the collection is « obsolete » because of the invalidity of the due date |
| Information | - Reference of the collection - Number of transactions in the collection - Total amount of the collection - Due date |
| Template | [ALERT] An alert based on the rule [Transaction Collection is obsolete] has been issued. The transaction collection related to this alert is: Reference: {collectionRef}/UNKNOWN Number of transactions: {collectionObjectSize}/UNKNOWN Amount: {collectionTotalAmount}/UNKNOWN Due date: {dueDate}/UNKNOWN Source: {source}/UNKNOWN |
| Mandate updated by PAIN.008 | |
|---|---|
| Object | An alert is sent when a mandate is updated by a Pain.008 |
| Information | - UMR |
| Template | [ALERT] The debtor account of the mandate {umr} has been updated after integrating a PAIN.008 message. The originating filename is : {source} |
If the value of a field was not retrieved from the application, the filed will be set to «UNKNOWN».
Alerts are viewable from the GUI; given the user has sufficient rights. Users can also subscribe to alerts by mail or text message.
To every alert class is assigned a criticality level and a color:
-
Minor (green);
-
Major (orange);
-
Critical (red).
A summary of all unacknowledged alerts is available on the Dashboard, on Home > Creditor > Dashboard > Mandates Dashboard (see Alerts).
This alert module allows the user to check all alerts sorted by type and set the notification preferences. Please note that the default alert channel is defined in the creditor entity’s parameters.
The module is available from the [Alerts Management] link in the main menu.
Viewing the Alert Classes
When accessing the Alerts Management module, the default page displayed is the “Rule List”: Home > Creditor > Alerts Management > Alerts Overview.
The page displays a summary of all existing alert classes, indicates how many alerts where received and when was the last one. A detailed view of the alerts is accessible for each class.
A first block, named “Creditor Filter” allows the user to choose a creditor entity (see Choosing a Creditor Entity, an SCI and a Business Code).
The second block, “Alerts Overview” displays as a table the existing alert classes. Are also visible the dates of the last issued alerts, the number of alerts, the name of the existing classes, the criticality level and two action buttons.
The column on the right of the table contains two action buttons. [Display Alerts] is used to see the details of a selected alert
class (see Viewing the Details of an Alert Class). The [Edit alert
rule] button links to the alerts overview page (see Subscribing to
the Alerts).
Viewing the Details of an Alert Class
The page can be accessed either from Home > Creditor > Alerts Management and by clicking on one of the [Display Alerts] action buttons (see Viewing the Alert Classes), or from Home > Creditor > Dashboard > Mandates Dashboard and by clicking on one of the [Alerts Details] buttons (see Alerts).
The page is used to sort the alerts by creditor entity. Searching by key words provides an additional search filter.
The available blocks and actions will be described in the following subsections.
Search Filters
Two blocks can be used to filter the results.
The “Creditor filter” allows the user to search within a creditor entity and an SCI (see Choosing a Creditor Entity, an SCI and a Business Code).
The “Filter” block is used to switch alert classes. It is a scroll list of all available alert classes, with the number of existing alerts within parenthesis.
Additional Search Criteria
The user can define additional criteria using a time period, a creditor’s bank account and the amount of the transaction.
Alerts List
The alerts list displays in a table the alerts that match the search criteria.
For every result, the available information is as follows:
-
Regarding the alert:
-
The alert ID;
-
The date on which the alert was sent;
-
The source of the alert;
-
The rejection justification;
-
Regarding the creditor:
-
The creditor’s SCI;
-
The creditor’s name.
-
-
Regarding the debtor:
-
The debtor’ s IBAN,
-
Its name.
-
-
The amount of the transaction.
A last column named “Action” includes two buttons, [Show details] and [Dismiss Alert].
Dismissing an Alert
The [Acknowledge Alert] deletes the selected alert. Once deleted by a user, the alert will not be displayed to the other users of the same creditor.
Viewing an Alert’s Details
The [Show details] buttons leads to the details page of the chosen alert.
The details page is made up of a single [Back to Alerts List] button and a block providing the user with the alert details.
Subscribing to the Alerts
SPS allows the user to receive alerts either by email or text message from a settings page available for each node of the creditor entity.
Even if an alert is not delivered either by email or text, it will still be visible on the GUI.
The alert subscription page is divided in several blocks:
- The selection of the creditor entity block
- Status of the email subscriptions: The block shows the alerts under its related alert group. All the alerts will be unchecked by default for the newly created root organization.
- The ‘Email Alert Group’ block shows the emails along with their respective status for the various alert groups.
The email alerts settings page is accessible from Home > Creditor > Alerts Management > Subscriptions. This page is also available from the [Edit alert rule] action button of the alert classes list.
For each creditor entity, the user can edit his subscriptions from the “Status of your email subscriptions” block. For each ticked row, an alert will be delivered. Hitting [Validate] applies the changes.
At the bottom of the block is displayed a reminder of the email account and phone number to which the alerts will be sent.
The preferred channel is defined in the organizational parameters. Alerts can be sent by text message or email.
Global alerts
Instead of sending a notification for each individual generated alert, only one global notification per alert type is to be sent. The global notification contains a summary of how many alerts were generated for that alert type, and the detail of the first 10 alerts.
If less than 10 alerts are generated for a given type, they will all be included in the global notification.
If only one alert is generated for a given type, it will be sent “as is”, without using the global alert template
For example, if a file is uploaded containing 200 transactions out of which 100 transactions are created in OBSOLETE status and another 100 transactions are created in WAITING status, then a total of two emails will be sent to the specified email addresses, containing information about the 10 first alerts (maximum number of alerts displayed in the email) instances of each alert type.
| Template of the global alerts |
|---|
| [ALERT] [NB_ALERT] alerts based on the rule [RULE] have been issued. The first operations related are: [list of the ten first alerts] (if there is only 3 operations concerned, we will have only 3 operation in the list) Source: [FILE_NAME] |