REGISPRO. es >>> RegistroElectronico.es

Contenidos útiles para la práctica registral._______Edita: Joaquín Delgado (Registrador de la Propiedad y Notario)

TITULAR:

J. DELGADO: REGISTRO ELECTRONICO: SOBRE LA OBLIGATORIEDAD (O NO) DE LOS CAMPOS OBLIGATORIOS

Contenido:

SOBRE LA OBLIGATORIEDAD (O NO) DE LOS CAMPOS OBLIGATORIOS

 

 

 

* 1.- EL NUEVO ARTICULO 242 LH ESTABLECE UNA TRIPLE OBLIGATORIEDAD:

 

* 1.1.- LA OBLIGATORIEDAD DE LA BASE DE DATOS AUXILIAR:

“Los Registros dispondrán de una base de datos auxiliar para la gestión registral.”

 

Nota: efectivamente, los registros disponemos de ella.

 

* 1.2.- LA OBLIGATORIEDAD DE LA CUMPLIMENTACIÓN DE DETERMINADOS CAMPOS EN LA BASE DE DATOS OBLIGATORIA 

“El Colegio de Registradores de la Propiedad, Mercantiles y de Bienes Muebles de España determinará los campos de la base de datos que se consideren de cumplimentación obligatoria, conforme a un modelo semántico común a todos los Registros de la Propiedad e interoperable que deberá ser aprobado por la Dirección General de Seguridad Jurídica y Fe Pública. En todo caso se considerarán datos esenciales a los efectos de lo dispuesto en este artículo los relativos a los nombres, apellidos o denominaciones y documentos identificativos de los titulares registrales, el carácter y porcentaje de su titularidad, así como las responsabilidades por cantidades y plazos de las garantías dinerarias.”

 

Nota: curiosamente, la “Resolución de 7 de julio de 2023 de la Dirección General de Seguridad Jurídica y Fe Pública por la que se aprueban los campos que obligatoriamente deben cumplimentarse en la base de datos auxiliar de los Registros …”, no cumple con el mandato legal, pues según la ley son datos esenciales (y por tanto, campos obligatorios) “la responsabilidades por cantidades” , y en cambio, según dicha resolución, solo es obligatorio el campo de responsabilidad hipotecaria por “principal” pero no por otras cantidades o conceptos, como intereses, costas, etc.

 

* 1.3.- LA OBLIGATORIEDAD DE LA CORRESPONDENCIA ENTRE LOS DATOS (CAMPOS) DE LA BASE DE DATOS OBLIGATORIA Y LOS DATOS EXPRESADO EN  LOS ASIENTOS REGISTRALES:

Deberá asegurarse la correspondencia entre los datos de la base de datos auxiliar de los Registros y los asientos registrales. Para ello, sin perjuicio del contenido esencialmente literario del asiento, sus datos fundamentales solamente podrán incorporarse al asiento mediante su previa introducción en la base de datos y únicamente podrán corregirse modificando la base de datos y generando un nuevo asiento antes de su firma que sustituya al anterior. Firmado el asiento no podrá alterarse la base de datos sin rectificar el asiento, conforme a la legislación hipotecaria.”

 

Nota: de lo anterior se deduce que a TODOS los datos cuya cumplimentación en la base de datos es obligatoria, se les aplica la regla de que solo podrán constar en el asiento de manera vinculada con la base de datos. Por ejemplo, el nombre o nif de un titular, que ha de constar en la base de datos, no puede hacerse constar en el asiento como texto libre ordinario, sino a través de una variable que vincule y fusione el correspondiente campo de la base de datos y aplique el “bloqueo” según el cual no se podrá cambiar el dato del asiento sin cambiarlo previamente en el campo de la base de datos.  Todo ello es perfectamente lógico y congruente.

Sin embargo, hasta donde me consta, el Corpme ha venido hasta ahora trasladando la idea de que los campos obligatorios sólo son obligatorios  en la base de datos, y no en el asiento, de modo que cada registrador puede decidir libremente si el asiento incluye muchos, pocos o ningún campo vinculado de la base de datos. Si se aplica esta libertad, se estaría vulnerando la exigencia legal que comentamos, que tiene por finalidad “asegurar la correspondencia entre los datos de la base de datos auxiliar de los Registros y los asientos registrales”.

 

 

* 2.- EL PROGRAMA DE GESTIÓN EXPERIOR IMPONE OTRAS “OBLIGATORIEDADES”  ABSURDAS, O BLOQUEOS QUE TRASTORNAN INNECESARIAMENTE EL DESPACHO Y COTEJO NORMAL DE LOS ASIENTOS:

 

* 2.1 Obligatoriedad de formato:

Cuando en la redacción del asiento se introduce el dato de un campo de la base de datos (por ejemplo, el nombre de un titular, o los datos de una escritura), el dato se “bloquea”  (lo cual es lógico para que no se modifique su contenido sin modificar a la vez el contenido del campo de la base de datos), pero absurdamente  impide cambiar el formato del texto: no se puede poner negritas, ni subrayado, ni cursiva, ni mayúsculas,  etc

Además, resulta absurdo que los datos numericos se introduzcan en la base de datos con cifras (que es lo más lógico, práctico y claro), y sin embargo, la mayoría de las variables de fusión en el asiento los transforman a letra, con lo que se pierde esa claridad para el cotejo y lectura de cifras, fechas, etc.

 

* 2.2 Obligatoriedad de posición:

