Agencia Estatal Boletín Oficial del Estado

El Esquema Nacional de Interoperabilidad (ENI) se establece en el artículo 156 de la Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público, que sustituye al apartado 1 del artículo 42 de la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos. Su finalidad es la creación de las condiciones necesarias para garantizar el adecuado nivel de interoperabilidad técnica, semántica y organizativa de los sistemas y aplicaciones empleados por las Administraciones públicas, que permitan el ejercicio de derechos y el cumplimiento de deberes a través del acceso electrónico a los servicios públicos, a la vez que redunda en beneficio de la eficacia y la eficiencia, en el marco, entre otras normas, de la Ley 39/2015 de Procedimiento Administrativo Común de las Administraciones Públicas.

El Esquema Nacional de Interoperabilidad se establece en el apartado 1 del artículo 156 de la Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público. Su finalidad es la creación de las condiciones necesarias para garantizar el adecuado nivel de interoperabilidad técnica, semántica y organizativa de los sistemas y aplicaciones empleados por las Administraciones públicas, que permitan el ejercicio de derechos y el cumplimiento de deberes a través del acceso electrónico a los servicios públicos, a la vez que redunda en beneficio de la eficacia y la eficiencia.

El Real Decreto 4/2010, de 8 de enero, por el que se regula el Esquema Nacional de Interoperabilidad en el ámbito de la Administración Electrónica establece, en su disposición adicional primera, el desarrollo de la serie de Normas Técnicas de Interoperabilidad que son de obligado cumplimiento por parte de las Administraciones públicas.

Las Normas Técnicas de Interoperabilidad desarrollan aspectos concretos de diversas cuestiones, tales como: documento electrónico, digitalización, expediente electrónico, copiado auténtico y conversión, política de firma, estándares, intermediación de datos, modelos de datos, gestión de documentos electrónicos, conexión a la red de comunicaciones de las Administraciones públicas españolas, modelo de datos para el intercambio de asientos registrales y declaración de conformidad; todos ellos necesarios para asegurar los aspectos más prácticos y operativos de la interoperabilidad entre las Administraciones públicas y con el ciudadano.

En particular, la Norma Técnica de Interoperabilidad de Modelo de Datos para el Intercambio de asientos entre las entidades registrales se aprobó mediante Resolución de 19 de julio de 2011 (BOE de 30 de julio), de la Secretaría de Estado para la Función Pública, para responder a lo recogido en el artículo 24.4 de la Ley 11/2007, de 22 de junio, sobre garantía de interconexión de todas oficinas de registro y posibilitar el acceso por medios electrónicos a los asientos registrales y a las copias electrónicas de los documentos presentados.

Posteriormente, la entrada en vigor de la Ley 39/2015, de 1 de octubre, del Procedimiento Administrativo Común de las Administraciones Públicas, y las previsiones recogidas en su artículo 16.4, que establece que los registros electrónicos de todas y cada una de las Administraciones, deberán ser plenamente interoperables, de modo que se garantice su compatibilidad informática e interconexión, así como la transmisión telemática de los asientos registrales y de los documentos que se presenten en cualquiera de los registros, hacen necesario la actualización de esta Norma Técnica de Interoperabilidad.

Así, la Norma Técnica de Interoperabilidad de Modelo de Datos para el intercambio de asientos entre las Entidades Registrales, que sustituye a la anterior, normaliza los intercambios registrales entre las oficinas de registro para garantizar su interoperabilidad y, como novedad, permite la adecuación de los intercambios a las nuevas necesidades de las oficinas de registro y favorece el avance hacia una tramitación automatizada de la documentación intercambiada.

La presente norma técnica se ha elaborado con la participación de todas las Administraciones públicas a las que les es de aplicación, ha sido informada favorablemente por el Comité de Dirección de Tecnologías de la Información y Comunicaciones y por la Comisión Sectorial de Administración Electrónica.

En aplicación de lo dispuesto en el apartado 2 de la disposición adicional primera del Real Decreto 4/2010, de 8 de enero,

Esta Secretaría de Estado resuelve:

Primero.

Se aprueba la Norma Técnica de Interoperabilidad de Modelo de Datos para el intercambio de asientos entre las Entidades Registrales (SICRES4), que sustituye a la anterior Norma Técnica de Interoperabilidad de Modelo de Datos para el intercambio de asientos entre las Entidades Registrales (SICRES3) de 2011, y cuyo texto se incluye a continuación.

Segundo.

La Norma Técnica de Interoperabilidad de Modelo de Datos para el intercambio de asientos entre las Entidades Registrales (SICRES4) que se aprueba mediante la presente Resolución se aplicará desde el día siguiente al de su publicación en el «Boletín Oficial del Estado».

Desde su publicación en el «Boletín Oficial del Estado» se dispondrá de un año para la adaptación de la anterior Norma Técnica de Interoperabilidad. Durante ese período, ambas versiones estarán vigentes.

Madrid, 22 de julio de 2021.–La Secretaria de Estado de Digitalización e Inteligencia Artificial, Carmen Artigas Brugal.

NORMA TÉCNICA DE INTEROPERABILIDAD DE MODELO DE DATOS PARA EL INTERCAMBIO DE ASIENTOS ENTRE LAS ENTIDADES REGISTRALES

I. SICRES: Sistema de Información Común de Registros de Entrada y Salida

La Ley 30/1992, de 26 de noviembre, de Régimen Jurídico de las Administraciones Públicas y del Procedimiento Administrativo Común (en adelante, Ley 30/1992), estableció por primera vez la posibilidad de que las Administraciones públicas utilizaran medios electrónicos y telemáticos en su relación con el ciudadano. Dentro de este ámbito se incluía inicialmente la integración informática de los registros generales con los restantes registros administrativos (artículo 38.3 de la Ley 30/1992, de 26 de noviembre).

