bandejaModificaEvento

[[TOC]]

USO GENERAL

PARA LAS APLICACIONES EA

(sandra-suite-v1.0.22 PRO 16/07/2020) Se añade este uso para uso de aplicaciones EA sin tasa.

Con esta operación los distintos servicios EA pueden modificar los eventos en función de las fases por las que pasa cada servicio. Esta modificación se refleja en el evento y permite que las aplicaciones sectoriales o usuarios DELFOS puedan enterarse del cambio de fase.

Por ejemplo, el servicio de notificaciones puede modificar el evento de notificación en función de las fases por las que puede pasar una notificación:

• 11-NOTIFICACION ENVIADA
• 12a-NOTIFICACION ACEPTADA
• 20a-NOTIFICACION REHUSADA
• 21a-NOTIFICACION EXPIRADA

De la misma forma el portafirmas puede modificar el evento de firma en función de las distintas fases por las que pasa la firma:

• 03-FIRMA SOLICITADA
• 04-FIRMA REALIZADA
• 05-FIRMA RECHAZADA
• ..

Actualmente estos cambios no los hace portafirmas puesto que no ha sido posible modificar el desarrollo de la UMU. En este caso los hace SANDRA integrando el servicio advisor de portafirmas.

En los servicios implementados en la CARM, deberían ser estos los que hagan los cambios de estado de sus eventos relacionados.

En el servicio se indican los siguientes valores opcionales,

• fechaEfecto que se refiere a la fecha de efectos del evento. Por ejemplo, si la notificación se ha leído por el ciudadano el 23/03/2020 y el evento se graba el 24/03/2020, en este campo habrá que indicar el día 23/04/2020 pues es el que tiene valor para el cálculo de plazos.

  En la bandeja de eventos existirán las dos fechas. La fecha del evento y la fecha de efectos del evento.

  Si no se pasa este valor, no se actualizará la fecha de efectos del evento en la bandeja de eventos y quedará con el valor que tuviera anteriormente (que puede ser nulo)

  Sí que se actualizará la fecha de evento como corresponde cuando se realiza cualquier modificación del evento.

• Descargado, estableciéndolo a FALSE indicamos a las aplicaciones sectoriales que tiene que volver a leer el evento, debido posiblemente un cambio de fase.

  Si no se pasa este valor, no se actualiza este campo en la bandeja de eventos, que quedará con el valor que tuviera anteriormente.

• fase se indicará la nueva fase a la que pasa el evento.

Si no se pasa este valor, no se actualiza este campo en la bandeja de eventos, que quedará con el valor que tuviera anteriormente.

• estado se indicará el estado al que pasa el estado del evento. Estableciéndolo a 01-PENDIENTE DE LEER aseguramos que al usuario DELFOS vuelve a leer el evento que ha cambiado probablemente de fase.

  Si no se pasa este valor, no se actualiza este campo en la bandeja de eventos, que quedará con el valor que tuviera anteriormente.

PARA LAS APLICACIONES SECTORIALES.

Este uso para las aplicaciones sectoriales es similar al caso anterior, pero en este caso solo pueden modificar los eventos del tipo en eventos 07c-NOTIFICACION PAPEL. Las fases que pueden indicar son:

Solo se podrán indicar alguna de las siguientes fases:

• 12b-NOTIFICACION ACEPTADA MANUAL
• 20b-NOTIFICACION REHUSADA MANUAL
• 21b-NOTIFICACION EXPIRADA MANUAL
• 22-NOTIFICACION ERRONEA
• 99-PROBLEMA CON LA NOTIFICACION

(Adicionalmente al cambio de estado, la aplicación sectorial habrá dado de alta un documento de acuse de recibo en el expediente correspondiente con referencia de origen-notificaciones, referencia notificación sede- que será la que lo vincule el documento al evento)

USO CON EVENTOS DE PRESENTACIÓN QUE TENGAN TASAS ASOCIADAS

En el caso de eventos de trámites de presentación que tengan tasas asociadas, existe un tratamiento diferente que pueden utilizar tanto las aplicaciones EA como las aplicaciones SECTORIALES.

En estos casos, es el propio servicio es el que incorpora la lógica para determinar la fase, el estado y el campo descargado, en función del tipo de tasa (si requiere pago previo o no, o existen exenciones o bonificaciones).

