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, es necesario crear un job que ejecute el report: /EDGE/SII_EXPIRATION_ALARMS. Este report 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 creada la alarma de caducidad, la genera, (si ya existía la alarma de caducidad, pero esta estaba inactiva, el report no la activa de nuevo ya que considera que esa alarma ha sido apagada manualmente, y se entiende que no se quiere activar). Una vez generada esta alarma, si no es una alarma agrupada, automáticamente envía una notificación a los usuarios correspondientes. Si la alarma es agrupada, no envía notificación y esperará al job de envío de notificaciones para enviar su notificación correspondiente.
La fecha de expiración que se toma para calcular los días transcurridos y disparar la alarma es:
- Para facturas emitidas se toma el campo "BLDAT", fecha del documento contable.
- Para facturas recibidas se toma el campo "BUDAT", fecha de contabilización.
- Para bienes de inversión, no se da una fecha en concreto, luego no se tiene en cuanta bienes de inversión para disparar alarmas de caducidad.
- Para operaciones intracomunitarias, dependiendo del tercero, se tomará la fecha contable o la fecha de contabilización.
Esta fecha se calcula en la BAdI /EDGE/BADI_SII_EXPIRED_ALARMS que tiene una implementación por defecto donde calcula la fecha de expiración de la manera expuesta anteriormente. Si se desea cambiar este cálculo es posible crear una implementación Z.
Para esta BAdI existe una clase reserva para FICA que puede servir de ayuda para implementar las alarmas de caducidad para FICA. Esta clase es la /EDGE/CL_SII_EXP_AL_ISU.
Este tipo de alarma se dispara para todas aquellas facturas que:
- Su estado no se encuentra en la tabla de estados finales.
- El estado al que se ha llegado mediante tramitación excepcional, no está en la tabla de "Estados finales por tramitación excepcional". (Véase apartado Estados finales por tramitación excepcional de esta misma página)
- No tiene el estado ACER (Aceptado con errores).
Si una factura NO cumple alguno de estos puntos, la alarma de caducidad no se dispara.
- Disparadores por caducidad para facturas aceptadas con errores
Este tipo de alarmas se crea para distinguir la caducidad entre las facturas que han llegado al estado "Aceptado con errores" del resto de facturas en un estado no final.
La razón por la que se crea esta nueva parametrización, es debido a que según los criterios de la AEAT, las facturas que son devueltas en este estado, tienen un plazo "especial" para volver a ser enviadas. En el momento en el que una factura llega al estado aceptado con errores, el plazo para enviar la factura corregida a la AEAT, es hasta el día 15 del mes siguiente.
Este tipo de alarmas sólo se crea para facturas que están en estado ACER (Aceptado con errores).
Así pues, si se desea, se puede parametrizar este nuevo tipo de alarma. Su funcionamiento es similar al de alarmas de caducidad:
Tras crear la nueva alarma, hay que parametrizar su disparador en la tabla "Disparadores Caducidad Aceptados con errores":
El número parametrizado en días será el tiempo que debe transcurrir para disparar la alarma. Este número debe ser menor que 15, ya que si es mayor, puede ser que la notificación no llegue a tiempo al usuario correspondiente y se exceda el periodo para su corrección.
Para que se creen este tipo de alarmas, es necesario crear un job que ejecute el report: /EDGE/SII_EXP_ALARMS_ACER. Este report se encarga de comprobar los días transcurridos entre el momento en el que una factura tomó el estado "Aceptado con errores" y el número parametrizados en su disparador correspondiente. Si han transcurrido más días de los parametrizados anteriormente y este intermedio no tiene creada la alarma de caducidad para aceptados con errores, la alarma se genera, (si ya existía la alarma de caducidad, pero esta estaba inactiva, el report no la activa de nuevo ya que considera que esa alarma ha sido apagada manualmente, y se entiende que no se quiere activar). Una vez generada esta alarma, si no es una alarma agrupada, automáticamente envía una notificación a los usuarios correspondientes. Si la alarma es agrupada, no envía notificación y esperará al job de envío de notificaciones para enviar su notificación correspondiente.
La fecha de expiración que se toma para calcular los días transcurridos y disparar la alarma es la fecha de última modificación para la facura en estado aceptado con errores.
Esta fecha está calculada en la BAdI /EDGE/BADI_SII_EXPIRED_ALARMS y se puede crear una implementación en caso de querer tomar otra.
Tanto para alarmas de caducidad como alarmas de caducidad para facturas aceptadas con errores, 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:
También hay que parametrizar los canales en la tabla "Relación alarmas/canales" para que se produzcan los envíos de las notifiaciones.
Además, el usuario que ejecute este report, tanto de manera online como en fondo, debe tener asignado el objeto de autorización ZESI_ADM, objeto de autorización administrador del producto.
- 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:
- 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 si, 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.
- Alarmas de escalado
Para las alarmas de escalado, hay que indicar el número de notificaciones a las que se quiere escalar esta alarma a otra. También hay que indicar, al igual que el resto de alarmas, el plazo en horas para el envío de las notificaciones. Y por último, hay que indicar el ID de la notificación a la cual se quiere escalar una alarma una vez llegada al máximo de notificaciones enviadas (campo "ID Alarmas Escalado").
Una vez creada esta alarma, hay que parametrizar su disparador correspondiente, ya sea por estado o por caducidad. Además, hay que tener en cuenta que se debe parametrizar la tabla de "Relación alarmas/canal" para que las notificaciones puedan ser enviadas.
Para la alarma escalada, es decir, alarma a la que escala la alarma de escalado, no es necesario parametrizar un disparador, ya que esta se activa cuando la alarma de escalado envía el número de notificaciones parametriazadas.
Para que una alarma de escalado se escale hay programar un job periódico que haga ciertos chequeos y lleve a cabo este proceso de manera automática. El job a programar tiene que ejecutar el report /EDGE/SII_NEW_NOTIFICATION. Este report lo que hace es comprobar si han pasado las horas parametrizadas en el campo "Plazo en horas" y en caso afirmativo, enviar una notificación.
Además de esto, este report chequea si una alarma de escalado ha cumplido el total de sus notificaciones, y en caso positivo, una vez pasado el plazo de hora de esta alarma de escalado, escala la alarma a la que haya sido parametrizada en el campo "ID Alarmas Escalado".
En este report está establecido que cuando se genere una alarma de escalado, se envíe automáticamente una notificación para avisar de que la alarma se ha escalado.
Como se ha dicho anteiormente, este report es el encargado de enviar las notificaciones. Estas, se pueden enviar manualmente desde el monitor de alarmas: 3.3.1. Alarmas b+ SII - Módulo antiguo.
Pero por comodidad se ha creado este report, /EDGE/SII_NEW_NOTIFICATION, que al ejecutarse envía notificaciones a todas aquellas alarmas que estén activas según el plazo de horas establecido.