Tipos de validación estándar

Existen cuatro tipos de validación estándar:

En las secciones siguientes se describe en detalle cada una de esas operaciones.

Validación de comparación

La validación de comparación se utiliza para comparar un atributo de datos del modelo con atributo de datos o un literal, utilizando un operador de comparación concreto. En esta sección se describe su funcionalidad.

Propiedad de la validación de comparación Descripción
Campo de origen El atributo cuyo valor se compara. El campo de origen puede ser un atributo de datos, un atributo calculado o un atributo de participante de caso relacionado.
Comparación El operador que se utilizará en la comparación. Los operadores disponibles y sus significados se describen detalladamente en la sección siguiente.
Campo de destino El atributo cuyo valor se compara. Como norma general, el campo de destino debe ser del mismo tipo (ya sea de tipo de atributo o de tipo de atributo de datos) a fin de que se puedan comparar, y la lista de campos se filtra de modo que solo se muestren los atributos válidos para la comparación con el campo de origen seleccionado actualmente. La única excepción a esta regla es para los atributos de datos con un tipo de datos de Entero, Dinero o Flotante; estos tipos numéricos son mutuamente comparables.
Nota: Tenga en cuenta que los atributos de empleo relacionado, los atributos de direcciones y los atributos de comentarios nunca están disponibles para su uso en las validaciones de comparación.
Nota: El campo de destino no debe apuntar a los mismos atributos que el campo de origen.

La tabla siguiente describe las combinaciones válidas de operadores y tipos de datos para los atributos de datos y los atributos calculados. Se proporciona una tabla separada para los atributos de participante de caso relacionado ya que su comportamiento es diferente.

Tabla 1. Operadores y tipos de datos aplicables/datos de atributos calculados soportados en las validaciones de comparación
Operador Tipos de datos aplicables Descripción
== Booleano, Serie, Entero, Flotante, Dinero, Tabla de códigos y Fecha. El operador "Igual a" comprueba que los campos de origen y de destino tengan exactamente el mismo valor (si no tienen el mismo valor, la validación fallará). Consulte la nota siguiente para obtener más información sobre el uso de este operador para los campos de Fecha.
<> Booleano, Serie, Entero, Flotante, Dinero, Tabla de códigos, Fecha y Fecha y hora. El operador "Igual a" comprueba que los campos de origen y de destino no tengan exactamente el mismo valor (si tienen el mismo valor, la validación fallará). Consulte la nota siguiente para obtener más información sobre el uso de este operador para los campos de Fecha.
< Entero, Flotante, Dinero, Fecha y Fecha y hora. El operador "Menor que" comprueba que el valor del campo de origen sea inferior al valor del campo de destino. Si el valor del campo de origen es mayor que o igual al valor del campo de destino, esta validación fallará.
<= Entero, Flotante, Dinero, Fecha y Fecha y hora. El operador "Menor que o Igual a" comprueba que el valor del campo de origen sea inferior o igual al valor del campo de destino. Si el valor del campo de origen es mayor que el valor del campo de destino, esta validación fallará.
> Entero, Flotante, Dinero, Fecha y Fecha y hora El operador "Mayor que" comprueba que el valor del campo de origen sea superior al valor del campo de destino. Si el valor del campo de origen es menor que o igual al valor del campo de destino, esta validación fallará.
>= Entero, Flotante, Dinero, Fecha y Fecha y hora El operador "Mayor que o Igual a" comprueba que el valor del campo de origen sea superior o igual al valor del campo de destino. Si el valor del campo de origen es menor que el valor del campo de destino, esta validación fallará.
before Fecha y Fecha y hora. El operador "Antes" comprueba que el valor del campo de origen va antes que el valor del campo de destino. Si el valor del campo de origen va después del valor del campo de destino, esta validación fallará.
el o antes de Fecha y Fecha y hora. El operador "el o antes de" comprueba que el valor del campo de origen es el mismo día o anterior al valor del campo de destino. Si el valor del campo de origen es posterior al del valor del campo de destino, esta validación fallará.
después de Fecha y Fecha y hora El operador "después" comprueba que el valor del campo de origen va después que el valor del campo de destino. Si el valor del campo de origen es el mismo día o anterior al del valor del campo de destino, esta validación fallará.
el o después de Fecha y Fecha y hora El operador "el o después de" comprueba que el valor del campo de origen es el mismo día o posterior al valor del campo de destino. Si el valor del campo de origen es anterior al del valor del campo de destino, esta validación fallará.
Nota: Cuando se rellena el campo de origen con un atributo de datos cuyo tipo de datos es "Fecha", se añaden dos atributos adicionales (que no existen en los metadatos de la versión del tipo de pruebas dinámicas) a la lista del campo de destino:
  • evidenceReceivedDate

    Este atributo representa la fecha de recepción almacenada en el descriptor de pruebas de caso durante la ejecución. La infraestructura de pruebas dinámicas añadirá automáticamente este campo a cada página para crear y modificar pruebas de caso en relación con una versión del tipo de pruebas dinámicas, sin que sea necesario especificarlo en el modelo. Este campo representa la fecha en la que la agencia ha recibido una prueba para la organización y es una fecha que frecuentemente se utiliza en las validaciones de comparación de pruebas.

  • evidenceEffectiveDateOfChange

    Este atributo representa la fecha efectiva de recepción almacenada en el descriptor de pruebas de caso durante la ejecución. La infraestructura de pruebas dinámicas añadirá automáticamente este campo a cada página de modificación de pruebas de caso en relación con una versión del tipo de pruebas dinámicas, sin que sea necesario especificarlo en el modelo. Este campo representa la fecha efectiva del cambio para un registro de pruebas de caso (consulte la Guía de pruebas de Cúram para obtener más información sobre el significado de este campo) y también es una fecha que se utiliza frecuentemente en las validaciones de comparación de pruebas.