Cada vez que una aplicación invoca a bandejaCambiaEstadoEvento o bandejaModificaEvento, para marcar como descargado o para materializar un cambio , tiene que rellenar obligatoriamente en la petición la ultimaFechaConocida del evento (la que le llegó en la última descarga del mismo) para que Sandra pueda comprobar si la aplicación tiene la última versión del evento y por tanto permita cambiar el estado (y opcionalmente la marca de descarga). En caso de que Sandra compruebe que el evento tiene un cambio posterior, devolvería un error controlado, S-305/Sincronización de evento necesaria, que indica al cliente que tiene que volver a descargar el evento porque tiene cambios más recientes.

PARA LAS APLICACIONES EA

Este uso general solo está permitido para las aplicaciones EA.

Con el servicio bandejaAltaEvento las aplicaciones PRESENTADOR y REGISTRO dan de alta los eventos de tramites presentados por el ciudadano. De esta forma las aplicaciones sectoriales se enteran de los nuevos trámites solicitados por el ciudadano leyendo los eventos de tipo 01 a 06 de la bandeja de eventos.

En el caso del PRESENTADOR, se da de alta un evento previo a la presentación definitiva, si el evento tiene tasas y se va a invocar a la pasarela de pagos.

Este evento previo es útil para permitir la recuperación del evento, en el caso de que la presentación tenga tasas asociadas, se produzcan pagos y ocurra algún error sin que la presentación se haya presentado. En este caso la frustración del ciudadano es máxima que ve como ha pagado y no ha completado su trámite.

Este evento previo, se da de alta con un estado 00-SIN EFECTO y fase=14-PENDIENTE DE PAGO. El valor Descargado=true permite que las aplicaciones sectoriales no detecten el cambio este evento que aún no ha sido presentado.

Con bandejaModificaEventos se van registrando las fases conforme se realizan los pagos, antes de la presentación.

Por ejemplo, en una presentación con varios hechos imponibles, estos se pagan en distintas llamadas a la pasarela de pagos (inicialmente el evento estará en 14-PENDIENTE DE PAGO, pasará por 15-PAGADO PARCIALMENTE y si se completan los pagos, acabara en 17-PAGADO)

En el caso de que haya fallos durante la presentación y no se complete, el ciudadano no tiene que volver pagar con los problemas que esto puede ocasionar. (ver el apartado Mecanismo de recuperación de errores de pago)

Las fases por las que puede pasar evento en función de los importes de las tasas, de los pagos realizados y la forma de justificación del pago son los siguientes:

• 14-PENDIENTE DE PAGO
• 15-PAGADO PARCIALMENTE
• 16-PAGADO SIN VERIFICAR
• 17-PAGADO
• 18-EXENTO DE PAGO
• 19-PAGO BONIFICADO

El evento en estas fases previas a la presentación puede estar en un estado 00-SIN EFECTO. La visibilidad del evento se establece con el valor Descargado=true para que las aplicaciones sectoriales no detecten estos eventos previos que aún no han sido presentado. Los usuarios DELFOS tampoco verán los eventos en estado 00-SIN EFECTO (solo a partir de 01-PENDIENTE DE LEER)

Los valores de estado, descargado y fase se establecen en función de las tasas y su pago. ver tabla.

Una vez se han completado CORRECTAMENTE todos los procesos de presentación, pago y firma, el PRESENTADOR invoca a entregaDocumentosPresentados para concluir su presentación y en función de las tasas y los pagos dejara el evento en alguna de las siguientes fases:

01-INICIADA: Presentación realizada completamente. El significado de este estado es alguno de los siguientes:

• Que el trámite no tiene tasas y se ha completado la presentación

• Que el trámite tiene tasas y dado que el procedimiento requiere su pago previo, estas han sido pagadas antes de la presentación. En el evento estarán relacionadas las tasas y sus pagos. El presentador no permite la presentación con pagos parciales en el caso de que se requiera pago previo.

• Que el trámite tiene tasas y aunque el procedimiento NO requiere su pago previo, el ciudadano ha optado por pagarlas. En el evento estarán las tasas y sus pagos.

• Que el trámite este exento de pago o el pago esté bonificado.

14-PENDIENTE DE PAGO. Presentación realizada completamente con el siguiente significado:

• Que el trámite tiene tasas, y como el procedimiento no obliga a su pago previo, el ciudadano puede optar por no pagar y descargar la carta de pago para su pago posterior (el ciudadano selecciona la forma de pago: carta de pago). En el evento estarán las tasas no pagadas.

16-PAGADO SIN VERIFICAR. Presentación realizada completamente con el siguiente significado:

