2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el...

66

Transcript of 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el...

Page 1: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.
Page 2: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

1. Introductioni. Control de cambios

2. Estado del sistemai. Uso del Sistemaii. Componentes Externosiii. Geolocalización

3. Configuracióni. Call-backii. Envío de emailsiii. Errores del sistemaiv. Generalv. Geolocalizaciónvi. Informe de transferenciavii. Notificaciones

4. Buscadori. Detalle de un mensaje

i. Detalle de una firmaii. Verificación de firma biométrica

5. Auditoría6. Transferencias7. Aplicaciones8. Grupos9. Gestión de Usuarios

i. Roles10. Plantillas

i. Dispositivosii. Estilos página de firmaiii. Informes

Tabla de contenido

2

Page 3: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Accesible a usuarios con roles de Administración, el panel de control está compuesto por los siguientes apartados:

Estado del sistemaConfiguraciónBuscadorAuditoríaTransferenciasAplicacionesGruposGestión de UsuariosRolesPlantillasDispositivosEstilos página de firmaInformes

Panel de control de Viafirma Documents

3Introduction

Page 4: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Esta documentación técnica está sujeta a modificaciones diarias, y alguna información o configuración avanzada podríano estar reflejada. Consulte en cualquier caso con el equipo de soporte técnico.

Revisión Fecha

Actualización 11-julio-2016

Servicios Versión

Backend 3.2.7

App iOS 3.2.2

App Android 3.2.1

DB Documents (backend) 0.0.63

Biometric signature verifier 1.4.1

Fecha Cambio

17-mar-16 Versión inicial del manual de administrador

11-jul-16 4.3.1.2 Verificación de firma biométrica.

Control de cambios

Últimas versiones liberadas

Últimos cambios

4Controldecambios

Page 5: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

La pantalla de estado del sistema está compuesta por los siguientes apartados:

1. Uso del Sistema2. Componentes Externos3. Geolocalización

Estado del sistema

5Estadodelsistema

Page 6: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Pantalla de estadísticas del uso del sistema.

Uso del Sistema

6UsodelSistema

Page 7: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Estado de las conexiones externas de viafirma documents

Las comprobaciones de las conexiones se realizan periodicamente. Si se desea realizar en el momento actual se debepulsar Actualizar ahora.

Componentes Externos

7ComponentesExternos

Page 8: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Cuando el mensaje llega al backend, se procesa toda la metadata asociada a la geolocalización del dispositivo que seusó para la firma.

¿Cómo se presenta esta información?

se hace uso de las APIs de Google Mapssólo se visualizarán documentos cuyo dispositivo haya autorizado el uso del GPS.las búsquedas se permiten para un mismo día y se mostrarán hasta un máximo de 5.000 localizaciones.

Geolocalización

Geolocalización de documentos firmados

8Geolocalización

Page 9: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

el nivel de agrupamiento variará en función del zoom aplicado al mapa, representando por círculos de distintoscolores en función del número de documentos localizados en una misma región, hasta finalmente mostrareldocumento firmado, representado por un marcador rojo.

9Geolocalización

Page 10: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

A = nivel de agrupación basado en una regiónB = nivel de agrupación basado en una zona cercanaC = localización exacta de la firma de un documento

10Geolocalización

Page 11: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Pantalla de configuración de viafirma documents.

Está compuesta por los siguientes apartados:

Call-backEnvío de emailsErrores del sistemaGeneralGeolocalizaciónInforme de transferenciaNotificaciones

Configuración del sistema

11Configuración

Page 12: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

En las respuestas dadas desde el backend hacia las aplicaciones de terceros que invocan los servicios de viafirmadocuments se permite además enviar un correo electrónico para cada respuesta.

Para ello, en el objeto MESSAGE debemos incluir la propiedad callbackMails.

Una vez configurada la callback vía correo electrónico, desde el backend se podrá configurar el comportamiento de eseenvío de correo, tal y como se describe a continuación:

Asunto del email de callback: asunto con el que se remitirá el correo al integrador en cada callback.

Mostrar valores del formulario en el correo electrónico de callback: incluirá en el correo remitido al integrador los valoresinformados en el formulario que dio origen al PDF firmado. Esta opción es útil para revisar en un simple vistazo elcontenido de documentos tipo encuestas de satisfacción o similares, cuyo contenido no es muy extenso y ofreceinformación sin necesidad de procesar.

Se permite además incluir más de un destinatario de correo, separados por coma (,).

Además, en el caso de que existan valores sensibles en el formularios, éstos podrán ser omitidos en el correo

Call-back

Configuración call-back

12Call-back

Page 13: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar.El resto, no se mandarían.

Para este filtrado de datos usaremos la propiedad callbackMailsFormKeys disponible en el objeto MESSAGE.

Message{

callbackMailsFormKeys(array[string],optional),

}

