Transacción:
/EDGE/SII_CU_002
Mediante esta transacción se configuran las alarmas que deben notificar el retraso de envío a la AEAT.
Se considera alarma a la situación de riesgo sobre un documento financiero; notificación al evento de envío sobre la alarma; y envío a la creación de un mensaje en un canal.
Maestro de alarmas
En este punto se definen los tipos de alarma, para ello existen tres orígenes por los cuales se produce la alarma:
- Estado: Se crea la alarma cuando un eDocument alcanza un estado determinado(retenido, liberado, rechazado con errores, aceptado con errores, envío aceptado).
- Caducidad: Se crea la alarma en función del número de días transcurrido para controlar que el envío se produzca en el plazo establecido por la AEAT. Esta alarma sólo afecta a eDocuments intermedios (facturas).
- Escalado: Se crea esta alarma cuando una alarma anterior ha producido un número de notificaciones sin que se corrija la situación de riesgo.
Para crear una nueva alarma, se tienen que informar los siguientes campos:
| Campo | Significado |
|---|---|
| ID Maestro Alarmas | Es un contador, se tiene que informar el número consecutivo al existente |
| Tipo de Alarma | Descripción del tipo de alarma |
| Sapscript cabecera | Se selecciona el Sapscript de cabecera (creado previamente por la parte técnica) creado específicamente para la alarma en cuestión |
| Sapscript de cuerpo | Se selecciona el Sapscript de cuerpo (creado previamente por la parte técnica) creado específicamente para la alarma en cuestión |
| Nº Notif Escalado | Se especifica cuando se debe escalar la alarma. Por ejemplo si se indica un 3 significa que después del envío de 3 notificaciones se escale al siguiente nivel, para lo que se rellena el campo ID maestro Alarma y se indica la alarma para ese nivel de escalado. |
| Plazo en horas | El tiempo en horas que debe transcurrir entre una notificación y la siguiente. |
| Rol | Se indica el rol al cual tiene que llegar la notificación. En caso de tener lógica compleja la determinación de la persona a la que se debe enviar la notificación, se dejará el banco vacío y la determinación se hará mediante código |
| Clase ABAP dest. | En vez de definir los destinatarios de las notificaciones a través del Rol anterior (que se dejará vacío) se puede indicar aquí una clase en la que hay que desarrollar la lógica correspondiente para determinar dichos destinatarios. La clase a indicar se debe construir como una implementación de la clase ejemplo /EDGE/IF_SII_NOTIF_USER_ALARM y se debe desarrollar la lógica en el método GET_USERS. |
| ID Maestro Alarmas de escalado | En caso de haber escalado se identifica la alarma que se generará cuando se produzca el escalado |
| Tipo Alarma Activo | se debe marcar este campo para que la alarma esté activa. (Está pensado para que de manera excepcional se pueda desactivar) |
| Notif Agrupadas | Si se marca este campo se agruparán todos los documentos que cumplan las condiciones de este tipo de alarma. Por ejemplo si un lote tienen 1000 edoc, se enviarían 1000 mil mails, si se marca el check se enviaría un mail para todo el lote |
Una vez configurada el maestro de alarma, se podrían establecer las siguientes asignaciones:
- Disparadores por estado:
En este punto se especifica donde se quiere realizar la alarma:
- Proceso eDoc.: /EDGE/SII - Sistema Información Impuestos
- Sociedad: Id de la sociedad
- Paso del proceso: Crear Lote, Aceptar Lote, Rechazar Lote, etc.
- Disparadores por caducidad
Se configura la caducidad, para que se notifique con una periodicidad, o cuando esté próximo el vencimiento.
Para que se creen este tipo de alarmas de caducidad es necesario crear un job que ejecute el report: /EDGE/SII_EXPIRATION_ALARMS que es el que se encarga de comprobar los días transcurridos entre el momento en el que un intermedio tomó un estado "de alarma" (esto quiere decir que no esté en estado Aceptado, Aceptado con errores y Confimado) y los días parametrizados en la tabla mostrada en la imagen superior. Si han transcurrido más días de los parametrizados anteriormente y este intermedio no tiene activa la alarma de caducidad, genera o activa la nueva alarma de caducidad para el intermedio. Una vez generada esta alarma automáticamente envía una notificación a los usuarios correspondientes.
Para alarmas de caducidad es necesario parametrizar la tabla /EDGE/SII_PAR_MP con el calendario que se desee. El estándar con días festivos nacionales de España utilizado en producto es:
- Relación alarmas-canal
Para cada alarma se indica el canal que se va a utilizar. Por defecto va a estar configurado el mail. Cada vez que se produzca una alarma se va a enviar una notificación a los usuarios que tengan el rol.
- Canales de comunicación
En este punto se debe configurar el modo por el que se va a realizar la notificación. Las clases para los canales los proporcionará el equipo técnico.
- Estados finales de comunicación
En este punto se parametrizan los estados que se consideran finales para los que se dejará de emitir alarmas de caducidad y que cuando se llegue a ellos producirán el apagado de las alarmas existentes.
Cuando se parametrice una entrada /EDGE/SII con su paso de proceso correspondiente, en el momento en el que un eDocument intermedio (factura) llegue a este estado, sus alarmas se desactivarán. Lo mismo sucederá para los lotes cuando se parametrice en esta tabla una entrada /EDGE/SIIL, cuando un lote llegue al estado parametrizado su alarma se desactivará.
- Estados finales por tramitación excepcional
Cuando un eDocument intermedio ha sido tratado mediante la opción "Tramitación Excepcional", la tabla anterior "Estados Finales" no funciona correctamente debido a que el campo parametrizado no es el estado en sí, sino el paso de proceso. Cuando un eDocument es tramitado excepcionalmente, el paso de proceso es TRATO_EXCE, mientras que el estado final será el elegido en esta tramitación. Como en la tabla anterior no se puede parametrizar este paso de proceso, ya que apagaría alarmas para eDocuments en todos los estados tramitados de esta manera, se ha creado una tabla nueva: "Estados finales por tramitación excepcional",
En esta tabla se parametrizan los estados que consideramos finales para facturas que han sido tratadas mediante tramitación excepcional. Desde producto se parametriza esta tabla de manera estándar con los estados:
- ACCE: Aceptado.
- ACOB: Aceptado→Obsoleto.
- CONF: Confirmado.
- NALI: No Alineado.
- OBSO: Obsoleto.
Sin embargo, es posible cambiar estos estados indicando los estados que se deseen. Los estados a parametrizar pueden ser los siguientes:
| Estado | Descripción |
|---|---|
| ACCE | Aceptado |
| ACER | Aceptado con Errores |
| ACOB | Aceptado->Obsoleto |
| CONF | Confirmado |
| CORR | Corregido |
| CREA | A incluir en lote |
| HOLD | Retenido |
| INCL | Incluido en Lote |
| NALI | No alineado |
| OBSO | Obsoleto |
| REJE | Rechazado |
De esta manera, cuando una factura haya sido fijada en un estado que esté en esta tabla mediante tramitación excepcional, el report que se encarga de apagar las alarmas tendrá en cuenta estos estados finales para desactivar las que correspondan.
A parte de esta parametrización de alarmas es necesario configurar un job para que se envíen las notificaciones de manera automática. Las notificaciones se pueden enviar manualmente desde el monitor de alarmas: 3.3. Monitor de alarmas SII.
Pero por comodidad se ha creado el report /EDGE/SII_NEW_NOTIFICATION que al ejecutarse envía notificaciones a todas aquellas alarmas que estén activas. Para ello es necesario crear un job que ejecute este report periódicamente y así notificar de la situación a los usuarios de manera regular.