Posteriormente, el legislador amplió las potestades de las Administraciones en este ámbito a través de la Ley 24/2001, de 27 de diciembre, de Medidas Fiscales, Administrativas y del Orden Social, que venía a añadir un nuevo apartado al ante dicho artículo 38 por el que se reconocía «la posibilidad de crear registros telemáticos para la recepción o salida de solicitudes, escritos y comunicaciones que se transmitan por medios telemáticos».

Siguiendo el espíritu de la Ley 30/1992, de 26 de noviembre, el Consejo Superior de Informática (en adelante, CSI), en aquel momento Consejo Superior de Administración Electrónica según el Real decreto 589/2005, (en adelante, CSAE), definió en 1995 por primera vez, el estándar SICRES versión 1.0 (Sistemas de Información Común de Registros de Entrada y Salida) por el que se fijaban los criterios que debían cumplir todos los sistemas de Registro que se implantaran en la Administración, versión que fue actualizada en 1999 por el CSI a través de la norma SICRES versión 2.0.

En definitiva, con la definición de SICRES se perseguía lograr una tramitación más eficaz de los expedientes a través de un Registro Central interconectado con las distintas oficinas registrales y garantizar los derechos que la citada Ley 30/1992 reconocía.

Posteriormente, la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicio Públicos, volvió a ratificar la regulación de los registros electrónicos administrativos y la interconexión de estos. Así, el artículo 24 de esta ley, estableció que las Administraciones Públicas crearían registros electrónicos para la recepción y remisión de solicitudes, escritos y comunicaciones.

En 2010, se aprobó el Real Decreto 4/2010, de 8 de enero, por el que se regula el Esquema Nacional de Interoperabilidad en el ámbito de la Administración Electrónica, el cual es de aplicación a todas las Administraciones Públicas. En el artículo 25 de este Real Decreto, se establece que los registros electrónicos deben regirse por lo establecido en el Esquema Nacional de Interoperabilidad, y por tanto también por las Normas Técnicas de Interoperabilidad aprobadas a raíz de este.

Así, se aprobó en 2010, con aplicación a todas las Administraciones Públicas, la Norma Técnica de Interoperabilidad de Modelo de Datos para el Intercambio de asientos entre las Entidades Registrales, la cual aprobaba la versión 3 de la norma SICRES. Esta norma SICRES3.0 presentaba las principales diferencias con respecto a sus predecesoras:

i. Orientación a arquitectura de intermediación.

ii. Incorporación de ficheros adjuntos a los intercambios.

iii. Mejora en los mecanismos de control del intercambio.

II. Objetivo y alcance de esta Norma Técnica de Interoperabilidad

El objetivo de la Norma Técnica de Interoperabilidad (en adelante, NTI) de Modelo de Datos para el intercambio de asientos entre las Entidades Registrales es definir las condiciones y características para la interconexión de registros de las Administraciones públicas, y, por tanto, el intercambio de información entre estas.

Para ello, esta NTI contiene la especificación SICRES 4.0, evolución de su antecesora SICRES 3.0,

Su contenido abarca los siguientes puntos:

i. Definición y características principales de SICRES 4.0

ii. Esquema de datos y formatos para los ficheros intercambiados.

iii. Mecanismos de control y gestión de errores a aplicar en el proceso.

iv. Prestaciones de alto nivel a garantizar por el sistema de intercambio utilizado.

III. Ámbito de aplicación y destinatarios

El contenido de esta NTI es de aplicación para todos los órganos de la Administración pública o Entidades de derecho Público vinculadas o dependientes de aquélla (en adelante, organizaciones) que participan en el intercambio de asientos registrales, ya sea para la prestación de servicios directos a los ciudadanos, como de cara al intercambio de información con otros órganos.

Dentro del ámbito de aplicación definido, los destinatarios del contenido de esta norma son los siguientes:

i. Responsables de sedes electrónicas y, por tanto, de garantizar los requisitos de interoperabilidad de las mismas y, concretamente, de sus registros electrónicos.

ii. Responsables y administradores de aplicaciones, redes y servicios corporativos de cualquier órgano.

IV. Modelo de datos para el intercambio de asientos entre Entidades Registrales

IV.1 Definición y características generales de SICRES 4.0.

SICRES 4.0 constituye el modelo de datos para el intercambio de asientos entre Entidades Registrales. Esta versión de SICRES, alineada con la filosofía de sus predecesoras, tiene como finalidad contribuir a garantizar la interconexión entre organizaciones, permitiendo así, un servicio de mayor calidad a los ciudadanos tal y como marca la Ley 39/2015, de 1 de octubre, del Procedimiento Administrativo Común de las Administraciones Públicas.

Las principales características de SICRES 4.0 que la diferencian de sus versiones anteriores son:

i. Reordenación, actualización e incorporación de campos. El modelo de intercambio SICRES 4.0 agrupa y reordena los campos de los distintos segmentos para dotarlos de mayor contenido semántico y facilitar su interpretación. Asimismo, se eliminan o actualizan campos obsoletos y se incorporan nuevos campos.

ii. Referenciación de documentos electrónicos. Se sustituye el intercambio de los ficheros de los documentos electrónicos objeto de registro e intercambio, por el intercambio de referencias a tales documentos electrónicos. De este modo, se optimiza el funcionamiento de la Plataforma de Intercambio y se superan limitaciones de la misma.

iii. Metadatado para automatización del tratamiento de los asientos registrales y sus documentos anexos. Se incorporan en el intercambio registral nuevos metadatos destinados a facilitar la automatización del tratamiento de los asientos y los documentos electrónicos. Asimismo, se incorpora la posibilidad de intercambiar otros metadatos no definidos a priori, bien sea para cubrir necesidades futuras, o bien sea para cubrir necesidades particulares de cada organismo.

Durante el período de transición de las aplicaciones de registro de SICRES 3.0 a SICRES 4.0 se garantizará la interoperabilidad entre ambas normas. La plataforma de intercambio de asientos registrales SIR se encargará de garantizar la compatibilidad y la comunicación entre aplicaciones de registro que utilicen diferentes versiones de la norma.