Disclaimer del correo electrónico de callback: permitirá personalizar el pie del correo remitido al integrador tras cadacallback.

Adjuntar PDF/XML en el correo: activando estas opciones, el correo remitido al integrador adjuntará el PDF firmado y elXML del message procesado.

Asunto del correo electrónico de callback de rechazo: asunto con el que se remitirá el correo al integrador para callbackde rechazo.

Contenido del correo electrónico de callback de rechazo (*): contenido con el que se remitirá el correo al integradorpara callback de rechazo.

13Call-back

Page 14: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

La aplicación realiza envíos de emails a los usuarios en varios supuestos.

El contenido de estos emails es configurable desde esta pestaña de la configuración.

Envío de emails

14Envíodeemails

Page 15: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Destinatario del correo electrónicoAsunto del correo electrónicoContenido del correo electrónicoContenido del correo electrónico enviado tras rechazar la reactivación de cuentaAsunto del correo electrónico de denegación de reactivación de usuarios inactivosAsunto del correo electrónico de reactivación usuarios inactivosContenido del correo electrónico de usuario reactivados

Duración en horas de los tokens de activación de la cuenta y de reseteo de la contraseñaAsunto del correo electrónico de confirmación de cuenta de usuarioContenido del correo electrónico de confirmación de cuenta de usuario

Asunto del correo electrónico de modificación de contraseñaContenido del correo electrónico de modificación de contraseña

Activación de usuarios

Confirmación de cuenta de usuario

Modificación de contraseña

15Envíodeemails

Page 16: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

La aplicación realiza envíos de emails cuando se producen errores en el sistema. Para ello es necesario configurar lassiguientes propiedades:

Destinatarios del correo electrónico de error del sistemaAsunto del correo electrónico de error del sistema

Errores del sistema

16Erroresdelsistema

Page 17: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Configuraciones generales de la aplicación:

Periodo de caducidad de usuarios por inactividad (en días)Número máximo de elementos permitidos en las colas hazelcast (cuando supere el máximo será notificado paraactuacion)Código de la clave para la API públicaCódigo de la clave para la API privadaCódigo de la clave especial para la API

General

17General

Page 18: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

La geolocalización hace uso de la API de google, para el correcto funcionamiento es necesario configurarlapreviamente.

Los datos a configurar son:

API de Google MapsAPI Key de Google MapsLatitud del punto de inicio del mapaLongitud del punto de inicio del mapaNúmero máximo de coordenadas mostradas en el mapa

Geolocalización

18Geolocalización

Page 19: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

En esta pantalla se configuran los correos electrónicos del informe de transferencia. Las propiedades a configurar son:

Destinatarios del correo electrónico de transferencia de documentosAsunto del correo electrónico de transferencia de documentosContenido del correo electrónico de transferencia de documentos

Informe de transferencia

19Informedetransferencia

Page 20: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Desde esta pantalla se configura el número máximo de notificaciones en caso de error de un sistema externo.

Notificaciones

20Notificaciones

Page 21: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Los usuarios administradores desde la opción Buscador tendrán la posibilidad de acceder al listado completo de losmensajes de la aplicación.

Por defecto se mostrará el listado completo de mensajes ordenados por fecha, mostrandose los más recientes primero.

Existe la posibilidad de filtrar el listado de mensajes disponibles. Los filtros disponibles son:

Aplicación de destinoAplicación solicitanteCódigo de firmaCódigo de grupoCódigo de mensajeCódigo de plantillaCódigo del dispositivoCódigo del usuario destinatarioCódigo del usuario remitenteDescripción de mensaje

Buscador

21Buscador

Page 22: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Estado de transferenciaEstado del mensajeFecha de actualizaciónFecha de creaciónResultado de transferenciaTítulo del mensaje

Las acciones que se pueden realizar sobre cada mensaje son:

Acceder al detalle de un mensaje.

Rechazar un mensaje y crear nueva copia. Sólo disponible en mensajes con estado WAITING.

Rechazar un mensaje. Sólo disponible en mensajes con estado WAITING.

22Buscador

Page 23: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Al pulsar el enlace en el listado de mensajes del buscador accederemos al detalle del mismo.

Detalle de un mensaje

23Detalledeunmensaje

Page 24: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

24Detalledeunmensaje

Page 25: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

En esta pantalla podremos realizar las siguientes acciones:

Descargar el JSON del mensaje.

Descargar el XML del mensaje.

Descargar el pdf firmado del mensaje. Solo disponible para mensajes que hayan sido firmados.Acceder al detalle de la firma. Al pulsar sobre código de firma de un mensaje se accederá al detalle de la firma.Solo disponible para mensajes que hayan sido firmados.

25Detalledeunmensaje

Page 26: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Al pulsar en el código de firma del detalle de un mensaje accederemos a la pantalla de detalle de la firma en cuestión.

