Alarms Configuration SII

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:

1. Status: The alarm is created when an e document reaches a certain status (retained, released, rejected with errors, accepted with errors, accepted submission).
2. 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.
3. 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:

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.

To create this type of alarms, it is necessary to create a job that executes the report: / EDGE / SII_EXPIRATION_ALARMS. This report is responsible for checking the days elapsed between the time when an intermediate took an "alarm" status, (this means that it is not in the Accepted, Accepted with errors and Confident status) and the days customized in the table shown in the upper image.

If more days have elapsed than those previously configured and this intermediate has not created the expiration alarm, generates it, (if the expiration alarm already existed, but it was inactive, the report does not activate it again since it considers that alarm it has been turned off manually, and it is understood that you do not want to activate). Once this alarm is generated, if it is not a grouped alarm, it automatically sends a notification to the corresponding users.

If the alarm is grouped, it does not send notification and will wait for the notification sending job to send its corresponding notification.

The expiration date that is taken to calculate the elapsed days and trigger the alarm is:

• For issued invoices, take the "BLDAT" field, date of the accounting document.
• For received invoices, take the "BUDAT" field, posting date.
• For investment goods, a specific date is not given, then there is not enough investment property to trigger expiration alarms.
• For intra-community transactions, depending on the third party, the accounting date or the posting date will be taken.

This date is calculated in the BAdI / EDGE / BADI_SII_EXPIRED_ALARMS, which has a default implementation where it calculates the expiration date in the manner described above. If you want to change this calculation it is possible to create a Z implementation.

This type of alarm is triggered for all those invoices that:

• Its status is not found in the final state table.
• The state that has been reached through exceptional processing, is not in the table of "Final States for exceptional processing". (See section  final states for the exceptional tram on this page)
• It does not have the status ACER (Accepted with errors).    

If an invoice is about these points, the expiration alarm does not tigger. 

• Expiration triggers for accepted invoices with errors

This type of alarm is created to distinguish the expiration between the invoices that have reached the "Accepted with errors" status of the rest of the invoices in a non-final state.The reason why this new customization is created due to the fact that according to the criteria of the AEAT, the invoices that are returned in this state, have a "special" term to be sent again. At the moment in which an invoice arrives at the accepted state with errors, the deadline to send the corrected invoice to the AEAT, is until the 15th day of the following month. This type of alarms is only created for invoices that are in ACER status (Accepted with errors).So, if desired, this new type of alarm can be customized. Its operation is similar to that of expiry alarms. 

After creating the new alarm, it is necessary to customize its trigger in the table "Triggers Expiration Accepted with errors":

The number customized in days will be the time that must elapse to trigger the alarm. This number must be less than 15, because if it is greater, the notification may not arrive in time to the corresponding user and the period for correction will be exceeded.

To create these types of alarms, it is necessary to create a job that executes the report: / EDGE / SII_EXP_ALARMS_ACER. This report is responsible for checking the days elapsed between the moment an invoice took the status "Accepted with errors" and the number customized in its corresponding trigger. If more days have elapsed than those previously configured and this intermediate has not created the expiration alarm for accepted with errors, the alarm is generated, (if the expiration alarm already existed, but it was inactive, the report does not activate it again, it considers that this alarm has been turned off manually, and it is understood that it does not want to activate).

Once this alarm is generated, if it is not a grouped alarm, it automatically sends a notification to the corresponding users. If the alarm is grouped, it does not send notification and will wait for the notification sending job to send its corresponding notification. The expiration date that is taken to calculate the elapsed days and trigger the alarm is the date of last modification for the invoice with accepted state with errors. This date is calculated in the BAdI / EDGE / BADI_SII_EXPIRED_ALARMS and you can create an implementation if you want to take another one.

Both for expiration alarms and expiration alarms for invoices accepted with errors, it is necessary to customize the table / EDGE / SII_PAR_MP with the desired calendar. The standard with national holidays of Spain used in product is:

It is also necessary to customize the channels in the "Alarms / channels list" table so that the notifications can be sent. In addition, the user who executes this report, both online and in the background, must have the authorization object ZESI_ADM assigned, object of authorization for the product administrator.

• 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 customized for which they will cease to issue expiration alarms and that when they are reached they will produce the shutdown of the existing alarms.

When an input / EDGE / SII is customized with its corresponding process step, at the moment in which an intermediate eDocument (invoice) reaches this state, its alarms will be deactivated. The same will happen for batches when an input / EDGE / SIIL is customized in this table, when a batch reaches the customized state its alarm will be deactivated.

States:

• Final states for exceptional processing

When an intermediate eDocument has been treated by the option "Exceptional Processing", the previous table "Final States" does not work correctly because the customized field is not the status itself, but the process step. When an eDocument is processed exceptionally, the process step is TRATO_EXCE, while the final state will be chosen in this procedure. As in the previous table, this process step can not be pcustomized, since it would turn off alarms for eDocuments in all the states processed in this way, a new table has been created: "Final states by exceptional processing",

In this table the states that we consider final are customized for invoices that have been treated by exceptional processing. From the product this table is customized in a standard way with the states.

• ACCE: Accepted
• ACOB: Accepted→Obsolete.
• CONF: Confirmed
• NALI: Not aligned
• OBSO: Obsolete

However, it is possible to change these states by indicating the desired states. The states to be customized can be the following:

In this way, when an invoice has been set in a state that is in this table by exceptional processing, the report that is responsible for turning off the alarms will take into account these final states to deactivate those that correspond.

• Scaled Alarms

For scaled alarms, you must indicate the number of notifications to which you want to scale this alarm to another. It is also necessary to indicate, like the rest of the alarms, the deadline in hours for sending the notifications. And finally, you must indicate the ID of the notification to which you want to scale an alarm once you have reached the maximum number of notifications sent (field "Scaled alarms ID"). 

Once this alarm has been created, it is necessary to customize its corresponding trigger, either by status or by expiration. In addition, it must be taken into account that the "Alarm / channel list" table must be customized so that notifications can be sent. For the scaled alarm, the alarm which the scaled alarm scales, it is not necessary to customize a trigger, since this is activated when the scaled alarm sends the number of customized notifications. To get a scaled alarm can be scaled, there is a scheduled periodic job that performs certain checks and carries out this process automatically. The job to be programmed has to execute the report / EDGE / SII_NEW_NOTIFICATION.  This report checks if they have passed the customized hours in the field "Term in hours" and if so, send a notification. 

In addition, this report checks if an scaled alarm has fulfilled the total of its notifications, and if positive, once the time limit of this scaled alarm has elapsed, it scales the alarm to which it has been customized in the field "ID Alarms Scaled". In this report it is established that when a scaled alarm is generated, a notification is automatically sent to warn that the alarm has escalated.

As stated above, this report is responsible for sending notifications. These can be sent manually from the alarm monitor: 3.1.3.3. SII alert morning

But for convenience this report has been created, / EDGE / SII_NEW_NOTIFICATION, which when it is executed, it sends notifications to all those alarms that are active according to the established time period.