El modelo conceptual de espacio de intercambio bajo SICRES 4.0 aparece en la siguiente figura:

Según este esquema, el espacio de intercambio engloba todo el proceso de intercambio desde la Unidad de Tramitación Origen hasta la Unidad Tramitación Destino proporcionando un contexto único a cada uno de los intercambios. Dentro de este espacio, destacan los siguientes elementos:

Unidades de Tramitación de Origen y Destino: Entidades, o unidades pertenecientes a dichas entidades, responsables de la tramitación de los documentos registrados. La identificación de ambas Unidades debe ser única a través de Directorios unificados, como se indica en el apartado VI.4 de esta norma.

Entidad Registral de Origen y Destino. Entidades, o unidades pertenecientes a dichas entidades, que, bien sea por medio del personal al servicio del mismo, o bien sea por medio de actuación automatizada, se encarga tanto de inscribir los asientos de entrada y salida en el Registro Electrónico de la Administración u Organismo, como de llevar a cabo el proceso de intercambio registral, responsabilizándose del envío y recepción de Mensajes de Datos de Intercambio y Mensajes de Control, desde el punto de vista técnico y de comunicación, pero sin implicación en la tramitación de los documentos. La identificación de ambas Entidades Registrales debe ser única a través de Directorios unificados, como se indica en el apartado VI.4 de esta norma.

Mensaje de datos de intercambio. Es creado y emitido por la Entidad Registral de Origen y alberga, además de campos para el control e identificación, la información del asiento registral y los documentos correspondientes adjuntos. Su estructura y formato se definen en el apartado IV.2 de esta norma.

Mensajes de control. Son emitidos por la Entidad Registral destino o por el propio sistema de intercambio y proporcionan información de estado para la gestión de la operación de intercambio. Su estructura y formato se definen en el apartado IV.3 de esta norma.

Sistema de intercambio. Proporciona la gestión del intercambio y la comunicación directa con las Entidades Registrales Origen y Destino. Sus funciones y requisitos técnicos deben cumplir lo establecido en el apartado VI de esta norma.

Plataforma de intercambio. Comprende el Sistema de intercambio y las Entidades Registrales de Origen y de Destino.

El proceso de intercambio inicia y finaliza en la Entidad Registral de Origen, punto de contacto con el ciudadano o Unidad de Tramitación que origina la creación del asiento registral.

El inicio viene marcado por la generación del mensaje de datos de intercambio en la Entidad Registral Origen conteniendo la información del asiento. A través del sistema de intercambio, este mensaje es recibido en la Entidad Registral destino, que, si procede, confirma la recepción correcta al Origen a través del mensaje de control correspondiente.

Los intercambios disfrutan de un contexto único dentro del espacio SICRES mediante la asignación de un identificador del intercambio único a cada proceso de transacción que es generado por la aplicación de registro de la Entidad Registral de Origen y acompaña tanto al mensaje de datos de intercambio como a los mensajes de control relacionados. La generación del identificador del intercambio se detalla en el apartado V.1 de esta NTI.

IV.2 Estructura y contenido del mensaje de datos de intercambio.

El mensaje de datos de intercambio de SICRES4.0 es el mensaje que alberga la información objeto del intercambio. Su codificación se especifica con un ejemplo de implementación del modelo en XML en el Anexo 2 de esta norma.

Este mensaje está compuesto por los 7 segmentos que aparecen en la figura y cuya descripción funcional se desarrolla a continuación.

Segmento de Origen (o Remitente).

Tabla 1. Datos de Origen (o Remitente)

La cumplimentación de la Unidad de Tramitación de Origen será obligatoria cuando el emisor del registro sea un órgano u organismo perteneciente o dependiente de una Administración Pública, como se indica en el comentario del campo.

Sin embargo, no será obligatoria la cumplimentación de este campo en los reenvíos o rechazos que se realicen de registros emitidos por Administraciones Públicas. Asimismo, tampoco será obligatoria la cumplimentación, en envíos registrales que se traten de rectificaciones de intercambios previos. Es decir, en envíos registrales que realicen órganos y organismos de las Administraciones Públicas como consecuencia de haber confirmado por error un registro que habían recibido.

B) Segmento de destino.

Tabla 2. Datos de destino

C) Segmento de Interesado.

Este segmento comprende los datos que identifican al Interesado y su Representante en la entidad mensaje de datos de intercambio. Este segmento se puede declarar de forma múltiple. Su condicionalidad se define en los comentarios de los campos «Datos del Interesado» y «Datos del Representante».

Tabla 3. Datos de Interesado

Los campos «Dirección postal», «Correo electrónico» o «Teléfono móvil» son condicionales de modo que, se pueden cumplimentar voluntariamente, en cualquier caso, pero deben cumplimentarse obligatoriamente si el canal de contacto en cuestión ha sido seleccionado expresamente en el campo «Canal preferente de notificaciones», en «Solicita aviso de puesta a disposición de la notificación por correo electrónico» o en «Solicita aviso de puesta a disposición de la notificación por SMS», respectivamente.

El campo «Canal preferente de notificaciones» no podrá tener el valor «1» para interesados obligados a relacionarse electrónicamente con las administraciones.

D) Segmento de Asiento.

Tabla 4. Datos de Asunto

El formato de las fechas y horas de registro y presentación es yyyyMMddHHmmssZ, donde Z representa la variación en horas y minutos respecto a GMT (Ejemplo: 20200917124020+0200).

Los campos «Otros metadatos generales», «Otros metadatos particulares», «Campo» y «Valor» permiten intercambiar otros metadatos relativos al asiento adicionales a los ya transmitidos en campos nativos de la norma SICRES.