Detalle de una firma

26Detalledeunafirma

Page 27: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

27Detalledeunafirma

Page 28: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Los datos biométricos de las firmas realizadas se recogen acorde a la ISO/IEC 19794-7:2014 (Formato de los datospara sistemas biométricos basados en la firma manuscrita). Estos datos se encuentran cifrados con la clave pública deun tercero de confianza.

Los datos biométricos podrán ser descifrados haciendo uso de viafirma documents o de forma externa.

Para descrifrar los datos biométricos usando viafirma documents es necesario disponer del fichero .p12 con la claveprivada del tercero de confianza y la contraseña del mismo.

Para acceder a la pantalla de descifrado de los datos biométricos de una evidencia se debe pulsar el enlace Descifrar situado en el apartado de Datos cifrados de la evidencia.

Una vez pulsado el enlace se mostrará la pantalla de descrifrado de datos biométricos.

Para obtener los datos biométricos cifrados se debe seleccionar el certificado con la clave privada del tercero deconfianza empleado en la encriptación de los datos, la contraseña del certificado y pulsamos Descifrar.

Si los datos son correctos se descargará un JSON con los datos biométricos de la evidencia.

Puede descargar un ejemplo de JSON aquí

Para descrifrar los datos biométricos es necesario realizar los siguientes pasos.

¿Cómo se descifran los datos biométricos de una firma?

Descrifrar datos biométricos usando viafirma documents

Descrifrar datos biométricos de forma externa

28Detalledeunafirma

Page 29: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

1. Descargar el pdf firmado.2. Por cada firma realizada en el documento se le adjunta al pdf un xml con los datos de la firma cifrados. El acceso

al contenido de este xml dependerá del software utilizado para la visualización del pdf. Así, por ejemplo, en Acrobat

Reader DC para acceder al xml debe realizarse doble click en el icono de la firma cuyos datos biométricosqueremos descifrar.

Dentro de este xml los datos a tener en cuenta son:

data: Datos biométricos cifradoscipherAlgorithm: Algoritmo empleado para el cifrado de los datos biométricos.encryptedAesSessionKey: Cifrado de la clave de 128 bits (sessionKey en el futuro) que ha sido empleada parael cifrado de los datos biométricos.trustedThirdParty: Clave pública del tercero de confianza que ha sido empleada para cifrar el sessionKey.

3. Descrifrar el sessionKey. Para ello se debe descifrar encryptedAesSessionKey usando la clave privada del tercerode confianza cuya clave pública es trustedThirdParty. Para ello se utiliza el algoritmo RSA/None/PKCS1Padding.

4. Descrifrar los datos biométricos. Para ello se debe descifrar data usando como clave de cifrado el sessionKeyobtenido en el punto anterior utilizando el algoritmo definido en cipherAlgorithm.

Una vez finalizado el proceso obtendremos un xml con los datos biómetricos.

Puede descargar un ejemplo de xml aquí

En el siguiente enlace puedes descargar la aplicación de viafirma para la comprobación de firmas biométricas según elISO 19794-7:2014 biometric signature verifier v1.3.0

Uso de la aplicación de verificación de firmas biométricas

29Detalledeunafirma

Page 30: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

En el siguiente link te contamos cómo se usa la herramienta de verificación de firmas

Verificación de firmas biométricas con viafirma documents

Verificación de firma biométrica

30Verificacióndefirmabiométrica

Page 31: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

La auditoría de mensajes ofrece una vista histórica de todas las operaciones realizadas, y cuenta con las siguientescaracterísticas.

Histórico permanente

A diferencia de la gestión de mensajes, la información auditada no es borrada por el backend, como sí lo hace con losmensajes. Este borrado se configura en el ciclo de vida de los mensajes, ver capítulo Administración > Aplicaciones.

Respaldo en disco

Las referencias auditadas quedan respaldadas opcionalmente por ficheros XMLs, persistidos éstos en un sistema deficheros.

El path de persistencia del XML es definido en la configuración del sistema, en la variable AUDITORY_PATH. Si estefichero XML fuese borrado del filesystem, la inforación seguiría estando disponible en esta vista de auditoría. Lo únicoque no estaría disponible sería el fichero XML que reúne toda el detalle de la operación.

El path de persistencia del XML se definirá de la siguiente forma:

AUDITORY_PATH+YYYMMDD+CODMESSAGE+.xml

Auditoría

31Auditoría

Page 32: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Por ejemplo:

/home/cluster/custodia/auditory/20150810/1439216343810R278.xml

Existe la posibilidad de filtrar el listado de auditoría disponibles. Para ello introducimos el texto por el que se desee filtaren el cuadro de búsqueda y se pulsar Buscar . Para eliminar el filtro de búsqueda y volver a mostrar el listado completode auditoría pulsamos Mostrar todos .