• El trámite tiene una o varias tasas y el procedimiento puede requerir su pago previo o no. En este caso, el ciudadano ha presentado el/los justificante/s del pago de la tasa/s

(el ciudadano selecciona la forma de pago: Ya he pagado la tasa previamente).

• Esto puede ocurrir cuando:

  • Los ha pagado previamente en el banco con una autoliquidación manual.

  • Los ha pagado telemáticamente en una presentación telemática anterior que no ha podido concluir.

En los 3 estados anteriores, la presentación se ha completado CORRECTAMENTE y se han realizado todos los procesos de presentación, pago y firma. Al ciudadano se le ha entregado el justificante de presentación sellado por la CARM con los efectos jurídicos que eso conlleva.

En todos estos casos es posible iniciar la tramitación, con la apertura de un expediente con el servicio generaExpedienteSolicitud.

Corresponde al gestor (o a su aplicación sectorial) determinar si se requieren que los pagos estén materializados (o verificados) antes de la prestación del servicio.

Existen otros dos estados, en el que LA PRESENTACIÓN NO SE HA COMPLETADO y con los que no se puede iniciar la tramitación.

15-PAGADO PARCIALMENTE. Presentación NO REALIZADA con el siguiente significado:

• El trámite tiene varias tasas y el procedimiento requiere su pago previo, o no lo requiere pero el ciudadano ha optado por pagar. Ha realizado el pago de alguna de las tasas incluidas.

  En el momento que se paga la primera tasa, este evento será marcado con el descargado = false para que lo detecten las aplicaciones sectoriales y también con el estado 0-PENDIENTE DE LEER para los vean los usuarios de DELFOS.

  El evento puede ser visible en fase 15-PAGADO PARCIALMENTE durante unos minutos mientras se concluye el resto de los pagos. Si finalmente se completa la presentación el evento evolucionará a estado 01-INICIADO.

  Si la presentación no se concluye, por cualquier error, el evento quedara permanentemente en estado 15-PAGADO PARCIALMENTE.

  Si el formulario del trámite que se realizo tiene borrador, es posible que usuario pueda recuperar la solicitud junto con la información de los pagos realizados y completar la presentación. Ver MECANISMO DE RECUPERACIÓN DE ERRORES DE PAGO.

17-PAGADO. Presentación NO REALIZADA con el siguiente significado:

• No se ha completado la presentación, pero el trámite tiene tasas y todas han sido pagadas. En el evento estarán las tasas y los pagos que se hayan realizado.

El evento puede ser visible en fase 17-PAGADO durante unos minutos mientras se complete la presentación. Si finalmente se completa la presentación el evento evolucionará a estado 01-INICIADO.

Si la presentación no se concluye, por cualquier error, el evento quedara permanentemente en estado 17-PAGADO

Si el formulario del trámite que se realizo tiene borrador, es posible que usuario pueda recuperar la solicitud junto con la información de los pagos realizados y completar la presentación. Ver MECANISMO DE RECUPERACIÓN DE ERRORES DE PAGO.

PARA LAS APLICACIONES SECTORIALES:

Este uso general solo está permitido para las aplicaciones Sectoriales y EA.

Las aplicaciones sectoriales pueden modificar el evento posteriormente a la presentación. Puede usarse para incorporar nuevas tasas o para modificar la fase del evento.

Solo se pueden modificar eventos con las siguientes condiciones:

• cuando los eventos sean de presentación (en cualquiera de los tipos 01 a 06), y

• cuando los eventos se encuentren en alguna de las fases de pago (14 a 19) anteriormente descritas, salvo en estado 18-Exento de pago al que no se le pueden cambiar sus tasas.

Si no se cumple la primera condición da un error S-427 (Las aplicaciones sectoriales sólo pueden modificar eventos de tipo solicitud o trámite)

Si no se cumple la segunda condición da un error S-428 (Las aplicaciones sectoriales no pueden modificar eventos ya iniciados).

En las tasas a un evento exento de pago da el error S-433 (No se permite registrar tasas en un evento asociado a un documento exento de pago)

Se puede invocar el servicio de dos formas.

• Para modificar la fase, por ejemplo, para cambiar de fase 16-PAGADO SIN VERIFICAR a 01-INICIADA. En este caso no hay que especificar las tasas.

• Para cambiar las tasas existentes y sus pagos asociados. En este caso las tasas incorporadas en la llamada sustituyen completamente a las del evento. Se comprobará que el número de tasas que se pasa en la llamada sea mayor o igual que las del evento y también que el importe de las tasas de la llamada sea mayor o igual que las del evento.