En el caso de «Otros metadatos generales», el listado de atributos a intercambiar (es decir, el listado de posibles contenidos del campo «Campo») será acordado y fijado por las Administraciones Públicas, con independencia de la aprobación de la NTI y pudiendo ser modificado a lo largo del tiempo. Los atributos de este listado podrán tener carácter opcional, condicional u obligatorio, por lo que deberán ser implementados por todas las Entidades Registrales.

En el caso de «Otros metadatos particulares», el listado de atributos a intercambiar (es decir, el listado de posibles contenidos del campo «Campo») será determinado por la Unidad de Tramitación de Destino que lo desee atendiendo a sus necesidades particulares, pudiendo establecerse un único listado a emplear por todos los orígenes, o listados particulares para determinados orígenes. Estos atributos serán siempre opcionales.

E) Segmento de Anexo.

Este segmento comprende datos e información relativa a los documentos electrónicos que son objeto de registro e intercambio. En el caso de justificantes de registro, su intercambio como documento anexo es opcional.

El segmento contiene la referencia única del documento electrónico a intercambiar. Esta referencia única consiste en un conjunto de campos con metadatos que permiten al destino la identificación unívoca del documento, la localización del repositorio en el que se encuentra almacenado y, en su caso, la acreditación de permisos para su acceso. Los campos y formatos de la referencia única del documento serán acordados y establecidos por las Administraciones Públicas al margen de esta NTI y pudiendo ser modificados a lo largo del tiempo. Esta información se recoge en la «Especificación del Sistema de referenciación de documentos en las AAPP» del Foro por el Documento Electrónico – Documentación para la Tramitación Automatizada (https://administracionelectronica.gob.es/comunidades/verPestanaDocumentacion.htm?idComunidad=141).

Este segmento es opcional y puede declararse de forma múltiple.

Tabla 5. Datos de Anexo

F) Segmento de Internos y Control.

Tabla 6. Datos de Internos y Control

Las consideraciones a tener en cuenta para asignar valor al campo ‘Documentación física y/o soportes’ son:

i. Acompaña documentación física (u otros soportes) requerida (‘1’). Indica que el mensaje de datos de intercambio debe ser tratado junto con documentación física (u otros soportes) necesaria para su trámite. Por tanto, no se puede aceptar y reenviar (si aplica) el fichero de intercambio hasta que toda la documentación física requerida haya sido recibida en la Entidad Registral de destino. Tampoco se puede dar número de registro oficial a la entrada, dándole temporalmente el tratamiento de ‘pre-asiento’, hasta disponer de la documentación física requerida.

Ejemplo de este caso, sería un intercambio en el que se realiza copia electrónica auténtica sólo de una parte de los documentos presentados, o cuando dichas copias no se pueden realizar (no se dispone de medios o el soporte no permite la digitalización correcta, como en el caso de sobres cerrados).

ii. Acompaña documentación física (u otros soportes) complementaria (‘2’). Indica que se envía documentación física (u otros soportes) que acompaña al mensaje de datos de intercambio, pero que ésta no es estrictamente necesaria para su trámite. Por tanto, se podría aceptar, pero no se podría reenviar (si aplica) el fichero de intercambio hasta que toda la documentación física haya sido recibida en la Entidad Registral de destino.

iii. No acompaña documentación física ni otros soportes (‘3’). Indica que el mensaje de datos de intercambio no se acompaña de ninguna documentación física ni otros soportes. Por tanto, se podría aceptar y reenviar (si aplica) el fichero de intercambio en cuanto llegue a la Entidad Registral de destino.

Además, este segmento incorpora la posibilidad de incluir información sobre la Entidad Registral de Inicio, cuya localización es necesaria para que un mensaje de datos de intercambio, que ha sido rechazado, pueda ser reenviado a la Entidad Registral que originó el proceso de intercambio, sin perder el rastro de la Entidad Registral que generó el reenvío. El modo en que el mensaje de datos de intercambio es reenviado a la Entidad Registral de Inicio se desarrolla en el apartado V de esta norma.

Del mismo modo, el segmento incorpora también la posibilidad de incluir información sobre la Unidad de Tramitación de Inicio.

G) Segmento de Formulario Genérico.

Tabla 7. Datos de Formulario Genérico

Este segmento opcional permite el intercambio del contenido de los formularios de propósito general que se implementan en los registros electrónicos.

Si se utiliza, además de incluir los datos específicos de este segmento, el formulario genérico se deberá incluir como documento anexo en el segmento de Anexo.

Esto permite que se puedan intercambiar formularios genéricos tanto con registros electrónicos con registros presenciales.

IV.3 Estructura y contenido del mensaje de control.

La entidad mensaje de control en SICRES 4.0 es un fichero que contiene la información de control y notificación acerca del estado de una operación de intercambio.

A continuación se definen los campos que componen un mensaje de control a utilizar, no así, el formato en que se implementen dentro del sistema de gestión de intercambio.

Tabla 8. Datos de Mensaje de control

V. Descripción y estados del intercambio

En este apartado se describen los posibles estados en los que se puede encontrar el apunte registral objeto del intercambio.

Tal y como se introdujo en el apartado IV.1, el proceso de intercambio inicia y finaliza en la Entidad Registral Origen, ya sea en el propio ciudadano o en la Unidad de Tramitación de Origen.

A lo largo de todo este proceso, Entidad Registral Origen y Destino se informan mutuamente sobre el estado del intercambio a través de sus respectivos campos:

i. Campo ‘Tipo de anotación’ del segmento de datos ‘Internos y Control’ del mensaje de datos de intercambio que emite la Entidad Registral Origen y destino.

ii. Campo ‘Tipo de mensaje’ de los mensajes de control que se envía.

De esta forma, el control sobre el estado del asiento registral a lo largo del proceso de intercambio se gestiona y controla de manera conjunta entre Origen y destino.

