Menú

Validación por lotes: flujo para listas grandes

Comprobar muchos números a la vez no es repetir la comprobación individual en bucle. Esta guía describe el flujo por etapas: limpiar, repartir por esquema, clasificar los resultados y generar un informe con la línea y el valor original.

Publicado el

  • lotes
  • informes
  • limpieza de datos

Cuando la lista de números deja de caber en un formulario, el problema cambia de naturaleza. Ya no se trata de dar una respuesta rápida a una persona, sino de dejar constancia de qué pasó con cada fila, porque nadie va a revisar los resultados a mano y el informe es la única prueba de lo ocurrido. La validación por lotes es, por tanto, un ejercicio de trazabilidad tanto como de cálculo. Este artículo describe el flujo por etapas que evita los errores clásicos y produce un resultado que se puede accionar.

¿En qué se diferencia la validación por lotes de comprobar un solo número?

En tres cosas, y las tres obligan a cambiar el diseño.

  • No hay una persona esperando delante. La comprobación puede tardar, pero no puede quedarse a medias sin dejar rastro de dónde se detuvo.
  • El resultado ya no es un veredicto, sino una clasificación. Cada fila recibe su categoría y hay que poder contar cuántas hay de cada tipo.
  • Los datos llegan sucios de formas que un formulario impide. Aparecen filas vacías, columnas desplazadas, separadores mezclados y el mismo número repetido varias veces.

Un flujo que se limite a recorrer la lista y marcar las filas correctas perderá la información más valiosa: cuáles no se pudieron interpretar, cuáles eran duplicados y cuáles no tenían ningún esquema conocido.

Primero limpiar, después comprobar

El orden de las etapas no es negociable. La limpieza va primero y se aplica a toda la lista antes de que ninguna fila se compruebe.

La limpieza incluye quitar separadores, unificar mayúsculas y minúsculas, recortar espacios sobrantes y descartar las filas que han llegado vacías o con un número de columnas equivocado. Cada una de esas operaciones puede hacer fracasar la comprobación si se ejecuta después, y el fallo será atribuido al número cuando el problema estaba en la fila.

Conviene además conservar dos versiones de cada valor: la original, tal como llegó, y la normalizada, que es la que se va a comprobar. La primera hará falta en el informe y la segunda en el cálculo. La guía sobre cómo funciona la validación de números desarrolla por qué la normalización es un paso previo y no una mejora opcional.

¿En cuántas categorías hay que clasificar los resultados?

Al menos en cuatro, y conviene añadir una quinta cuando la lista lo permite.

Categoría Significado Acción habitual
Válido El control se recalculó y coincide Se puede dar por buena
No válido La forma encaja pero el control falla Se revisa la fila original
Solo formato Se confirmó la forma, sin control disponible Se acepta con reservas
Sin regla No hay esquema conocido para esa entrada Se envía a revisión manual
Duplicado El mismo número aparece más de una vez Se decide cuál conservar

Separar duplicados de errores es importante, porque son problemas distintos y se resuelven de forma distinta. Un informe que los mezcle obligará a alguien a revisar a mano cientos de filas que solo estaban repetidas.

La categoría sin regla merece un cuidado especial. No significa que el número sea falso, significa que el sistema no tiene ninguna regla para interpretarlo. Redactarla como un error grave lleva a descartar datos que quizá sean perfectamente correctos.

Duplicados, valores vacíos y archivos muy grandes

Los tres problemas aparecen en casi todos los lotes reales y ninguno se resuelve bien sobre la marcha.

Los duplicados se detectan comparando la forma normalizada y no la original, porque el mismo número puede llegar escrito de dos maneras distintas. Si se compara el texto tal cual, los duplicados pasarán desapercibidos.

Los valores vacíos no deben tratarse como errores de formato. Una celda en blanco es una ausencia de dato, y confundirla con un número mal escrito distorsiona las estadísticas del informe y las decisiones que se tomen después.

En cuanto al tamaño, la estrategia razonable es procesar por bloques y guardar el estado de cada bloque a medida que termina. Así, si algo falla a mitad de camino, se puede retomar sin repetir lo ya hecho ni perder la trazabilidad de las filas procesadas.

Cómo redactar un informe que se pueda accionar

Un informe útil responde a tres preguntas: qué fila, qué valor y qué pasó. Todo lo demás es secundario.

  • Número de línea o posición original, para poder volver al punto exacto del archivo.
  • El valor tal como llegó, sin normalizar, porque es lo que la persona reconocerá.
  • La categoría asignada, con el mismo vocabulario que usa el resto del sistema.
  • El esquema aplicado, cuando se haya podido determinar, y nada si no se pudo.
  • Un resumen con el recuento por categorías, que es lo que se lee primero.

Conviene resistir la tentación de añadir columnas derivadas que nadie pidió. Cada columna extra alarga el informe y dificulta encontrar lo importante, que casi siempre es una lista corta de filas a revisar.

Si el mismo lote se va a repetir con correcciones, el informe debería poder compararse con el anterior. Eso exige que las categorías sean estables y que el orden de las filas no cambie entre ejecuciones.

Para quien programa: bloques, concurrencia e idempotencia

Al implementar el flujo aparecen decisiones que conviene fijar desde el principio.

  • Procesa por bloques y escribe el resultado parcial antes de pasar al siguiente.
  • Haz que repetir el proceso sobre el mismo lote produzca el mismo resultado, para poder relanzarlo sin miedo.
  • No compartas estado mutable entre bloques; cada uno debería poder ejecutarse por separado.
  • Separa el cálculo de la escritura del informe, de modo que se pueda cambiar el formato sin tocar la comprobación.
  • Registra la versión de las reglas usadas, porque un informe antiguo se interpreta con las reglas de su fecha.

Cuando el lote se apoya en un servicio remoto para la parte que no se puede calcular en local, aparecen los problemas de límites de uso y tiempos de espera descritos en la guía sobre validación en la API. Esa combinación es la que más cuesta dejar idempotente.

Siguientes pasos

Prepara un archivo pequeño, de unas pocas filas inventadas, que contenga a propósito un duplicado, una línea vacía y una entrada sin esquema conocido. Pásalo por tu flujo y comprueba que el informe distingue los tres casos en lugar de agruparlos como errores.

Después, pasa por el validador de números las mismas cadenas una a una y compara la categoría que devuelve con la que había asignado tu proceso.

Sobre los datos de esta guía: las listas y valores mencionados son ejemplos de demostración pensados para describir el flujo de trabajo; no proceden de ningún archivo real ni contienen información de personas o entidades.

Seguir leyendo

Artículos sobre Validador de DNI