32Auditoría

Page 33: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

En caso de haber configurado un sistema externo para la persistencia de documentos, esta vista mostrará el detalle delas transferencias realizadas.

Para cada caso, se indicará:

fecha y hora de la transferenciamensaje asociado a la transferenciasistema externo configurado (ej. computec, ftp, etc.)estado de la transferencia (pendiente, asignada, finalizada o error)número de intentos en caso de fallo en la primera transferenciala respuesta del sistema externo tras la transferencia, por ej. 200 (si es un servicio REST), y el número asignadopor el sistema externo en la petición.

El número de intentos de los documentos a transferir se define en las propiedad del sistemaexternal_signed.MAX_RETRY_COUNT. Para más info consulta la Configuración del Sistema.

En caso de error, en esta vista se podrá acceder al detalle del error para que pueda ser analizado y escalado segúnproceda.

Existe la posibilidad de filtrar el listado de transferencias disponibles. Para ello introducimos el texto por el que se deseefiltar en el cuadro de búsqueda y se pulsar Buscar . Para eliminar el filtro de búsqueda y volver a mostrar el listadocompleto de transferencias pulsamos Mostrar todos .

Sistema de Transferencias

33Transferencias

Page 34: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

34Transferencias

Page 35: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Esta administración de aplicaciones permitirá definir las reglas de comunicación entre el backend y los usuarios quehagan uso, bien de aplicaciones móviles, o bien de aplicaciones servidor que estén integradas con viafirma documents.

Nos permitirá autorizar el uso a estas aplicaciones, y nos permitirá identificar el origen y destino de los documentosprocesados.

Se tendrán en cuenta tres tipos de aplicaciones:

iOSAndroidAPI

Las aplicaciones iOS y Android se refieren a las apps oficiales de viafirma documents. Cada una cuenta con su propiaconfiguración, nombre, y securización.

El tercer tipo de apliaciones, API, se refiere a aquellas aplicaciones que integren con los servicios de viafirmadocuments, por ejemplo, un CRM, que al igual que para el caso de iOS y Android, podrá tener su propia configuración ysecurización.

Aplicaciones

Tipo de Aplicaciones

35Aplicaciones

Page 36: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

A continuación se describe cómo gestionar las aplicaciones en el backend.

Listado de mensajes en estado borrador para el usuario autenticado.

Existe la posibilidad de filtrar el listado de aplicaciones disponibles. Para ello introducimos el texto por el que se deseefiltar en el cuadro de búsqueda y se pulsar Buscar . Para eliminar el filtro de búsqueda y volver a mostrar el listadocompleto de aplicaciones pulsamos Mostrar todos .

Las acciones que un administrador puede llevar a cabo en esta pantalla son:

Añadir una nueva aplicación pulsado el botón Añadir.Editar una aplicación pulsando en el lápiz de la fila correspondiente al mensaje.Eliminar una aplicación pulsando la cruz roja de la fila correspondiente al mensaje.

Se tendrán en cuenta tres tipos de aplicaciones:

Listado de aplicaciones

Detalle de aplicaciones

Tipo de Aplicaciones

36Aplicaciones

Page 37: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

iOSAndroidAPI

Las aplicaciones iOS y Android se refieren a las apps oficiales de viafirma documents. Cada una cuenta con su propiaconfiguración, nombre, y securización.

El tercer tipo de apliaciones, API, se refiere a aquellas aplicaciones que integren con los servicios de viafirmadocuments, por ejemplo, un CRM, que al igual que para el caso de iOS y Android, podrá tener su propia configuración ysecurización.

A continuación se describe cómo gestionar las aplicaciones en el backend.

Datos Generales

37Aplicaciones

Page 38: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Entre los datos generales a la hora configurar una aplicación, empezaremos a describir los datos bloqueantes yfuncionales:

Tipo de aplicación (plataforma)Tipo de autenticación

Como ya se ha explicado, nuestra aplicación deberá crearse como una de las tres opciones permitidas: iOS, Android yAPI.

El tipo de autenticación se explica de forma detallada más abajo, en la sección "seguridad".

38Aplicaciones

Page 39: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Y por otro lado, tenemos la siguiente configuración opcional:

TítuloVersiónFecha de creaciónFecha de actualizaciónTexto que se mostrará al ofrecer la actualización de la aplicación * Ofrecer actualización de la app en losdispositivos que ya tienen instalada la aplicaciónURL icono de aplicación (actualmente no es funcional)URL de instalación de la app (sólo a título informativo, no se realiza ningún tipo de validación sobre esta URL).JSON de configuración externa

Esta opción sólo está disponible para aplicaciones del tipo iOS y Android, y permite inyectar configuración distinta a laconfiguración con la que fue compilada la versión.