El inicio del intercambio viene marcado por la generación por parte de la Entidad Registral Origen del mensaje de datos de intercambio cuyo campo ‘Tipo de anotación’ tiene valor de Pendiente. El intercambio finaliza cuando, después de que la Entidad Registral de destino haya notificado a la Entidad Registral de Origen el asentimiento del intercambio enviándole un mensaje de control de tipo confirmación, esta Entidad Registral de Origen acepta el mensaje devolviéndole a la Entidad Registral de Destino un mensaje de control de tipo ack.

Las Entidades Registrales deben implementar mecanismos y procedimientos que eviten la duplicación de asientos en caso de recepciones múltiples. Las herramientas para esta implementación son los datos ‘Identificador de Intercambio’, ‘Identificador de Fichero’ y ‘Número de Secuencia’.

V.1 Generación del Identificador de Intercambio.

La aplicación de registro de la Entidad Registral Origen que interviene en el proceso de intercambio, es responsable de la generación de un identificador de intercambio único para cada operación en el espacio de intercambio del tipo:

Este identificador se mantiene durante todo el proceso de intercambio tanto en el sistema de gestión de intercambio como en la aplicación de registro de la Entidad Registral destino. En el apartado Anexo 1A se describen las reglas para la generación de este identificador.

V.2 Estados en el mensaje de datos de intercambio.

Los estados que registra el mensaje de datos de intercambio en el campo de ‘Tipo de anotación’ son:

i. Pendiente (‘01’): Indica que el mensaje de datos de intercambio está pendiente de envío al sistema de intercambio y que está pendiente de la asignación de un identificador del intercambio para iniciar el proceso.

ii. Envío (‘02’): Indica que el mensaje de datos de intercambio está en pleno proceso de intercambio, y por tanto, ha partido desde la Entidad Registral de Origen pero está pendiente aún de convertirse en registro en firme por la Entidad Registral de destino.

iii. Reenvío (‘03’): Indica que el mensaje de datos de intercambio es enviado de nuevo desde la Entidad Registral de destino.

La razón para el reenvío es, generalmente, que el destino indicado en el primer envío no corresponde. Cuando se da esta situación, la Entidad Registral de destino puede identificar la Entidad Registral de destino correcta y reenviarlo a ésta en lugar de rechazar el envío que realizó la Entidad Registral Origen.

Esta secuencia de envíos y los valores que toma el campo ‘Tipo de anotación’ aparecen en la siguiente figura.

V.3 Estados en los mensajes de control.

La información de estado del intercambio que se refleja en los mensajes de control a través de los siguientes valores de ‘Tipo de mensaje’:

i. ACK-aceptación (‘01’): Notifica la recepción correcta del mensaje de datos de intercambio desde un punto de vista exclusivamente técnico, por lo que no constituye la confirmación de finalización correcta de todo el proceso de intercambio.

A continuación, se muestra una figura explicativa de la emisión de un mensaje de control tipo aceptación:

Los mensajes de control de aceptación deberán emitirse también para notificar la recepción correcta desde el punto de vista técnico de los mensajes de control de tipo confirmación. En la figura 10 se muestra la emisión de este mensaje en tal escenario.

ii. Error (‘02’): Notifica la recepción errónea o incompleta del mensaje de datos de intercambio desde un punto de vista técnico. Los posibles tipos de errores que se pueden dar se identifican mediante un rango de error y el propio código de error. Este mensaje de control refleja el tipo de error a través de la codificación de errores que se detalla en el Anexo 1.D.

La siguiente figura refleja la emisión de un mensaje de control tipo Error:

Ante esta situación, la Entidad Registral de Origen (‘A’) puede enviar el mensaje de datos de intercambio a la Entidad Registral de destino (‘B’), reenviarlo o rechazarlo.

iii. Confirmación (‘03’) y ACK Confirmación (‘04’): Una vez recibido el mensaje de datos de intercambio y todos sus documentos anexos, se acepta que el proceso de intercambio se ha realizado con éxito y, por tanto, se notifica a la Entidad Registral de Origen o Inicio que la recepción ha sido correcta confirmando por tanto el asentimiento del intercambio completado.

La figura que sigue, muestra la secuencia que provoca la emisión de un mensaje de control tipo confirmación y la correspondiente aceptación de la confirmación:

El asentimiento es necesario para el correcto funcionamiento de los flujos de intercambio definidos, por lo que debe ser implementado por todas las Entidades Registrales para el intercambio de los asientos. El asentimiento permite confirmar que el asiento registral es correcto y corresponde a la Entidad Registral de destino por lo que debe emitirse tanto tras la recepción de un mensaje de datos de intercambio con ‘Tipo de anotación’ envío como si se trata de un reenvío.

La Entidad Registral de Destino deberá reenviar el Mensaje de Control de confirmación si pasado un periodo de tiempo (predefinido en cada sistema de intercambio) no recibe de la Entidad Registral de Origen o Inicio el Mensaje de Control de ACK Confirmación.

iv. Rechazo (‘05’) y ACK Rechazo (‘06’): Indica que el mensaje de datos de intercambio no ha sido aceptado por la Entidad Registral de destino.

En caso de rechazo, el mensaje de datos de intercambio será enviado siempre a la Entidad Registral de Inicio.

La Entidad Registral de Destino deberá reenviar el Mensaje de Control de rechazo si pasado un periodo de tiempo (predefinido en cada sistema de intercambio) no recibe de la Entidad Registral de Inicio el Mensaje de Control de ACK Rechazo.

VI. Funciones y requisitos del sistema de intercambio.

El sistema de intercambio utilizado para emisión y recepción de los mensajes definidos en los apartados anteriores funciona, en el espacio de intercambio SICRES, como elemento responsable de:

i. Centralizar el registro de operaciones de intercambio y garantizar la trazabilidad de las mismas.

ii. Gestionar la situación temporal de los ‘pre-asientos registrales’.

iii. Proporcionar la seguridad en el transporte de la información a través de mecanismos de encriptación en el mensaje de datos de intercambio.

