Cómo registrar errores por fila sin rechazar todo el documento

Distingue fichero ilegible y dato inválido

Una codificación desconocida, cabeceras ausentes o separadores incoherentes pueden impedir saber qué significa cada columna. Eso exige revisar el documento antes de importar. Un código postal inválido en una fila puede apartarse si las demás son independientes. No anuncies «documento aceptado» sin indicar qué se aplicó. Define cuándo el error invalida fila, grupo relacionado o fichero entero, y muestra esa decisión en el informe.

Devuelve errores que se puedan corregir

Incluye referencia de fichero y versión, hoja, fila, clave de negocio, campo, código de error y explicación comprensible. Muestra el valor rechazado solo a quien deba verlo y evita incluir información sensible innecesaria en mensajes generales. Conserva el original; una corrección genera una versión o registro relacionado. Si varias reglas fallan en la misma fila, agrúpalas para que el usuario no tenga que repetir una carga por cada campo.

Aplica aislamiento conforme al destino

Una tabla de preparación permite validar antes de escribir en las entidades finales. Si utilizas PostgreSQL, los puntos de guardado permiten retroceder parte de una transacción, pero no deshacen efectos en APIs externas. Revisa cómo se comporta tu importador ante un error: no presupongas que continuará porque la base de datos ofrece esa capacidad. Si cabecera y líneas deben ser coherentes, puede ser necesario retener el conjunto relacionado en lugar de aceptar líneas huérfanas.

Distingue corregir datos de cambiar una regla

Si una fila cumple la información original pero el importador la rechaza por una validación mal diseñada, no pidas al usuario que invente un valor para pasarla. Registra un cambio de regla y evalúa qué filas anteriores quedan afectadas. Esa revisión puede incluir registros aceptados de forma incorrecta, además de los que estaban rechazados.

Cuando la corrección sí corresponde al origen, devuelve una referencia que permita actualizar la fila adecuada sin compartir todo el fichero con personas que solo necesitan resolver un campo. Comprueba después que el nuevo intento conserva la relación con el rechazo y termina en un resultado confirmado. El informe debe mostrar resueltas y todavía pendientes; sustituir el fichero de errores por una versión vacía borraría la evidencia necesaria para explicar cómo se cerró la carga.

Facilita un reenvío limitado y trazable

Ofrece una lista de rechazadas con sus referencias, y relaciona cada corrección con la aparición original. No reimportes todo el documento sin reconocer las filas ya aplicadas. Prueba una fila inválida entre dos válidas, una relación ausente y un error de formato global. Verifica qué llega al destino y que el informe suma aceptadas, rechazadas y pendientes sin perder registros. El cierre debe explicar el resultado parcial y quién tiene cada corrección, no limitarse a descargar un log técnico.

Fuentes y documentación

• PostgreSQL: SAVEPOINT — Permite retroceder una parte dentro de una transacción; no revierte efectos externos.
• PostgreSQL: restricciones — Restricciones de unicidad, nulidad y referencias como controles de integridad.