# Control de calidad y secuencia

Cuando GBDS recibe una nueva transacción, se realiza una verificación de control de calidad y secuencia. Esta verificación tiene el propósito de evitar que transacciones malas sean insertadas en la base de datos.

Cualquier transacción rechazada por el control de calidad y secuencia se envía al MIR para revisión manual.

{% hint style="info" %}
Vea el [manual del MIR (Manual Image Review)](/gbs/es/aplicaciones/mirweb.md) para más información sobre cómo tratar las transacciones enviadas a él.
{% endhint %}

## Pasos de Verificación

### Control de Calidad

El primer paso cuando se recibe una nueva transacción es realizar una verificación de calidad por GBDS de cada template de biometría enviado.

Si la calidad de cualquier template no alcanza el umbral configurado, toda la transacción se envía al MIR para verificación manual.

{% hint style="info" %}
Vea el [Manual de Configuración de GBDS](/gbs/es/configuracion-de-gbds/gbds4conf.md) o contacte al equipo de soporte de Griaule para más información.
{% endhint %}

Cualquier problema identificado por este paso de verificación será devuelto como `"QualityIssue"` por la API.

### Verificación de Duplicidad

En este paso, GBDS compara cada huella dactilar con las demás para verificar duplicidad.

Si se identifica algún duplicado, la transacción se envía al MIR para verificación manual.

Cualquier problema identificado en este paso será devuelto como `"DuplicationIssue"` por la API.

### Verificación de Secuencia

Para realizar este paso, GBDS requiere imágenes de huellas colocadas capturadas simultáneamente (*4-slap fingerprint*) (índices 940 y 941)

GBDS intentará segmentar esas imágenes y extraer un número predeterminado de biometrías. Luego, comparará las imágenes segmentadas con las huellas capturadas individualmente (usualmente, capturas rodadas).

{% hint style="info" %}
En casos de amputación o discapacidad temporal, la imagen puede contener menos de cuatro dedos.
{% endhint %}

Si cualquier comparación identifica una no coincidencia, GBDS intentará corregir el índice de los dedos que no coinciden y realizará una autocorrección.

Si existe cualquier problema identificado que GBDS no pueda autocorregir, o si el número de autocorrecciones es mayor que el máximo configurado, no se realizará ninguna corrección y la transacción se enviará al MIR.

{% hint style="info" %}
Vea el [manual de configuración de GBDS](/gbs/es/configuracion-de-gbds/gbds4conf.md) o contacte al equipo de soporte de Griaule para más información.
{% endhint %}

Cualquier problema identificado en este paso de verificación será devuelto como `"SequenceControlIssue"` por la API.

El flujo de comparación para la verificación de secuencia será el siguiente:

#### Flujo de Trabajo de Comparación

Las imágenes individuales de las huellas dactilares (rodadas o planas), con índices entre 0 y 3, se compararán contra las imágenes segmentadas del índice 940.

Luego, las imágenes individuales de huellas de los índices entre 6 y 9 se compararán contra las imágenes segmentadas del índice 941.

Los índices para las imágenes individuales de huellas dactilares son:

| Índice | Huella            | Índice | Huella          |
| ------ | ----------------- | ------ | --------------- |
| 0      | Meñique Izquierdo | 5      | Pulgar Derecho  |
| 1      | Anular Izquierdo  | 6      | Índice Derecho  |
| 2      | Medio Izquierdo   | 7      | Medio Derecho   |
| 3      | Índice Izquierdo  | 8      | Anular Derecho  |
| 4      | Pulgar Izquierdo  | 9      | Meñique Derecho |

## Tratando Anomalías

Para obtener más información sobre el MIR y los procesos de tratamiento de anomalías, vea el manual del MIR, como se mencionó arriba.

En esta sección, se detallarán los procesos de análisis de calidad realizados por el servidor, desde el momento en que GBDS recibe la decisión proporcionada por el MIR.

### Transacción Aprobada Sin Cambios

Dada esta decisión, GBDS mantendrá la transacción original sin cambios y continuará el proceso de registro. El GUID (Global Unique IDentifier) de la transacción (TGUID) permanecerá igual para ambas operaciones (`QUALITY_ANALYSIS` y `ENROLL`).

El flujo de notificación será el siguiente:

#### Análisis de Calidad - Aprobado

La primera notificación contendrá el estado `"APPROVED"` para la operación de `"QUALITY_ANALYSIS"`.

```json
{
	"operation": "QUALITY_ANALYSIS",
	"tguid": "<tguid>",
	"status": "APPROVED"
}
```

#### Registro - Registrado

La segunda notificación contendrá el estado `"ENROLLED"` para la siguiente operación de `"ENROLL"`.

```json
{
	"operation": "ENROLL",
	"tguid": "<tguid>",
	"status": "ENROLLED"
}
```

### Transacción Aprobada con Cambios

Dada esta decisión, GBDS mantendrá los cambios realizados por el examinador (imágenes eliminadas o editadas) y generará un nuevo TGUID para el registro.

El flujo de notificación para esta decisión es similar al generado por la "*Transacción Aprobada sin Cambios*", agregando el nuevo TGUID:

#### Análisis de Calidad - Aprobado

La primera notificación contendrá el estado `"APPROVED"` para la operación de `"QUALITY_ANALYSIS"` e incluirá el nuevo campo `"newTransactionGUID"` denotando que la transacción fue aceptada con cambios y apuntando al nuevo TGUID.

```json
{
	"newTransactionGUID": "<new_tguid>",
	"operation": "QUALITY_ANALYSIS",
	"tguid": "<original_tguid>",
	"status": "APPROVED"
}
```

#### Registro - Registrado

La segunda notificación contendrá el estado `"ENROLLED"` para la siguiente operación de `"ENROLL"`.

{% hint style="info" %}
La operación de `ENROLL` se realizará para la transacción modificada, por lo que el TGUID mencionado será el nuevo que fue generado por la operación de `QUALITY_ANALYSIS`.
{% endhint %}

```json
{
	"operation": "ENROLL",
	"tguid": "<new_tguid>",
	"status": "ENROLLED"
}
```

### Transacción Rechazada

Dada la decisión, GBDS no continuará el proceso de registro y descartará toda la transacción. El TGUID permanecerá igual.

{% hint style="info" %}
El historial de la transacción se mantendrá, pero el perfil no será insertado en la base de datos como un registro de persona activa.
{% endhint %}

El flujo de notificación será el siguiente:

#### Análisis de Calidad - Rechazado

La primera notificación contendrá el estado `"REJECTED"` por la operación de `"QUALITY_ANALYSIS"`.

```json
{
	"operation": "QUALITY_ANALYSIS",
	"tguid": "<tguid>",
	"status": "REJECTED"
}
```

#### Registro - Fallo

El resultado de la operación de `QUALITY_ANALYSIS` será seguido de una notificación de registro apuntando al estado `"FAILED"` para la operación de `"ENROLL"`.

```json
{
	"operation": "ENROLL",
	"tguid": "tguid",
	"status": "FAILED"
}
```


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.griaule.com/gbs/es/integracion-de-gbds/qualitycontrol.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