iv. Firma electrónica del mensaje de datos de intercambio.

Como ya se ha indicado, esta norma no establece los requisitos tecnológicos concretos que deben proporcionar el sistema que da soporte a un intercambio de asientos registrales, ya que SICRES4.0 es independiente de la tecnología o plataforma sobre la que se realice la transmisión de los elementos que forman el intercambio propiamente dicho.

No obstante, sí se establecen unos principios básicos que deben ser cubiertos por el sistema de intercambio que se utilice, como son:

i. Integridad: Garantía de que la información no es modificada en los procesos de intercambio.

ii. Confidencialidad: Disponibilidad de la información solamente para usuarios autorizados.

iii. Autenticidad: Legitimidad del origen de la información.

iv. No repudio: Imposibilidad de negación ante terceros del envío y/o recepción por parte del emisor y/o receptor de la información.

v. Accesibilidad: Posibilidad de acceso eficiente sólo para entidades autorizadas.

A continuación se desarrollan estos requisitos de seguridad y, posteriormente, las funciones que debe proporcionar el sistema de intercambio.

VI.1 Requisitos de seguridad.

a) Autenticación de los sistemas implicados.

Además de la implementación de las políticas de seguridad para los usuarios de la plataforma de intercambio, se asegura la identidad de cada uno de los sistemas intervinientes en el espacio de intercambio.

Así, todos los sistemas que participen en el proceso de intercambio, incluidos los sistemas de las Entidades Registrales de Origen y Destino, están correctamente identificados y validados en el espacio de intercambio.

b) Integridad.

La plataforma de intercambio proporciona los mecanismos necesarios, a fin de garantizar que el contenido completo de los mensajes de datos intercambiados permanezca inalterado durante el proceso de intercambio.

Este punto se asegura a través del protocolo de transporte de mensajes entre las Entidades Registrales de Origen y Destino que utilice el sistema de intercambio, y la tecnología de transmisión de datos.

c) Garantía de no repudio.

La plataforma de intercambio provee de los mecanismos necesarios para garantizar el no repudio del mensaje de datos de intercambio.

VI.2 Gestión del proceso de intercambio.

Como ya se ha mencionado, para iniciar el intercambio, la aplicación de registro de la Entidad Registral Origen genera el mensaje de datos de intercambio de forma completa y lo envía al sistema de gestión de intercambio.

La plataforma de intercambio es responsable de verificar la validez del mensaje de datos de intercambio según el formato establecido en esta norma.

Además, el sistema de gestión de intercambio es el encargado de garantizar la transmisión entre los sistemas de la Entidad Registral Origen y destino.

Posteriormente, la aplicación de registro de la Entidad Registral destino es la responsable de interpretar de forma correcta el fichero intercambiado.

Hasta que el intercambio concluye, la plataforma de intercambio tiene la misión de resolver de forma correcta la situación temporal del ‘pre-asiento registral’ que desaparece cuando se produce la recepción completa de todos los ficheros que pudieran constituir un envío.

Dentro de cada espacio de intercambio debe definirse un conjunto de reglas que permitan la gestión del intercambio entre Entidades Registrales a través de un sistema de intercambio. Estas reglas permiten definir los mecanismos y herramientas para realizar el intercambio en condiciones adecuadas incluyendo:

i. La tecnología de comunicación entre los distintos agentes del intercambio.

ii. Los mecanismos y procedimientos específicos para el envío y recepción de ficheros, y para garantizar la integridad y seguridad de los envíos.

iii. Las políticas específicas de protección de datos que deben ser de aplicación.

iv. Los mecanismos de trazabilidad de los intercambios y la información que se registre sobre los mismos.

v. Procedimientos detallados de gestión de errores y excepciones.

a) Gestión de envíos de mensajes y anexos.

La plataforma de intercambio debe realizar una gestión adecuada del envío de mensajes y los posibles documentos anexos asociados, que garantice la correcta identificación del registro completo en la Entidad Registral de destino y su posterior almacenamiento.

b) Gestión del flujo.

Las operaciones de intercambio tienen definido un estado (definidos en el apartado V de la presente norma) en el que se indica la fase lógica dentro del proceso de intercambio en la que se encuentra el fichero, y los posibles eventos que pueden ocurrir.

c) Evitar duplicados.

El sistema de gestión de intercambio contiene los mecanismos necesarios para garantizar que los asientos que se envíen o reciban por duplicado de manera errónea, sean identificados como tales.

Las Entidades Registrales deben implementar mecanismos y procedimientos que eviten la duplicación de asientos en caso de que se reciban varias veces, utilizando los datos ‘Identificador de Intercambio’, ‘Identificador de Fichero’ y ‘Número de Secuencia’.

d) Gestión de mensajes.

El sistema de intercambio dispone de funcionalidades de gestión de mensajes de actividad, a fin de proporcionar información de seguimiento a la Entidad Registral de Origen, una vez realizado el intercambio, tal y como se describe en el apartado V.

La gestión y conservación de los anexos, entendidos éstos como documentos electrónicos, se definen y normalizan en la NTI de Política de gestión de documentos electrónicos.

e) Conservación de la información del asiento registral.

Cuando los pre-asientos registrales intercambiados no se convierten en asientos firmes en la Entidad Registral de destino, ésta no debe conservar el mensaje de datos de intercambio ni sus documentos adjuntos. Únicamente debe conservar traza de la transacción de intercambio realizada.

VI.3 Soporte del modo de prueba.

El sistema de gestión de intercambio debe disponer de la capacidad de soportar el modo de prueba en el proceso de intercambio, de tal forma que permita realizar pruebas de intercambio.

El modelo de datos incluye un identificador para mensajes de datos de intercambio que indica que son una prueba que aparece detallado en los apartados IV.2 y IV.3.

VI.4 Directorios unificados de organismos, entidades y unidades.