Si esto no ocurre se muestra el error S-434: El número de tasas y/o la suma de los importes no pueden ser inferiores a los que ya tiene asignados el evento.

(Con esto se prevé que las aplicaciones sectoriales puedan añadir nuevas tasas e indicar las que se han pagado)

Como se ha indicado antes en este, será el servicio el que determine automáticamente la fase del evento, estado y descargado en función de las tasas, sus importes o sus justificantes.

RECUPERACIÓN DE UN PAGO REALIZADO A TRAVÉS DE LA PASARELA DE PAGOS CUANDO LA PRESENTACIÓN NO SE HA COMPLETADO

Como se ha descrito anteriormente, el PRESENTADOR crea el evento previo antes de la presentación donde incorpora los datos de las tasas y los pagos que se van produciendo.

El evento se crea antes de la invocación a la pasarela de pagos de forma que el pago de cada tasa, va actualizando el evento.

Este evento está en estado 00-SIN EFECTO y con el valor Descargado=true para que las aplicaciones sectoriales no detecten estos eventos previos que aún no han sido presentado.

Pueden ocurrir que se interrumpa el PRESENTADOR cuando se está realizando una presentación y esta:

• Tiene tasas, pero NO se ha realizado ningún pago, el evento quedará en 14-PENDIENTE DE PAGO

• Tiene tasas y se ha realizado el pago parcial de una o más tasas. El evento quedará en fase 15-PAGADO PARCIALMENTE.

• Tiene tasas y se ha realizado el pago completo, el evento quedará en fase 17-PAGADO

El evento aunque la presentación sea incompleta será visible desde DELFOS (estado pendiente de leer) y desde las aplicaciones (descargado = No)

(Otros casos que no tienen pagos no se contemplan para la recuperación del evento pues no son tan críticos para recuperar

En ese caso, si el formulario específico tiene borrador asociado, el ciudadano podrá recuperar el borrador del formulario específico y los datos del presentador que estarán asociados al evento en estado 00-SIN EFECTO.

Este mecanismo de recuperación solo es aplicable en el caso de solicitudes con pagos realizados a través de la pasarela de pagos y no presentadas. Si no tiene pagos, el ciudadano puede fácilmente volver a rellenar los datos del presentador. Si tiene pagos, no sería admisible que volviera a pagar.

El presentador crea un nuevo evento 00-SIN EFECTO en el que copia los campos del anterior evento incluidos los de las tasas y pagos realizados. Este evento será el que se utilice en la presentación.

Podrá completar la presentación y en función de los pagos realizados correctamente el evento quedará en la fase correspondiente (si los pagos se han completado o no)).

El presentador dejará al evento anterior en estado 03-ERROR DE ASIGNACION y lo pondrá en descargado=false.

(Ahora el presentador lo deja en true para evitar que siempre les aparezca a las aplicaciones sectoriales ya que no pueden modificar los errores de asignación)

El funcionamiento definitivo será que:

• El presentador dejará el evento anterior en estado estado=00-SIN EFECTO y lo pondrá en descargado=false. Para la aplicación sectorial que antes tenía este evento en un estado no presentado, (14-PENDIENTE DE PAGO, 15-PAGADO PARCIALMENTE, 17-PAGADO) detectará el cambio y de esta forma podrá saber que esta presentación se ha recuperado.

• Si no se recupera el pago, es probable que les llegue una incidencia y podrán verificar que efectivamente existe un pago de un evento no presentado (14-PENDIENTE DE PAGO, 15-PAGADO PARCIALMENTE, 17-PAGADO).

• Si el formulario especifico NO tiene borrador asociado, el ciudadano tendrá que iniciar una nueva presentación, pero podrá aportar losjustificantes de pago, en el campo “ya he pagado” del PRESENTADOR.

En esta nueva presentación se crea un nuevo evento en fase 00-SIN EFECTO que será el que se presente y evolucione a 01-INICIADA o a cualquiera de lasfases de pago pendiente.

Por ejemplo, si aporta todos los justificantes podrá completar la presentación quedando el evento en fase 16-PAGADO SIN VERIFICAR

En cualquier caso, si el usuario no ha podido descargar la justificante de pago telemático puede contactar con los gestores del procedimiento que podrán verificar otros eventos del ciudadano con en el evento 15-PAGADO PARCIALMENTE o 17-PAGADO en el que consten los pagos como realizados. Además, con el N28 de la solicitud el ciudadano puede descargarse el justificante de pago de la pasarela.