You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Descripción del problema
Se crean personas con NIF duplicados desde formularios.
Las rutinas que tenemos de validación de NIFs permiten introducir los NIFs que empiezan por cero sin el cero (la longitud queda menor que la habitual), tanto en los formularios como en el CRM.
Este hecho, unido a que la búsqueda por idTax de los formularios busca por el literal entero provoca que se pueda entrar 2 veces el mismo NIF (empezando por 0 y sin ponerlo) y no lo detecte como duplicado. Sin embargo la posterior rutina de validación de datos sí detecta el duplicado.
Cómo reproducir el problema
Puede comprobarse en cualquier instancia utilizando algún NIF que empiece por 0, por ejemplo: 01234567L
Comportamiento esperado
El comportamiento esperado sería que se detecte el NIF ya existente y no se duplique el registro en la entrada vía formulario.
Solución propuesta
Opción 1) Modificar las rutinas de validación para pedir siempre la longitud completa
Opción 2) Hacer el padding con 0s del campo, tanto en el formulario antes de buscarlo como en el momento de guardar la persona
Ambas opciones requerirán también de un script para regularizar todos los NIFs que ya existan y puedan no tener la longitud adecuada.
Entre las 2 opciones, quizás sea más deseable la segunda, ya que no afecta a la entrada de datos.
No contemplo la opción de cambiar la manera de buscar el idTax porqué no sabríamos si el posible registro en BBDD está o no con los ceros delante. Y añadir el padding en el momento de la búsqueda destrozaría el posible uso del índice sobre el identification_number
The text was updated successfully, but these errors were encountered:
Descripción del problema
Se crean personas con NIF duplicados desde formularios.
Las rutinas que tenemos de validación de NIFs permiten introducir los NIFs que empiezan por cero sin el cero (la longitud queda menor que la habitual), tanto en los formularios como en el CRM.
Este hecho, unido a que la búsqueda por idTax de los formularios busca por el literal entero provoca que se pueda entrar 2 veces el mismo NIF (empezando por 0 y sin ponerlo) y no lo detecte como duplicado. Sin embargo la posterior rutina de validación de datos sí detecta el duplicado.
Cómo reproducir el problema
Puede comprobarse en cualquier instancia utilizando algún NIF que empiece por 0, por ejemplo: 01234567L
Comportamiento esperado
El comportamiento esperado sería que se detecte el NIF ya existente y no se duplique el registro en la entrada vía formulario.
Solución propuesta
Opción 1) Modificar las rutinas de validación para pedir siempre la longitud completa
Opción 2) Hacer el padding con 0s del campo, tanto en el formulario antes de buscarlo como en el momento de guardar la persona
Ambas opciones requerirán también de un script para regularizar todos los NIFs que ya existan y puedan no tener la longitud adecuada.
Entre las 2 opciones, quizás sea más deseable la segunda, ya que no afecta a la entrada de datos.
No contemplo la opción de cambiar la manera de buscar el idTax porqué no sabríamos si el posible registro en BBDD está o no con los ceros delante. Y añadir el padding en el momento de la búsqueda destrozaría el posible uso del índice sobre el identification_number
The text was updated successfully, but these errors were encountered: