Configuring SII alarms
Transaction:
/EDGE/SII_CU_002
This transaction configures the alarms that must notify the delivery delay to the AEAT.
The risk situation on a financial document is considered alarm; Notification to the sending event about the alarm; And sending to the creation of a message in a channel.
Alarm Master
At this point the alarm types are defined, for there are three origins for which the alarm occurs:
- Status: The alarm is created when an e document reaches a certain status (retained, released, rejected with errors, accepted with errors, accepted submission).
- Expiration: The alarm is created according to the number of days elapsed to control that the shipment occurs within the period established by the AEAT.
- Scaling: This alarm is created when a previous alarm has produced a number of notifications without correcting the risk situation.
To create a new alarm, the following fields must be reported:
| Field | Meaning |
|---|---|
| Master ID alarms | It is a counter, you have to inform the number consecutive to the existing one |
| Alarm type | Description of alarm type |
| Header SapScript | The header Sapscript (previously created by the technical part) created specifically for the alarm in question |
| Body Sapscript | The body Sapscript (previously created by the technical part) created specifically for the alarm in question |
| Not. Num.Escal. | Specifies when to escalate the alarm. For example, if a 3 is indicated, after 3 notifications has been sent, the next level is scaled and the alarm master ID field is filled in and the alarm for that scaling level is indicated. |
| Due Date(Hours) | The time in hours that must elapse between one notification and another |
| Role | It indicates the role to which the notification has to arrive. In case of complex logic the determination of the person to whom the notification should be sent, the bank will be left empty and the determination will be made by code |
| ABAP Class destiny | Instead of defining the recipients of the notifications through the previous Role (which will be left empty) you can indicate here a class in which the corresponding logic has to be developed to determine those recipients. The class to indicate must be constructed as an implementation of the example class /EDGE/IF_SII_NOTIF_USER_ALARM and the logic must be developed in the GET_USERS method. |
| Scaled Alarms ID | In case of scaling, the alarm that will be generated when scaling occurs is identified |
| Active Alarm Type | This field must be marked for the alarm to be active. (It is designed so that it can be disabled in an exceptional way) |
| Grouped Notif. | If this field is flaged, all documents that meet the conditions of this type of alarm will be grouped together. For example if a batch has 1000 edoc, 1000 thousand mails would be sent, if flaged would send a mail for the whole batch |
Once the alarm master is configured, the following assignments could be made:
- Triggers by state:
At this point you specify where you want to make the alarm:
- eDoc. Process: /EDGE/SII - Sistema Información Impuestos
- Company: Company Code
- Process Step: Create batch, Accept batch, Reject batch, etc.
- Expiration Triggers
The expiration is set, to be notified periodically, or when the expiration is near.
- Alarm-channel relationships
For each alarm the channel to be used is indicated. By default the mail will be configured. Each time an alarm occurs, a notification will be sent to the users who have the role.
- Communiction chanels
At this point you must configure the mode by which the notification is to be made. The classes for the channels will be provided by the technical team.
- EDoc final states
At this point the states that are considered final are parameterized for which they will cease to issue expiration alarms and that when they are reached they will produce the shutdown of the existing alarms.