En el sistema de intercambio se deberán emplear códigos de identificación unívoca de las Entidades Registrales y Unidades de Tramitación que actúan como emisoras o receptoras de asientos registrales (campos de Entidades Registrales y Unidades de Tramitación de los segmentos «De Origen», «De Destino» y «De internos y control»). Para ello, podrán emplearse los siguientes directorios unificados:

i. Directorio Común de Unidades Orgánicas y Oficinas (DIR3): directorio que, cumpliendo con el artículo 9 del Real Decreto 4/2010, codifica de forma unívoca, tanto los organismos, órganos y unidades de tramitación de las administraciones públicas, como las Oficinas de Registro y atención al ciudadano, y mantiene información sobre ellos y las relaciones entre ellos.

ii. Directorio de Entidades (DIRe): directorio que mantiene información sobre personas jurídicas del ámbito privado y su estructura organizativa, asignando códigos de identificación unívoca a las posibles unidades de tal estructura.

iii. Otros directorios unificados que puedan crear y acordar las administraciones públicas.

Los códigos de estos directorios podrán también ser empleados para identificar y facilitar la obtención de información complementaria o adicional sobre los interesados (campo «Código de Directorios unificados» del «Segmento de Interesado»).

VI.5 Control y gestión de errores.

La plataforma de intercambio es responsable de realizar una gestión adecuada de los errores y excepciones que puedan ocurrir durante el proceso de intercambio, que facilite la restauración de información en la medida de lo posible.

a) Tipología de errores de intercambio.

Los principales errores que pueden ocurrir durante el intercambio registral pueden clasificarse, en base a la naturaleza del error, como:

i. Errores lógicos: relativos a errores en las validaciones en estructura y/o en contenido de los ficheros de intercambio y/o en direcciones de origen o destino. En definitiva, cualquier error no achacable a un problema tecnológico, pero que provoca que el resultado del intercambio no sea exitoso.

ii. Errores físicos: relativos a errores que se pueden asociar con la tecnología que interviene en el proceso de intercambio, como la no disponibilidad de máquinas, de elementos de la infraestructura de software, excepciones de código no controladas y otros.

iii. Errores de transmisión de datos: relativos a errores que pueden ocurrir durante la transmisión de datos debido a problemas en las comunicaciones.

La codificación de los errores aparece en el Anexo 1.D.

Tabla 9. Descripción de errores de intercambio

b) Errores lógicos.

Descripción de los errores lógicos:

i. Errores de validación de los datos de intercambio. Ocurren al resultar erróneas las validaciones lógicas de los datos del intercambio en formatos, datos requeridos y correspondencia entre descripciones de contenido y el contenido de los datos de intercambio.

ii. Errores de direccionamiento. Ocurren cuando la identidad del remitente o destinatario reflejada en el mensaje de datos de intercambio no se corresponde con el que debería enviar o recibir la información.

iii. Errores en las reglas de intercambio. Aparece un evento no esperado durante el intercambio registral.

iv. Errores de ciclo de envío no completado. No se puede completar el ciclo de envío completamente.

Tratamiento de los errores lógicos:

i. Errores de validación de los datos de intercambio. En el momento que se detecte esta falta de integridad en los datos de intercambio, se deberá interrumpir el proceso marcando como erróneo el mensaje de datos de intercambio. A continuación se deberá notificar al Origen de que no se ha podido interpretar correctamente los datos, informándole del código de error lógico ocurrido.

Una vez notificado, la Entidad Registral de Origen se dispondrá a analizar la naturaleza del error para realizar acciones de subsanación:

1. Si es relativo a una composición errónea del mensaje de datos de intercambio y anexos asociados, deberá recomponerlos y retransmitirlos.

2. Si el error es debido a una corrupción de datos durante la transmisión deberá simplemente retransmitirlos.

La operación deberá ser registrada como errónea en el log de operaciones del sistema de gestión del intercambio.

ii. Errores de direccionamiento. Se pueden producir por errores en la dirección del remitente o en el destinatario.

Si se produce un error en los datos del destinatario, es posible que sucedan dos escenarios:

1. Los datos llegan a una Entidad Registral de destino no esperada. En este caso, la Entidad destino deberá rechazar el registro recibido y notificar a la Entidad Origen de la ocurrencia de este suceso a través del sistema de gestión de intercambio.

2. Los datos llegan a un destino no esperado fuera del espacio de intercambio registral, es decir, no es enviado a una Entidad Registral. El error se podrá identificar por un aviso de error de direccionamiento proporcionado por el sistema de gestión de intercambio (por ejemplo ‘destino inalcanzable’), o al no recibirse la confirmación de la entrega pasado un tiempo preestablecido por parte de la Entidad Registral de Origen.

El tratamiento de estos errores se llevaría a cabo a través de la realización retransmisiones desde el sistema de intercambio o desde la Entidad Registral Origen, una vez solucionado el error de direcciones.

Si se produce un error en los datos del remitente, es posible que sucedan dos escenarios:

1. Se recibe una confirmación de entrega en una Entidad Registral de Origen no esperada. En este caso, la Entidad Origen deberá rechazar la confirmación.

2. La confirmación de entrega es enviada a una dirección fuera del espacio de nombres del intercambio registral. En este caso el error se detectará si la entidad Origen no recibe la confirmación de la entrega en un tiempo preestablecido o si al enviar la confirmación se produce un aviso de error de direccionamiento, por ejemplo ‘destino inalcanzable’.

Para tratar los errores de destinatario se intentarán retransmisiones desde el sistema de intercambio o desde la Entidad Registral destino, una vez solucionado el error de direcciones.

Los errores de direcciones pueden estar motivados por entradas erróneas en el Directorio Común. En estos casos, se debe detectar (normalmente al aparecer errores de direccionamiento) y realizar la corrección de la entrada incorrecta.

Las operaciones anteriormente indicadas deberán ser registradas como erróneas en el log de operaciones del sistema de gestión de intercambio.