También impide absurdamente cambiar la posición del párrafo que contenga un dato tomado de un campo de la base de datos. Por ejemplo, si en la redacción del asiento se quiere mover un párrafo de un lugar a otro, dentro del mismo asiento, no es posible.

 

* 2.3 Obligatoriedad de “bloqueo” de datos introducidos en el asiento que no son campos de la base de datos ni constan en ella.

Cuando se introduce en el asiento una variable que NO importa los datos de un campo de la base de datos, sino que es una simple parada en el modelo que se utilice para insertar por primera vez algún dato (que no está previamente ni va a estar después en la base de datos), como por ejemplo, la fecha de un certificado técnico, o de una licencia, etc, el programa “bloquea” absurdamente el texto introducido como si fuera (que no lo es) un campo de la base de datos.   Y por tanto, al confrontar el asiento, y detectar algún error o necesidad de modificación, no permite, absurdamente, ni cambiar su formato, ni su posición, ni su contenido.

 

 

* 3.- Y CAMBIO, EL PROGRAMA EXPERIOR PRESCINDE DE UNA OBLIGATORIEDAD QUE SÍ QUE ES OBLIGATORIA Y DE SENTIDO COMÚN:

 

Como hemos dicho, para “asegurar la correspondencia entre los datos de la base de datos auxiliar de los Registros y los asientos registrales” es obligatorio, por ejemplo que el nombre o nif de un titular, que ha de constar en la base de datos, no puede hacerse constar en el asiento como texto libre ordinario, sino a través de una variable que vincule y fusione el correspondiente campo de la base de datos y aplique el “bloqueo” según el cual no se podrá cambiar el dato del asiento sin cambiarlo previamente en el campo de la base de datos.

 

Siendo ello así, no basta que en el asiento conste el contenido del campo de la base de datos, sino que tambien debería constar el nombre del campo que le da sentido al contenido.

Pongo un ejemplo:

Si Antonio Abad Abad es el vendedor y Bernardo Bados Bados es el comprador, y así se ha hecho constar en la base de datos, no debe bastar que en el asiento, al decir quién es el vendedor  se incluya uno de estos nombres, y al decir quién es el comprador se incluya otro, sino que en cada caso se incluya el nombre correcto, y no el contrario erróneo.

Si el contenido de los campos de la base de datos se introduce en el asiento precedido o seguido de un texto literario que altera el carácter o sentido del dato, no se está garantizando la correspondencia entre los datos de la base de datos y los del asiento.

Y actualmente no hay ningún control informático que verifique este extremo.

Debería exigirse que al introducir un dato en el asiento, no sólo se introduzca el contenido del campo, sino también el nombre del campo, que es lo que le da sentido al contenido.

Es como si al rellenar la responsabilidad hipotecaria por principal, intereses, y costas, se hace bien en la base de datos, pero en el asiento se hace mal y se dice que lo de principal es la cifra de intereses, lo de intereses la de costas, y lo de costas la de principal.  Todos ellos con contenidos de campos de la base de datos, pero con los “nombres de campos” libremente (y erróneamente) asignados en el asiento.

 

Y es que debemos ser conscientes de que no sólo la base de datos y la publicidad formal, sino también en cierta medida los propios asientos registrales,  deberían tener un formato estructurado (y hasta en cierto punto de “encasillado”) para expresar los datos esenciales, sin perjuicio de la redacción literaria libre, que la propia ley reconoce y protege,  cuando sea precisa o conveniente (detalles descriptivos , estipulaciones contractuales, peculiaridades jurídicas, etc)

 

El tradicional “formato ladrillo” que han tenido los asientos registrales durante más de siglo y medio (frases inacabables, gramaticalmente complejísimas, incluyendo una mezcla de datos esenciales y accesorios, protegidos y no protegidos, con cifras y fechas en letra, sin espacios libres ni puntos aparte y con letra pequeña) era quizá explicable en el formato papel y firma manuscrita, para evitar alteraciones o interpolaciones en el texto ya firmado.

Y ese “formato ladrillo”  con letra pequeña y apretada, sin huecos ni puntos aparte, también contribuía al objetivo de economizar papel, impresión, compra de libros, estanterías y espacio de archivo físico, etc.

Pero en el formato electrónico y en el mundo de la interoperabilidad del dato, el “formato de texto-ladrillo” y la expresión de cifras y fechas en letra en vez de numérico son sólo una rémora o inercia perjudicial para todos.

 

En mi opinión hay que evolucionar cuanto antes, con decisión, hacia la inscripción, (literaria, sí, pero)  con un cierto esquema y datos estructurados, en formatos y estilos uniformes,  incluso con datos desplegables o accesibles mediante hipervínculos a la base de datos que corresponda (por ejemplo, podría bastar que el asiento muestre por defecto un nombre y DNI, y el CSV de un documento,  para, cuando sea preciso, abrir el desplegable que muestra el resto de datos personales o el vínculo que muestre el contenido íntegro del documento en cuestión, o, incluso,  la vinculación a datos complementarios que constan ya inscritos en el registro mercantil o civil cuando proceda).  En esto consiste, precisamente, y esencialmente,  la informática, la interoperabilidad,  y las bases de datos relacionales , y, en definitiva, la modernización del Registro de la Propiedad, sin perder su esencia, y para mejor servir a sus fines.

 

 

 

* CONCLUSION:

Se sugiere la conveniencia de que se corrijan cuanto antes las deficiencias expresadas en este breve articulo y se evolucione en la dirección propuesta.

 

 

 

 

 

 

 

 

 

REGIS PRO. es © 2014