Es importante aclarar que la configuración "inyectable" sólo afecta a aquellas funcionalidades que en origen(compilación original) se hayan marcado como "editables".

¿Para qué necesito inyectar configuración externa?

Esta opción es útil para ambientes de desarrollo o preproducción, en los que se pueden probar aplicacionesinicialmente compiladas para un ambiente de producción, y que podremos cambiar configuraciones como por ejemploel endpoint del backend.

También podrá ser últil para cambiar datos de credenciales de servicios externos, como por ejemplo, el servicio demensajería SENDGRID. Si la cuenta de este servicio (user/pass) cambiara, sólo habría que hacer el cambio en elbackend, en el fichero de configuración, y de forma automática, todas las apps distribuidas aplicarían el cambio en elsiguiente inicio de sesión.

¿Qué tipo de configuración puedo editar desde aquí?

propiedad descripción

frontCamera true para permitir el uso de la cámara frontal en la captura de evidencias del tipo foto, yfalse para deshabilitarla.

personMask true o false; se usa para activar o desactivar la validación de "personas" cuando secaptura una evidencia del tipo foto.

autoRegisterDevicetrue o false; indica si se enlazan de forma automática los dispositivos al usuario. Deforma que un usuario sólo podrá tener asociado un dispositivo. En caso de logarse enotro dispositivo se desasocia del anterior

finalizeActions Acciones que el usuario puede realizar en la pantalla de resultado

JSON de ejemplo

{

JSON de configuración externa

39Aplicaciones

Page 40: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

"frontCamera":true,

"personMask":true,

"autoRegisterDevice":true,

"finalizeActions":[

{

"type":"MAIL"

},

{

"type":"VIEW"

},

{

"type":"DETAIL"

},

{

"type":"SHARE"

},

{

"type":"PRINT"

}

]

}

La comunicación entre las aplicaciones y el backend se realiza mediante servicios REST, securizados con OAuth.

Cada aplicación tendrá sus propias credenciales, esto es, consumer-key y consumer-secret, cuya equivalencia en laconfiguración de la aplicación sería la siguiente:

plataforma consumer-key consumer-secret

iOS com.viafirma.mobile.ios.documents [9999999999]

Android com.viafirma.viafirmaDocuments.Documents [9999999999]

Swagger com.viafirma.mobile.services [9999999999]

Otra... com.viafirma.mobile.crm [9999999999]

*nota: swagger es la utilidad para desarrolladores que permite el consumo de los servicios RESTS directamente desdeel backend para pruebas de integración. Esta funcionalidad consume el servicio con las credenciales definidas aquí.

¿Qué tipo de autenticación debo elegir?

En cuanto al tipo de autenticación, puede usarse indistintamente una u otra, aunque se podrá tomar en cuenta lasiguiente recomendación:

Seguridad

40Aplicaciones

Page 41: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Aplicaciones del tipo iOS y Android = OAuth (usuarios)Aplicaciones del tipo API = OAuth (aplicación)

Una autenticación del tipo usuario requiere que el TOKEN intercambiado por OAuth vaya siendo renovado. Si elusuario (o la aplicación móvil) no tiene actividad, este TOKEN caduca, y por tanto la sesión queda invalidada.

Una autenticación del tipo aplicación gestiona la renovación del TOKEN de forma automática, es decir, la aplicaciónque consuma el API REST de viafirma documents sólo tendrá que inicializar sus credenciales una única vez, y notendrá que gestionar la renovación del TOKEN intercambiado por OAuth.

Con esta configuración podemos controlar el ciclo de vida de los mensajes y notificaciones generados por el sistema.

Mensajes y sus Metadatos

Un mensaje, y todos sus metadatos, serán persistidos en la base de datos del sistema durante el tiempo especificado(en días) en la configuración Borrado Mensajes.

Por ejemplo, si el tiempo indicado es de 30 días, transcurrido ese tiempo, se procede al borrado del mensaje en la tabla"VD_MESSAGE", así como todos los metadatos asociados a este mensaje en la tabla "VD_METADATA".

¿Dónde puedo revisar un mensaje que ya se borró de la tabla VD_MESSAGE?

Si ya se borró el mensaje, el único sitio donde se podría consultar es en la Auditoría. Para más información ver elcapítulo Panel de Control > Auditoría.

Notificaciones

Las notificaciones, serán persistidos en la base de datos del sistema durante el tiempo especificado (en días) en laconfiguración Borrado Notificaciones.

Por ejemplo, si el tiempo indicado es de 30 días, transcurrido ese tiempo, se procede al borrado de la notificación en latabla "VD_NOTIFICATION".

Esta configuración sólo aplica a las plataformas iOS y Android, y para cada una de ellas se cuenta con una

Ciclo de vida de mensajes y notificaciones

Configuración de notificaciones push

41Aplicaciones