iii. Errores en las reglas de intercambio. Este error ocurrirá si aparece un evento no esperado durante el intercambio registral (por ejemplo, se recibe un segundo mensaje de control de confirmación de entrega correcta para un mismo Identificador de Intercambio).

En este caso, el sistema de gestión de intercambio se vuelve inconsistente, por lo que se deberá registrar el elemento que ha producido el evento, y realizar una notificación para solucionar el problema.

iv. Errores de ciclo de envío no completado. Este error ocurrirá si no se hubiera podido cerrar el ciclo de envío completo, al interrumpirse en alguno de sus pasos. Se detecta al sobre pasarse los límites de tiempo esperados para que un paso del ciclo se realice.

El Origen de este error puede ser variado, debido tanto a problemas lógicos como físicos. El tratamiento normal para estos casos es la retransmisión de los datos.

La operación errónea deberá ser registrada en el log del sistema de gestión de intercambio, indicando los reintentos efectuados y si fueron exitosos o no. Si al efectuar el número de reintentos determinado no se consiguiera cerrar el ciclo, el conjunto de datos objeto del error deberá ser marcado como erróneo notificando a el sistema de intercambio, la necesidad de un tratamiento para su subsanación.

c) Errores físicos.

Descripción de los errores físicos:

Se producen cuando ocurren errores, hardware o software, en alguno de los sistemas intervinientes.

Tratamiento de los errores físicos:

Los errores en el sistema de intercambio deben ser tratados según los procedimientos de operación que apliquen en cada caso.

Las operaciones de intercambio que se viesen afectadas por el error ocurrido se identificarán y restaurarán en la medida de lo posible.

d) Errores de transmisión.

Descripción de los errores de transmisión:

No se puede producir el intercambio, debido a que el sistema de destino o el de Origen no están disponibles.

Tratamiento de los errores de transmisión:

Si alguno de los sistemas no está disponible el tratamiento normal será la realización de reintentos de envío.

La operación errónea deberá ser registrada en el log del sistema de gestión de intercambio, indicando los reintentos efectuados y si fueron exitosos o no. Si al efectuar el número de reintentos establecidos no se consiguiera cerrar el ciclo, el conjunto de datos objeto del error deberá ser marcado como erróneo notificando al sistema de gestión de intercambio de la necesidad de un tratamiento para su subsanación.

VII. Otras recomendaciones

Existen otros requerimientos de tecnología que pueden ser considerados como recomendaciones.

a) Registro de la actividad de intercambio.

Se recomienda, que el estado y la secuencia de las operaciones de intercambio se registren en un sistema centralizado del sistema de intercambio, que permita realizar la trazabilidad de las operaciones efectuadas.

Las aplicaciones de registro de las Entidades Registrales implicadas en un proceso de intercambio, podrán hacer uso de los datos de trazabilidad para proporcionar un servicio de seguimiento a los ciudadanos e instituciones que lo soliciten.

b) Persistencia en errores y excepciones.

Los datos del mensaje de datos de intercambio y el estado de sus operaciones a través del sistema de gestión de intercambio, deberían permanecer en un medio persistente cuando se produzcan errores o excepciones que impidan su envío/recepción. Se garantizará la perdurabilidad de registro y su estado, si ocurrieran errores en el proceso de intercambio.

ANEXO 1

Codificación

ANEXO 1A

Identificador del intercambio

A cada operación de intercambio se le asocia un identificador que permite designar la operación de forma única.

La codificación de este identificador se compone según el siguiente criterio:

Tabla 10. Formato del identificador del intercambio

La generación de este código se realiza antes de enviar el Mensaje de datos de intercambio, al sistema de gestión de intercambio.

ANEXO 1B

Identificadores de ficheros de mensajes de datos de intercambio y anexos

En el proceso de intercambio se transmiten diferentes ficheros entre Origen y Destino. Por un lado, a través de la Plataforma de Intercambio, se transmiten ficheros con Mensajes de Datos de Intercambio y Mensajes de Control. Además, haciendo uso de las interfaces y canales habilitadas por los repositorios del sistema de referencias únicas, se transmiten ficheros con documentos electrónicos en formato ENI que contiene los documentos anexos.

Todos estos ficheros deben ser intercambiados con nombres de acuerdo con un formato normalizado. El uso de esta notación permite identificar de forma única a los ficheros dentro del espacio de intercambio registral.

A continuación se muestra el formato del nombre que deben tener los ficheros de Mensajes de Datos de Intercambio y de fichero de Anexos:

Tabla 11. Formato del identificador de los ficheros de Mensajes de Datos de Intercambio y de Anexos

ANEXO 1C

Identificador de ficheros de mensajes de control y notificación

Los ficheros de los Mensajes de Control se nombrarán de acuerdo con la siguiente estructura:

Tabla 12. Formato del Identificador de fichero del Mensaje de control y notificación

ANEXO 1D

Errores

Para realizar la codificación de los errores del sistema de intercambio, se utiliza un código de cuatro dígitos, estructurado en dos niveles:

i. Rango de error, que agrupa la definición de un tipo general de error. Se codifica con los dos primeros dígitos y establecen una secuencia:

ii. Código de error, pertenecientes a un rango. Utilizando los dos últimos dígitos, de la siguiente forma:

Por ejemplo, se puede definir un rango de error del tipo:

‘0000’ Errores en la validación del mensaje de datos de intercambio.

Y definir un error concreto como:

‘0001’ No se incorporan los anexos definidos en el mensaje de datos de intercambio.

ANEXO 2

Ejemplo esquema XML del modelo de datos SICRES 4.0

El objetivo de este anexo es mostrar el modelo de datos SICRES 4.0 en formato de esquema XML. Se adjuntarán ficheros XML de ejemplo.

Representación gráfica del esquema del mensaje de datos de intercambio

Esquema XML del mensaje de datos de intercambio

Representación gráfica del esquema del mensaje de control

Esquema XML del mensaje de control