2026-10-29

Cuándo una importación debe parar en vez de arreglar el dato

Una importación que da todo por bueno parece lo que quieres. Es la que más daño hace cuando el fichero trae algo dudoso, porque lo corrige sin avisar y nadie se entera. La que merece confianza sabe qué puede convertir sin perder nada y cuándo debe parar y enseñar la fila a una persona.

Aquí van tres filas de un fichero de pedidos inventado donde lo prudente es parar. Ningún dato viene de un cliente. No es una auditoría ni una recomendación de cambiar de programa. Si quieres la lista de los fallos más habituales, está en Por qué un Excel correcto a simple vista rompe una importación. Este artículo va de lo que hacer cuando los encuentras.

1. Un pedido que sale dos veces no tiene por qué estar duplicado

En el fichero de ejemplo, el pedido D-102 aparece en dos filas. La primera es la línea 1 con el producto 0007. La segunda es la línea 2 con el producto 0012. Si borras repetidos por número de pedido, pierdes la segunda línea y el pedido queda incompleto.

Antes de borrar nada hay que saber qué identifica una fila. En el ejemplo lo hemos decidido nosotros: el número de pedido junto con el número de línea. El estándar CSV on the Web de la W3C lo contempla: su propiedad de clave primaria puede apuntar a una columna o a varias, y quien valida debe comprobar que cada fila tiene una combinación única de esas columnas. Que sean dos columnas es una elección de este ejemplo, no una regla universal.

Con esa clave quedan dos casos que no se resuelven solos.

• D-101 aparece dos veces, con la misma línea y los mismos datos. Puede ser un doble clic al exportar o dos ventas iguales. El fichero no lo dice.
• D-103 aparece dos veces con la misma línea y distinto importe, 10,00 y 12,00 euros. Elegir uno sería inventar.

La regla que usamos aquí es retener todo el grupo repetido, también el idéntico. La W3C no manda conservar la primera fila y borrar la segunda, así que esa política es nuestra y se puede cambiar. Lo que no se puede hacer es borrar sin saber cuál representa la venta, y para saberlo hay que mirar de dónde sale el fichero.

2. El código 0007 y el 7 no son el mismo código

Un código de producto puede parecer un número y no serlo. En el ejemplo, 0007, 0000 y 7000 son tres códigos distintos y los tres pasan. El pedido Z-102 trae solo 7. No cumple el formato de cuatro caracteres que hemos fijado, así que se retiene.

Lo tentador es añadir ceros hasta completar cuatro. No lo hacemos, porque de un 7 no se puede saber si era 0007, 007 o simplemente 7. La ayuda de Microsoft explica de dónde viene el problema: Excel quita por defecto los ceros iniciales de un texto numérico y lo convierte en número, y para conservarlos hay que importar esa columna como texto. También avisa de que dar formato a la celda después no restaura los ceros que ya se habían eliminado.

Si los ceros siguen en el CSV, conservarlos es una cuestión de cómo se lee el fichero. Si solo queda un 7, la respuesta está en el origen, no en la herramienta. No hemos probado Excel para este artículo, solo contamos lo que dice su ayuda.

3. Un total que falta un céntimo no se corrige

El pedido T-102 trae dos unidades a 19,95 euros y un total de 39,89. Dos por 19,95 son 39,90. Falta un céntimo.

La herramienta puede enseñar la diferencia, que aquí es de menos 0,01, y no debe cambiar el total. Puede faltar un descuento, puede estar mal el precio o puede estar mal el total, y de las tres posibilidades el fichero no dice cuál es la buena. La cuenta se hace en decimal y no en coma flotante. La documentación de Python lo explica con un ejemplo: en coma flotante binaria 1,1 más 2,2 da 3,3000000000000003, y por eso el decimal se prefiere en contabilidad. Cuadrar los céntimos es el trabajo de la cuenta. Decidir qué importe es el correcto es del negocio.

En el ejemplo, el total de una línea es cantidad por precio, sin impuestos, descuentos ni portes. Con otro contrato la fila podría ser correcta, y por eso la regla se escribe antes de importar.

Qué decidir antes de importar

Cuatro decisiones que cuestan diez minutos antes y evitan una limpieza larga después.

1. Qué columnas identifican una fila. Una, dos o tres, pero escritas.
2. Qué columnas son códigos. Aunque parezcan números, se leen como texto y no se rellenan ni se recortan.
3. Qué diferencia se acepta sin mirar. En el ejemplo, ninguna. Cada negocio tiene su respuesta.
4. Quién mira lo retenido y dónde lo ve. El original queda intacto y cada fila retenida lleva su motivo.

Cómo salió con los seis ficheros de prueba

Montamos seis ficheros pequeños, uno por cada tipo de fallo, con 28 filas inventadas. Un verificador propio, escrito solo para el ejemplo, dejó pasar 11 filas y retuvo 17, y las 23 pruebas que lo comprueban pasan. Esas cifras no dicen nada sobre cuántos ficheros reales fallan, porque los ficheros están hechos para fallar. Lo único que enseñan es que cada decisión de este artículo se puede escribir como regla y comprobar.

Si quieres verlo con otro fichero inventado, la demostración de importación está publicada. Es una implementación distinta y no ejecuta estos seis ficheros. Y Revisa tu CSV marca en tu navegador lo que se rompería en el tuyo, sin subirlo a ningún sitio. Lo dudoso sale como «revisar», no como error.

Si prefieres que alguien lo mire contigo, la llamada de diagnóstico dura 20 minutos y se pide en el formulario de diagnóstico.

Qué cubre este artículo y qué no

Los ejemplos son inventados y no corresponden a ningún cliente ni a ningún fichero real. No damos cifras de ahorro porque no las tenemos medidas. Las fuentes, leídas el 29 de octubre de 2026, son la especificación CSV on the Web: metadatos de la W3C, la ayuda de Microsoft sobre conservar ceros iniciales y números grandes y la documentación del módulo decimal de Python. El comportamiento exacto depende de tu programa y de su configuración, y no hemos probado todos.