La tabla siguiente describe los operadores que se aplican a los atributos de participante de caso relacionado en las validaciones de comparación.

Tabla 2. Operadores soportados para los atributos de participante de caso relacionado en las validaciones de comparación
Operador Descripción
== El operador "Igual a" comprueba que los campos de origen y de destino representen al mismo participante; si no representan al mismo participante, la validación fallará. Para esta validación se proporciona un atributo booleano denominado superficial pero la infraestructura de pruebas dinámicas lo omite cuando el operador es "==" (si el ID del participante de caso relacionado es el mismo, el ID del rol de afectado también debe ser el mismo).
<> El operador "Igual a" comprueba que los campos de origen y de destino no tengan exactamente el mismo valor (si tienen el mismo valor, la validación fallará). Para esta validación se proporciona un atributo booleano adicional denominado superficial. Si se selecciona el atributo superficial en el diálogo Crear validación, entonces simplemente se comparan los ID de participante de caso relacionado en el registro de pruebas. Si no se selecciona el atributo superficial en el diálogo Crear validación, también se comprueba la igualdad de los ID de rol de afectado subyacentes.

La tabla siguiente describe algunas opciones adicionales disponibles en la validación de comparación.

Tabla 3. Opciones adicionales de la validación de comparación
Opciones Descripción
Literales Un atributo de origen (de atributos de datos o atributos calculados) puede compararse con respecto a literales. Como norma general, el valor literal debe tener el mismo tipo de datos que el atributo de origen seleccionado para que sean comparables. Para comparar un atributo de origen con un literal, seleccione el recuadro de selección "Utilizar un literal". A continuación, se puede escribir el valor literal (o se puede seleccionar para los tipos de datos tales como Tabla de códigos o Booleano o Fecha) en el campo Destino.
Nota: El valor literal solo se puede especificar para los atributos de datos.

Es posible que los administradores necesiten seleccionar un elemento de tabla de códigos como un valor literal cuando el tipo de datos de los atributos de origen es "tabla de códigos".

Cuando el tipo de datos del primer o segundo atributo es booleano, se pueden proporcionar los valores true o false.

En caso de que el tipo de datos sea Fecha, el valor de fecha se puede introducir o seleccionar a través de un selector de fecha.