Page 42: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

configuración específica.

Una aplicación iOS podrá tener asociados dos certificados digitales para la firma de las push (.p12), uno paraproducción, y otro para los ambientes de prueba (sandbox).

Cuando se marca la casilla "Usar certificado de producción" entonces se usará el p12 para tal efecto.

Las pruebas de carga y estrés deberían realizarse con la configuración "sandbox", para evitar que Apple pudierainterpretar ese consumo como spam y bloquee la cuenta.

Para el caso de Android no se usarán certificados .p12 sino tokens previamente generados desde el developers centerde Google.

Configuración PUSH para iOS

Configuración PUSH para Android

42Aplicaciones

Page 43: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

La figura de grupos nos permitirá una agrupación lógica de usuarios y plantillas.

Un usuario podrá hacer uso de todas las plantillas asignadas al grupo al que pertenece.

Existe la posibilidad de filtrar el listado de grupos del usuario. Para ello introducimos el texto por el que se desee filtaren el cuadro de búsqueda y se pulsar Buscar . Para eliminar el filtro de búsqueda y volver a mostrar el listado completode grupos pulsamos Mostrar todos .

Las acciones que un administrador puede llevar a cabo en esta pantalla son:

Añadir un nuevo grupo pulsado el botón Añadir.Editar un grupo pulsando en el lápiz de la fila correspondiente al mensaje.Eliminar un grupo pulsando la cruz roja de la fila correspondiente al mensaje.

Grupos

Listado de grupos

Edición de grupos

43Grupos

Page 44: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

En la pantalla de edición de grupos se añaden al grupo los usuarios y plantillas que lo compondrán. De forma que todoslos usuarios del grupo tendrán acceso a todas las plantillas del grupo.

Si el usuario no perteneciera a ningún grupo, o éste no tuviera asignado ninguna plantilla, se tomará en cuenta laasignación individual de plantillas para el usuario, es decir, las plantillas asignadas directamente en su cuenta deusuario.

Usuarios sin grupos asignados

44Grupos

Page 45: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Como se puede ver en la imagen anterior, el usuario NO pertenece a ningún grupo, sin embargo, tiene asignadas 9plantillas.

45Grupos

Page 46: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

El backend distinguirá entre dos tipos de usuarios: súper administrador y usuario.

Un súper administrador tendrá todos los permisos disponibles para configurar y operar desde el backend.

Un usuario se limitará a las acciones autorizadas al rol al que pertenezca, teniendo en cuenta que un usuario podrátener uno o varios roles al mismo tiempo.

Sólo un súper administrador tendrá permisos para la asignación de roles, los cuales están predefinidos en cincogrupos:

Administrador (ADMIN)Coordinador (MANAGER)Asesor (DISPATCHER)Usuario (USER)Desarrollador (DEVELOPER)

Cualquier usuario podrá editar sus datos personales y su contraseña. El resto de datos de configuración y operaciónsólo podrán ser editados por un súper administrador.

Gestión de Usuarios

Permisos de edición

46GestióndeUsuarios

Page 47: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

La cuenta de usuario podrá ser ilimitada (no caduca) o podrá tener una fecha de caducidad.

La fecha de caducidad se gestiona de dos formas distintas:

Una cuenta de usuario podrá tener una fecha de caducidad, la cual puede ser elegida desde un calendario, o bien,

Caducidad de Cuentas

Caducidad asociada a una fecha conocida

47GestióndeUsuarios

Page 48: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

indicar un número de días de validez. Por ejemplo, 60 días de validez, tomándose en cuenta la fecha actual como elprimer día de validez.

Si el usuario supera un número de días sin usar su cuenta, el sistema la caducará automáticamente.

Este número de días es definido en la configuración del sistema, en Panel de Control, sólo administrable por un súperadministrador.

Desde el backend se podrán podrán gestionar las cuentas activas, inactivas y aquellas cuentas que están en procesode reactivación.

¿Cuándo se bloquea una cuenta?

Como ya se ha explicado anteriormente, una cuenta puede tener asociada una caducidad, determinada en base a una

Caducidad asociada a una inactividad del usuario

Ciclo de vida de las cuentas de usuario

Cuenta bloqueada

48GestióndeUsuarios

Page 49: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

fecha conocida o por un período de inactividad.

Y como tercer motivo, una cuenta podría ser bloqueada por un súper administrador, a través de la opción disponible enel listado de cuentas activas.

¿Cómo se vuelve a habilitar una cuenta bloqueada?

Aquel usuario que intente acceder con su cuenta bloqueada o caducada, verá un mensaje en la pantalla del loginindicándole el estado de su cuenta. Al mismo tiempo, se le ofrecerá la posibilidad de solicitar la reactivación de sucuenta.

Para ello, el sistema seguirá los siguientes pasos:

solicitará user y passwordsi las credenciales introducidas son correctas, comprobará si el usuario tiene informado una cuenta de correo:si no la tuviera, se le solicita que informe una cuentael sistema envía una notificación al responsable del backend encargado de la reactivación de cuentas.

La cuenta de correo a la que se informa de una nueva solicitud se define en la configuración del sistema, ver capítulodel Panel de Control > Configuración del Sistema.

Del mismo modo, en la gestión de usuarios se podrá acceder a la pestaña "Cuentas Pendientes", en las que un súperadministrador podrá autorizar o denegar la reactivación.

Cualquiera de las acciones realizadas generará una notificación vía email al usuario afectado.

En caso de que la reactivación haya sido autorizada, dicho correo electrónico incluirá la nueva contraseñaautogenerada por el backend, contraseña que podrá ser cambiada por el usuario accediendo a los datos de su cuenta.

Cuando se da de alta un nuevo usuario, puede introducirse su contraseña por parte del usuario administrador o bienseleccionar que el usuario tenga que activar su cuenta. De forma que el usuario recibirá un correo electrónico paravalidar la cuenta y en el momento de validar la cuenta se le solicitará la que indique la contraseña de su cuenta.

En este apartado se mostrarán lo usuarios pendientes de validación y el usuario administrador podrá reenviarles elcorreo de confirmación.

Se podrán importar usuarios en bloque a partir de la carga de una plantilla excel (.xlsx) que se puede descargar desdela propia pantalla de importación de usuarios.

El proceso de importación mostrará el resumen de la operación, indicando el número de usuarios importados

Reactivación de Cuentas

Cuentas no confirmadas

Importación de Usuarios

49GestióndeUsuarios

Page 50: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

correctamente y, en su caso, indicando el error y motivo de aquellos usuarios que no pudieron ser importados.

50GestióndeUsuarios

Page 51: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Las acciones permitidas para cada role son las siguientes:

Las acciones permitidas para cada rol son las enumeradas a continuación:

Administrador (ADMIN)

AplicacionesEditarAcceso al listadoEliminar

DispositivosAcceso al listadoCrearEliminarAcceder al detalle

GruposEditarAcceso al listadoEliminar

Auditoría de mensajesAcceso al listado

MensajesAcceso al listado de mis mensajes

NotificacionesAcceso al listado de mis notificaciones

PlantillasAsignarEditarAcceso al listadoEliminarGenerar documentosEdición Básica

UsuariosEdición BásicaAcceso al listado

Coordinador (MANAGER)

GruposEditarAcceso al listadoEliminar

PlantillasAcceso al listado

Asesor (DISPATCHER)

51Roles

Page 52: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

MensajesAcceso al listado de mis mensajes

PlantillasAcceso al listadoGenerar documentos

Usuario (USER)

MensajesAcceso al listado de mis mensajes

PlantillasAcceso al listadoGenerar documentos

Desarrollador (DEVELOPER)

Servicios RestAcceder (UI swagger, con el detalle de todos las entidades expuestas por servicios rest)

Códigos de ErroresAcceso al listado (listado a la codificación de errores)

52Roles

Page 53: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

53Roles

Page 54: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

54Roles

Page 55: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Ver Apartado 3.5 Panel de Usuario/Plantillas pero en este apartado el usuario administrador tendrá acceso a todas lasplantillas de la aplicación. A diferencia del apartado anterior en el que sólo tiene acceso a sus plantillas.

Plantillas

55Plantillas

Page 56: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Listado de dispositivos dados de alta en la aplicación.

Existe la posibilidad de filtrar el listado de dispositivos disponibles. Para ello introducimos el texto por el que se deseefiltar en el cuadro de búsqueda y se pulsar Buscar . Para eliminar el filtro de búsqueda y volver a mostrar el listadocompleto de dispositivos pulsamos Mostrar todos .

Dispositivos

56Dispositivos

Page 57: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Selección del idioma en el que se presenta la página.

#header#locale{}

Para ocultar este elemento:

#header#locale{

display:none;

}

Estilos de la página de firma

Selección de idioma

Logo

57Estilospáginadefirma

Page 58: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Cabecera de la página, donde se muestra el logo.

#headerh1{}

Para ocultar este elemento.

#headerh1{

display:none;

}

Estos estilos permiten configurar las dimensiones, la visualización, etc. del visor del documento a firmar. Por defecto,este elemento está oculto.

#pdf-viewer{}

Para mostrar este elemento:

#pdf-viewer{

display:block;

}

#content.sign-content-box.sign-title{}

Para ocultar este elemento:

#content.sign-content-box.sign-title{

display:none;

}

Visor del documento a firmar

Título de la petición

Descripción de la petición

58Estilospáginadefirma

Page 59: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

#content.sign-content-box.sign-subtitle{}

