> ## Documentation Index
> Fetch the complete documentation index at: https://docs.abbyy.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Optimice la estructura y la búsqueda de FlexiLayout con elementos de grupo
> Agrupe elementos relacionados para reducir las combinaciones de hipótesis y acelerar el emparejamiento de FlexiLayout, ilustrado paso a paso en el proyecto GroupSample.fsp.
Usar elementos **de grupo** para buscar objetos es lo más eficiente, porque agrupar elementos reduce el número de hipótesis de un elemento y acelera la búsqueda de la hipótesis resultante para todo el FlexiLayout. Además, si la agrupación de los elementos refleja la lógica del documento, ayuda a optimizar la estructura del FlexiLayout y a hacerla más explícita.
Agrupar varios elementos en un único elemento de grupo permite que FlexiLayout Studio trate este conjunto de elementos como un todo con su propia hipótesis (compuesta por hipótesis individuales de los elementos del grupo).
El análisis de las hipótesis y de sus elementos tiene lugar dentro del elemento de grupo, y solo el número de mejores hipótesis especificado por el usuario (1 de forma predeterminada) se usa en la búsqueda posterior de otros elementos.
Todo el árbol de elementos puede considerarse un elemento de grupo, cuya mejor hipótesis es el resultado del emparejamiento del FlexiLayout.
## El proyecto de ejemplo GroupSample.fsp
El proyecto `GroupSample.fsp` (carpeta `%public%\ABBYY\FlexiCapture\12.0\Samples\FLS\Tips and Tricks\Group\Project1`) muestra cómo se pueden usar los elementos de grupo. El objetivo es detectar los campos con el número de factura, la fecha de la factura y el importe de la factura en la imagen.
## Agrupar los campos de facturas en InvoiceRequisiteGroup
Como muestra la imagen (y como suele ocurrir en los documentos financieros), el número y la fecha del documento son campos contiguos. Aunque la disposición de los campos en otro documento sea diferente, seguirán estando cerca entre sí.
Además, están relacionados por la lógica del documento, ya que describen determinados datos bancarios y forman un bloque lógico. Para que la estructura del FlexiLayout sea más explícita, el proyecto los agrupa en un elemento de grupo llamado **InvoiceRequisiteGroup**.
Antes de agrupar los elementos, se creó un elemento identificador especial. (Los elementos identificadores se describen en detalle en [Identificación y procesamiento de FlexiLayout en ABBYY FlexiCapture](/es/flexi-capture/fls/dif/form-reader-batch).) Este elemento se creó únicamente para ilustrar la "ramificación" del árbol de hipótesis provocada por la presencia o ausencia de elementos de grupo en él.
Suponga que todos los elementos del árbol, excepto el elemento identificador, son opcionales y que sus hipótesis nulas tienen la calidad predeterminada de 0.97.
El primer elemento del grupo es un elemento de tipo **texto estático**, llamado **InvoiceNumHeader**, que describe las restricciones de búsqueda del nombre del campo "Número de factura". La cadena "Invoice" se especifica como el valor de este elemento.
A partir del análisis de las imágenes disponibles, el número de factura se busca a la derecha del nombre con ayuda de un elemento llamado **InvoiceNum**.
De forma similar, debajo de la línea con el número de factura, el proyecto contiene un elemento para el campo de fecha, llamado **InvoiceDateHeader**. Para buscar la fecha propiamente dicha, el proyecto utiliza el grupo **DateGroup** con los siguientes subelementos: **InvoiceDate** y **InvoiceDateAsString**. Para obtener más información, consulte [Búsqueda de fechas después de un reconocimiento de alta o baja calidad](/es/flexi-capture/fls/tips-tricks/date2).
Para detectar el campo con el importe de la factura, el proyecto utiliza dos elementos: un elemento **texto estático** llamado **TotalSumHeader** (su valor "**Totalsum(EUR):**" se escribe sin espacios) y un elemento **cadena de caracteres** llamado **TotalSum**, que busca directamente el importe.
La configuración de los elementos no se describe aquí. Puede consultarla directamente en el proyecto.
La cadena "Invoice", especificada como valor del elemento **InvoiceNumHeader**, puede aparecer tres veces en las imágenes de prueba: como nombre del campo "Número de factura", como subcadena del nombre del campo "Fecha de la factura" y en la parte inferior de la factura, como subcadena en las condiciones de la factura: "Current **invoice** is…".
Tenga en cuenta también que el nombre "INVOICE" (que el elemento **InvoiceNumHeader** debe detectar) tiene mucho ruido, lo que provocó un error en el nombre. En las otras líneas, la cadena "Invoice" es clara, y la calidad de las hipótesis correspondientes debe ser mayor que la de la hipótesis del nombre.
## Cómo el grupo selecciona la mejor cadena de hipótesis
Ahora intente emparejar el FlexiLayout con las imágenes de prueba del lote.
Una vez que haya iniciado el procedimiento de emparejamiento de FlexiLayout seleccionando el comando **Match**, verá que el árbol de hipótesis consta de una sola cadena.
Haga doble clic en **InvoiceRequisiteGroup** para abrir su cuadro de diálogo de propiedades, donde podremos ver qué hipótesis se generaron para sus subelementos, qué cadena del Grupo resultó ser la mejor y por qué.
Hay tres hipótesis para el elemento **InvoiceNumHeader**, igual que el número de cadenas "invoice" detectadas.
La calidad de la hipótesis que nos interesa es inferior (aproximadamente 0.99), porque su área en la imagen tiene ruido y FlexiLayout Studio solo pudo reconocer "INVOIC" en lugar de "INVOICE". La calidad de las otras dos hipótesis, en cambio, es máxima (**calidad de la cadena** = 1).
Las propiedades del elemento **InvoiceNum** especifican que el número de factura puede tener cualquier cantidad de dígitos y debe buscarse a la derecha del nombre. En esta imagen, estas condiciones se cumplen en los tres casos, lo que permitió a FlexiLayout Studio seguir creando una cadena de hipótesis para cada una de las hipótesis del nombre del campo "Número de factura".
Aunque la Pre-search quality de cada una de las hipótesis del elemento **InvoiceNum** es 1, la cadena correcta sigue siendo la peor. Esto ocurre porque la calidad de la cadena se evalúa multiplicando las calidades de todas las hipótesis que forman la cadena.
Para el nombre obligatorio, esta calidad es de aproximadamente 0.99. Si el Grupo no tuviera ningún otro elemento, la elección final en esta etapa sería incorrecta.
**Post-search relations** no se especifican para ninguno de los elementos, por lo que para cada elemento Post-search quality = 1, y puede juzgar la calidad de cualquier hipótesis por su Pre-search quality.
## Por qué la cadena correcta gana a pesar de una calidad inicial inferior
Como señalamos antes, en las propiedades del elemento **InvoiceDateHeader** especificamos que debía buscarse debajo de la línea con el número de factura. Sin embargo, ninguna de las cadenas con la mejor calidad (calidad de la cadena **= 1**) produjo una hipótesis para el nombre del campo de fecha. En consecuencia, se formaron hipótesis nulas en estas cadenas para el elemento **InvoiceDateHeader**. Como no cambiamos la calidad predeterminada de una hipótesis nula, la calidad de la cadena resultante de las cadenas correspondientes bajó a 0.97. Al mismo tiempo, el elemento correspondiente al nombre del campo de fecha se encontró para la cadena que tenía la calidad más baja. La calidad de su hipótesis es de aproximadamente 0.993. Es inferior a 1 porque la imagen en el área del nombre tiene ruido, lo que provocó un error de reconocimiento y una coincidencia incompleta entre el texto reconocido y el valor especificado en las propiedades del elemento **InvoiceDateHeader**. Como resultado, la hipótesis encontrada fue penalizada y su calidad final es de aproximadamente 0.98 (el resultado de multiplicar 0.99 por 0.993). No obstante, la calidad final de esta hipótesis es superior a la de las demás (0.97), por lo que en esta etapa esta cadena es la mejor.
Para detectar el campo de fecha, el proyecto utiliza el elemento de grupo **DateGroup**, que especifica que al menos uno de los elementos no puede encontrarse si el otro se ha encontrado (se utilizó la función `Dontfind`).
Como resultado de las características del diseño del documento y de las propiedades especificadas para el elemento **InvoiceDateAsString** (su alfabeto permite dígitos), FlexiLayout Studio logró encontrar el campo de fecha para todas las cadenas, aunque en realidad solo una de las tres hipótesis es correcta.
Puesto que en cada grupo se ha encontrado uno de los elementos mientras que el otro no, la calidad final de la cadena en cada uno de los grupos **DateGroup** es 0.97 (1 multiplicado por 0.97, la calidad predeterminada de la hipótesis nula).
En este ejemplo, la calidad final de las cadenas de **DateGroup** no afectará al "equilibrio" entre las hipótesis en el momento de detectar el elemento **InvoiceDateHeader**; es decir, la calidad de cada una de las cadenas se seguirá multiplicando por 0.97.
Al final, FlexiLayout Studio generó una sola hipótesis para el elemento de grupo **InvoiceRequisiteGroup**, que corresponde a la mejor cadena del grupo. Su calidad es de aproximadamente 0.953; es decir, el "enfoque de grupo" ayudó a que ganara la hipótesis correcta, aunque su calidad inicial fuera inferior.
## El árbol de hipótesis sin elementos de grupo
Para ver cómo sería el árbol de hipótesis sin elementos de grupo en FlexiLayout, abra el proyecto `GroupSample.fsp` en la carpeta `Group\Project2`. El árbol se muestra en la figura siguiente.
Como se aprecia claramente en la figura, después de detectar el elemento **FormID**, el árbol de hipótesis se ramificó porque se generan varias hipótesis para el elemento **InvoiceNumHeader**. Como resultado, FlexiLayout Studio tiene que comparar los valores de calidad de cada una de las cadenas, comenzando cada vez por su primer elemento y descendiendo hasta el último.
Además, para cualquier documento con un diseño más complejo que el de este ejemplo, un FlexiLayout sin elementos de grupo producirá un árbol de hipótesis con demasiadas ramas, lo que dificultará el emparejamiento de FlexiLayout.
Evite colocar todos los elementos buscados en un único grupo raíz. Esto solo es adecuado para FlexiLayouts muy simples con menos de 10 elementos, algo muy poco frecuente en tareas reales.
Un aumento del número de elementos en el grupo raíz provoca un crecimiento masivo del número de hipótesis, hasta alcanzar el límite de 10.000 o agotar toda la memoria asignada al árbol de hipótesis. En cualquiera de los dos casos, el emparejamiento del FlexiLayout puede fallar.
En tareas reales, por lo general no es necesario explorar todas las combinaciones posibles de cada hipótesis de un elemento con cada hipótesis de todos los demás elementos, ya que la mayoría de los elementos pueden detectarse independientemente unos de otros.
Por eso, debe agrupar los elementos en elementos de grupo lo más pequeños posible, para reducir el número de combinaciones que deben analizarse y acelerar la búsqueda.
Además, dado que la calidad de la cadena final se calcula multiplicando los valores de calidad de todas las hipótesis de esa cadena, el volumen de cálculos puede ser mucho mayor en un árbol con demasiadas ramas, lo que hará que el emparejamiento de FlexiLayout sea más lento.