El formato específico de entorno local se puede escribir para el valor literal de los tipos de datos numéricos como Entero, Flotante o Dinero (el símbolo de moneda también se puede escribir junto con el valor literal en el caso de atributo dinero.

Varias cláusulas

Se pueden proporcionar varias cláusulas en una validación de comparación, cada una de las cuales deberá pasar por el proceso de validación general.

Se pueden proporcionar varias cláusulas seleccionando el recuadro de selección "Varias cláusulas" en el panel Validación. Dos botones controlan la creación y supresión de varias cláusulas:

  • Añadir

    Cuando se pulsa este botón se añadirá una cláusula a la validación actual, en función de los campos de origen, destino y operador seleccionados actualmente.

  • Suprimir

    Sólo está habilitado cuando se selecciona una cláusula en la lista de cláusulas. Cuando se pulsa este botón se elimina la validación de comparación/cláusula seleccionada.

ID de mensaje

Para establecer un mensaje de validación personalizado, el administrador debe establecer la propiedad "Mensaje". Para establecer esta propiedad, se debe pulsar el icono de búsqueda situado a la derecha de la propiedad "Mensaje" y se abrirá el diálogo "Añadir mensaje de validación". Para obtener más detalles sobre el mensaje de validación personalizado para las validaciones de comparación, consulte la sección "Mensaje de validación personalizado" más adelante.

Nota: Cuando existen varias cláusulas esta propiedad es obligatoria.

La tabla siguiente describe las propiedades obligatorias para varias cláusulas en las validaciones de comparación.

Tabla 4. Propiedades de varias cláusulas
Propiedades de varias cláusulas Descripción
Conjunciones Controla si cualquier cláusula o todas las cláusulas de un grupo se validarán durante la ejecución.
  • Si se selecciona el botón de selección "Cualquier cláusula", si pasa una de las cláusulas en tiempo de ejecución, la validación completa pasará.
  • Si se selecciona el botón de selección "Todas las cláusulas", entonces todas las cláusulas deberán pasar para que pueda pasar la validación completa.

Validación de dependencias

La validación de dependencias se utiliza para imponer una dependencia de un tipo concreto entre dos atributos. En esta sección se describe su funcionalidad. Tenga en cuenta que el uso de atributos calculados no está soportado actualmente en las validaciones de dependencias.

Propiedad de la validación de dependencias Descripción
Primer atributo El atributo de datos, el atributo de dirección, el atributo de participante de caso relacionado o el atributo de comentarios del que depende el "segundo atributo".
Segundo atributo El atributo de datos, el atributo de dirección, el atributo de participante de caso relacionado o el atributo de comentarios del que depende el "primer atributo".
Dependencia La naturaleza de la dependencia. Puede ser uno de los siguientes valores:
  • Debe especificar el segundo atributo

    Cuando está seleccionado este valor, si el asistente social especifica un valor en el campo relacionado con el atributo al que apunta el "Primer atributo", entonces también debe especificar un valor en el campo relacionado con el atributo al que apunta el "Segundo atributo". Si se especifica algo en el primer campo pero no así en el segundo campo, la validación fallará.

  • No debe especificar el segundo atributo

    Cuando está seleccionado este valor, si el asistente social especifica un valor en el campo relacionado con el atributo al que apunta el "Primer atributo", entonces no debe especificar un valor en el campo relacionado con el atributo al que apunta el "Segundo atributo". Si se especifica algo en ambos campos, la validación fallará.

  • Al menos un atributo

    Cuando está seleccionado este valor, el asistente social debe especificar un valor en cualquiera o en los dos campos a los que apuntan el "Primer atributo" y el "Segundo atributo". Si los dos campos se dejan en blanco, esta validación fallará.

  • Sólo un atributo

    Cuando se selecciona este valor, el asistente social debe especificar un valor en uno u otro de los campos a los que apuntan el "Primer atributo" y el "Segundo atributo". Si se especifican los dos campos o no se especifica ningún campo, esta validación fallará.

Bidireccional La propiedad booleana que se aplica a las validaciones de dependencia que solo tienen una dependencia de tipo "Debe especificar el segundo atributo" y "No debe especificar el segundo atributo" (y está inhabilitada cuando se seleccionan los otros valores de dependencia). Seleccionar la propiedad "Bidireccional" tiene como efecto la adición de las palabras "...y viceversa" a las descripciones que se encuentran bajo la "Dependencia" mencionada anteriormente.

Por ejemplo, cuando se selecciona este valor para la dependencia "Debe especificar el segundo atributo", si el asistente social especifica un valor en el campo relacionado con el atributo al que apunta el "Primer atributo", también deberá especificar un valor en el campo relacionado con el atributo al que apunta el "Segundo atributo"; del mismo modo, si el asistente social especifica un valor en el campo relacionado con el atributo al que apunta el "Segundo atributo" también deberá especificar un valor en el campo relacionado con el atributo al que apunta el "Primer atributo".

La tabla siguiente describe algunas opciones adicionales disponibles en la validación de dependencia.

Tabla 5. Opciones adicionales de la validación de dependencia
Opciones Descripción
Literales Él valor de literal se puede especificar para el primer y segundo atributo. Como regla general, el valor literal debe ser del mismo tipo de datos que el del primer o segundo atributo seleccionado. Para especificar literales en un primer o segundo atributo, seleccione el recuadro de selección "Usar literal; el valor literal se puede introducir ( o seleccionar si el tipo de datos de Tabla de códigos, Booleano o Fecha) en el campo de literal origen y destino.
Nota: El valor literal solo se puede especificar para los atributos de datos.

Es posible que los administradores necesiten seleccionar un elemento de tabla de códigos como un valor literal cuando el tipo de datos de los atributos de origen es "tabla de códigos".

Cuando el tipo de datos del primer o segundo atributo es booleano, se pueden proporcionar los valores true o false.

En caso de que el tipo de datos sea Fecha, el valor de fecha se puede introducir o seleccionar a través de un selector de fecha.

El formato específico de entorno local se puede escribir para el valor literal de los tipos de datos numéricos como Entero, Flotante o Dinero (el símbolo de moneda también se puede escribir junto con el valor literal en el caso de atributo dinero.

ID de mensaje

Para establecer un mensaje de validación personalizado, el administrador debe establecer la propiedad "Mensaje". Para establecer esta propiedad, se debe pulsar el icono de búsqueda situado a la derecha de la propiedad "Mensaje" y se abrirá el diálogo "Añadir mensaje de validación". Para obtener más detalles sobre el mensaje de validación personalizado para las validaciones de dependencia, consulte la sección "Mensaje de validación personalizado" más adelante.

Validación de fecha de nacimiento

La validación de la fecha de nacimiento se utiliza para asegurarse de que la fecha de nacimiento del participante a la que apunta un atributo de participante de caso relacionado en la versión del tipo de pruebas dinámicas es anterior o igual a una fecha específica. Esto puede parecer una validación demasiado restrictiva pero en la práctica es una comparación que se realiza frecuentemente en el mantenimiento de pruebas de caso. En esta sección se describe su funcionalidad. Tenga en cuenta que el uso de atributos calculados no está soportado actualmente en las validaciones de comprobación.

Propiedad de la validación de fecha de nacimiento Descripción
Participante relacionado El participante de caso relacionados que se utilizará en la comparación de fecha de nacimiento. El menú desplegable de esta propiedad se rellenará con todos los atributos de participante de caso relacionado definidos actualmente para la versión del tipo de pruebas dinámicas. Durante la ejecución, la fecha de nacimiento de la persona a la que apunta el participante de caso relacionado se compara con la fecha que figura en la "Fecha de entrada" (Fecha de nacimiento del participante de caso <= Fecha de entrada); si la fecha de entrada es anterior a la fecha de validación fallará. Tenga en cuenta que solo los participantes de caso relacionados de tipo "Persona" son válidos para utilizarlos en las comparaciones, aunque el editor de pruebas no lo aplica.
Fecha de entrada El atributo de datos con un tipo de datos de "Fecha" en el que se ha de realizar la comparación.

Tenga en cuenta que del mismo modo que la función que se proporciona en la validación de comparación, en esta validación están disponibles los dos atributos del descriptor de pruebas evidenceReceivedDate y effectiveDateOfChange para realizar la comparación con la fecha de nacimiento de participante relacionado. Consulte Tipos de validación estándar para obtener más información.

Nota: Se añaden dos atributos adicionales (que no existen en los metadatos de la versión del tipo de pruebas dinámicas) a la lista del campo "Fecha de entrada":
  • evidenceReceivedDate

    Este atributo representa la fecha de recepción almacenada en el descriptor de pruebas de caso durante la ejecución. La infraestructura de pruebas dinámicas añadirá automáticamente este campo a cada página para crear y modificar pruebas de caso en relación con una versión del tipo de pruebas dinámicas, sin que sea necesario especificarlo en el modelo. Este campo representa la fecha en la que la agencia ha recibido una prueba para la organización y es una fecha que frecuentemente se utiliza en las validaciones de fecha de nacimiento de pruebas.

  • evidenceEffectiveDateOfChange

    Este atributo representa la fecha efectiva de recepción almacenada en el descriptor de pruebas de caso durante la ejecución. La infraestructura de pruebas dinámicas añadirá automáticamente este campo a cada página de modificación de pruebas de caso en relación con una versión del tipo de pruebas dinámicas, sin que sea necesario especificarlo en el modelo. Este campo representa la fecha efectiva del cambio para un registro de pruebas de caso (consulte la Guía de pruebas de Cúram para obtener más información sobre el significado de este campo) y también es una fecha que se utiliza frecuentemente en las validaciones de fecha de nacimiento de pruebas.

La tabla siguiente describe algunas opciones adicionales disponibles en la validación de fecha de nacimiento.

Tabla 6. Opciones adicionales de la validación de fecha de nacimiento
Opciones Descripción
ID de mensaje

Para establecer un mensaje de validación personalizado, el administrador debe establecer la propiedad "Mensaje". Para establecer esta propiedad, se debe pulsar el icono de búsqueda situado a la derecha de la propiedad "Mensaje" y se abrirá el diálogo "Añadir mensaje de validación". Para obtener más detalles sobre el mensaje de validación personalizado para las validaciones de fecha de nacimiento, consulte la sección "Mensaje de validación personalizado" más adelante.

Validación de duplicados

La validación de duplicados se utiliza para impedir que los registros de caso de prueba que se consideran "duplicados' (según los criterios especificados) que se registren en el sistema.

Tenga en cuenta que la naturaleza de la operación de esta validación es ligeramente diferente de la de otras validaciones, ya que la selección del conjunto de registros sobre el que se realiza la validación de duplicados puede variar.

Si la versión del tipo de pruebas dinámicas tiene uno o varios tipos de pruebas dinámicas padre, durante la ejecución de la validación de duplicados solo se buscará en los registros de nivel inferior de dichos padres(por ejemplo, registros de hermanos del registro actual) para identificar los duplicados.

Si, no obstante, la versión del tipo de pruebas dinámicas no tiene relaciones padre, entonces durante la ejecución la validación de duplicados buscará en todos los registros del tipo de pruebas dinámicas de esta versión del tipo de pruebas dinámicas para identificar los duplicados.

En esta sección se describe adicionalmente las funciones de la validación de duplicados. Tenga en cuenta también que el uso de atributos calculados en las validaciones de duplicados no está soportado actualmente.

Propiedad de la validación de duplicados Descripción

Utilizar rango de fechas, Fecha de inicio, Fecha de finalización

Cuando se selecciona "Utilizar rango de fechas", aparecen dos propiedades obligatorias de la validación de duplicados en el diálogo "Crear validación": Fecha de inicio y Fecha de finalización. Estas propiedades deben apuntar a atributos de datos con tipos de datos de fecha.

Durante la ejecución, la validación de duplicados buscará en el conjunto de selecciones (consulte la visión general anterior para obtener detalles acerca de cómo se identifica el conjunto de selecciones) los registros que tengan valores en los atributos indicados por la fecha de inicio y la fecha de finalización que se solapen con los valores proporcionados en las pantallas de crear o modificar pruebas de caso. Si se identifican estos registros, la validación fallará.

Por ejemplo, si el valor proporcionado en el campo de la pantalla de pruebas de caso para el atributo al que apunta la propiedad fecha de inicio es anterior a cualquiera de los registros del conjunto de selecciones, entonces la validación fallará ya que se ha identificado un duplicado.

Otros atributos a comprobar

Una lista opcional de Otros atributos a comprobar (conjuntamente con cualquier rango de fechas proporcionado) para ver si son iguales y así identificar duplicados. Si en el conjunto de selecciones existen registros con valores de atributos iguales a los valores de los atributos de la lista "Otros atributos a comprobar" proporcionados en las pantallas para crear o modificar pruebas de caso, entonces la validación fallará.

Nota: Si se proporcionan varios atributos en la lista, se pueden comprobar de forma individual o conjunta para ver si existen duplicados.
  • Para comprobar los atributos individualmente, seleccione el botón "Comprobar atributo individualmente".
  • Para comprobar los atributos conjuntamente (por ejemplo, para comprobar que todos los atributos sean exclusivos cuando se toman conjuntamente de la lista de selección), seleccione el botón de selección "Comprobar los atributos conjuntamente".

La tabla siguiente describe algunas opciones adicionales disponibles en la validación de duplicados.

Tabla 7. Opciones adicionales de la validación de duplicados
Opciones Descripción
ID de mensaje

El administrador puede establecer un mensaje de validación personalizado para los dos atributos de rango de fechas y para otros atributos. Para establecer un mensaje de validación personalizado, el administrador debe establecer la propiedad "Mensaje". Para establecer esta propiedad, se debe pulsar el icono de búsqueda situado a la derecha de la propiedad "Mensaje" y se abrirá el diálogo "Añadir mensaje de validación". Para obtener más detalles sobre el mensaje de validación personalizado para las validaciones de duplicados, consulte la sección "Mensaje de validación personalizado" más adelante.

Mensaje de validación personalizado

Para establecer un mensaje de validación personalizado para un tipo de validación, se deben especificar las siguientes propiedades:

Tabla 8. Propiedades de los mensajes de validación personalizados
Propiedades de la correlación de mensajes personalizados Descripción
Mensaje El texto que se utilizará para el mensaje de validación. Este mensaje se puede parametrizar con nombres de atributos, marcadores que se especifican para los mismos en el mensaje de validación con el formato siguiente: llave de apertura, número de parámetro, llave de cierre. Por ejemplo, {0}. Si durante la ejecución falla una validación, el parámetro especificado en la lista "Parámetros de mensaje" siguiente se sustituye en el mensaje para crear el mensaje de validación que se visualizará. Consulte la propiedad "Parámetros de mensaje" para obtener más información sobre la parametrización de mensajes.
ID de mensaje Serie obligatoria que se utilizará como la clave del valor de la propiedad del mensaje; puede ser cualquier identificador válido (por ejemplo, 'My EvidenceTypeVersion.ComparisonValidation.Message').
Parámetros de mensaje

Una lista ordenada de datos de atributos de datos, atributos de participante de caso relacionado, atributos de dirección, atributos de comentarios y atributos calculados que se utilizarán en el mensaje.

Para las validaciones de comparación o las validaciones de fecha de nacimiento, se añaden a la lista dos atributos adicionales (que no existen en los metadatos de la versión del tipo de pruebas dinámicas), principalmente evidenceReceivedDate y evidenceEffectiveDateOfChange. Para obtener más información acerca de estos dos atributos adicionales, consulte la sección sobre validación de comparación o validación de fecha de nacimiento.

Como se ha mencionado anteriormente, los marcadores se colocan en el mensaje para indicar que durante la ejecución debe sustituirse un valor de atributo en el mensaje y debe tener el formato siguiente: {0}, {1}, etc.

Por ejemplo, si la propiedad "Mensaje" se establece de este modo: {0} no debe ser igual a true y {1} no debe ser igual a SX2, y se establecen los parámetros del mensaje de este modo: isPregnant, gender. Durante la ejecución si un usuario crea un registro de pruebas y falla la validación de comparación, entonces el mensaje que se muestra al usuario se visualizará de un modo similar al siguiente: 'isPregnant' debe ser igual a 'true' y 'gender' debe ser igual a 'Female'.