Para ocultar este elemento:

#content.sign-content-box.sign-subtitle{

display:none;

}

.sign-content-box.sign-content-metadata.sentCode{}

Para ocultar este elemento:

.sign-content-box.sign-content-metadata.sentCode{

display:none;

}

.sign-content-box.sign-content-metadata.sentDate{}

Para ocultar este elemento:

.sign-content-box.sign-content-metadata.sentDate{

display:none;

}

Botones para descargar el documento antes de firmarlo o una vez firmado.

#content.sign-actions{}

Para ocultar este elemento:

Identificador de petición

Fecha y hora de la petición

Descarga del documento

59Estilospáginadefirma

Page 60: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

#content.sign-actions{

display:none;

}

QR-code para continuar con el proceso desde la app nativa.

#content.apps-info.qrcode-arrow{}

Para ocultar este elemento:

#content.apps-info.qrcode-arrow{

display:none;

}

Listado de apps nativas que se pueden descargar para trabajar con la petición.

#content.apps-info.apps{}

Para ocultar este elemento:

#content.apps-info.apps{

display:none;

}

Paneles de evidencias, firmas y aprobaciones. Engloban todas las acciones a realizar con la petición.

#content.sign-content-box.sign-action-group{}

Continuar el proceso desde app nativa

Descarga de apps

Panel de evidencias/firmas/aprobaciones

Titulo del panel

60Estilospáginadefirma

Page 61: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

#content.sign-content-box.sign-action-subtitle{}

Para ocultar el titulo:

#content.sign-content-box.sign-action-subtitle{

display:none;

}

Evidencia completada

#content.sign-page-actionsli.IMAGE.buttons.ic_received{}

Evidencia no completada

#content.sign-page-actionsli.IMAGE.buttons.ic_not_received{}

Evidencia completada

#content.sign-page-actionsli.SIGNATURE.buttons.ic_received{}

Evidencia no completada

#content.sign-page-actionsli.SIGNATURE.buttons.ic_not_received{}

Evidencia completada

#content.sign-page-actionsli.OTP_SMS.buttons.ic_received{}

Botones evidencias

Evidencias tipo imagen

Evidencias tipo firma

Evidencias tipo SMS

61Estilospáginadefirma

Page 62: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Evidencia no completada

#content.sign-page-actionsli.OTP_SMS.buttons.ic_not_received{}

Evidencia completada

#content.sign-page-actionsli.GENERIC.buttons.ic_received.disabled{}

Activado

#content.sign-page-actionsli.IMAGE{}

Desactivado

#content.sign-page-actionsli.IMAGE.disabled{}

Activado

#content.sign-page-actionsli.SIGNATURE{}

Desactivado

#content.sign-page-actionsli.SIGNATURE.disabled{}

Activado

Evidencias tipo GENERIC CIFIN

Iconos evidencias

Evidencias tipo imagen

Evidencias tipo firma

Evidencias tipo SMS

62Estilospáginadefirma

Page 63: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

#content.sign-page-actionsli.OTP_SMS{}

Desactivado

#content.sign-page-actionsli.OTP_SMS.disabled{}

Activado

#content.sign-page-actionsli.GENERIC.QUESTION{}

Activado

#content.sign-page-actionsli.GENERIC.CHECK{}

Desactivado

#content.sign-page-actionsli.GENERIC.CHECK.disabled{}

Botón destinado a rechazar la petición.

#content.sign-content.reject-request{}

Para ocultar este elemento:

#content.sign-content.reject-request{

display:none;

}

Evidencias tipo GENERIC CIFIN

Evidencias tipo GENERIC CHECK

Rechazar petición

63Estilospáginadefirma

Page 64: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Estilos de los botones en los popups

.ui-widget-contenta.ui-button{}

Estilos para la barra de título de los popups

.ui-dialog.ui-widget-header

Otros estilos

Botones popups

Titulo popups

64Estilospáginadefirma

Page 65: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

Listado de informes disponibles en el backend. Se mostrará el listado de informes configurados en la carpetadocuments-home/reports

Existe la posibilidad de filtrar el listado de informes. Para ello introducimos el texto por el que se desee filtar en elcuadro de búsqueda y se pulsa Buscar . Para eliminar el filtro de búsqueda y volver a mostrar el listado completo deinformes pulsamos Mostrar todos .

El usuario autenticado tiene la posibilidad de descargar el JSON de configuración del informe pulsando en Descargardel listado de informes.

Al pulsar en Ver del listado de informes se accede a la pantalla de Gestión de Informes en la cual se podrán ver losdatos de configuración del informe, así como descargar cada uno de los informes generados en formato CSV.

Informes

Ver informe

65Informes

Page 66: 2. Estado del sistema - doc.viafirma.com · electrónico. Para ello, informaremos debidamente en el JSON del MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.

66Informes