2026-10-28
Por qué un Excel correcto a simple vista rompe una importación
Pasas un fichero de pedidos de un programa a otro. En Excel se ve perfecto. Al importarlo, el programa rechaza la mitad o, peor, lo acepta y guarda datos mal. Casi siempre el fallo no está donde lo buscas.
Aquí van seis errores típicos. Todos los ejemplos están inventados, son pedidos de una tienda ficticia, sin clientes ni datos reales. De cada uno cuento qué ocurre, la regla que lo detecta y dónde se queda corta. Las fuentes técnicas están al final.
Antes de nada, un CSV no es un Excel
Un CSV es un fichero de texto con los valores separados por comas. Nada más. No lleva tipos, ni formatos, ni fórmulas. La propia RFC 4180, que describe el formato, avisa de que no es un estándar de Internet, de que nunca hubo una especificación formal y de que hay diferencias considerables entre programas.
Por eso un mismo fichero se interpreta distinto según quién lo abra. Los seis errores salen de ahí.
1. El pedido que aparece dos veces
Lo que ves. Dos filas casi iguales, el pedido 1043 de "Tornillería Ejemplo", fecha 2026-03-04, importe 48,00 euros. Parece un descuido sin importancia.
Lo que pasa. El programa de destino puede crear dos pedidos y facturar dos veces el mismo.
La regla. Decidir qué campo identifica un pedido, aquí el número, y exigir que no se repita. Es lo que la especificación Table Schema de Frictionless Data llama clave primaria, es decir, un campo o conjunto de campos que identifica cada fila, y la restricción de valor único.
El límite. La regla detecta la repetición, no decide cuál fila sobra. Y dos filas iguales pueden ser dos pedidos legítimos si el origen no tiene número de pedido. Eso lo decide una persona.
2. La fecha que se puede leer de dos maneras
Lo que ves. 03/04/2026 en una columna de fecha de pedido.
Lo que pasa. Unos programas leen el 3 de abril y otros el 4 de marzo. Ninguno avisa, porque las dos lecturas son fechas válidas.
La ayuda de Microsoft lo reconoce. Al abrir un CSV, Excel usa la configuración de formato por defecto para interpretar cada columna, y pone el ejemplo de una columna en orden mes-día-año frente a un Excel configurado en otro orden.
La regla. Acordar un solo formato para todo el fichero. El que usa Table Schema por defecto es ISO 8601, año-mes-día, como 2026-04-03, que no admite dos lecturas.
El límite. Si el fichero ya llega como 03/04/2026, la regla no puede adivinar el orden. Una fecha como 25/04/2026 delata el formato, pero solo si hay alguna en el fichero. Si no la hay, hay que preguntar al origen.
3. El decimal que es coma en un sitio y punto en otro
Lo que ves. Un importe de 12,50 euros.
Lo que pasa. Un programa configurado con punto decimal puede leer 12,50 como texto y rechazarlo, o leerlo mal sin avisar.
Table Schema fija el punto como separador decimal por defecto y deja declarar otro carácter, además del de miles. La ayuda de Microsoft añade un detalle. En Excel, el separador de lista de un CSV, la coma o el punto y coma, va ligado a la configuración regional. Según esa ayuda, si cambias el decimal a coma, Excel usa el punto y coma como separador de lista.
La regla. Declarar en el propio proceso qué carácter es el decimal y cuál el de miles, y rechazar lo que no encaje.
El límite. 1.250 puede ser mil doscientos cincuenta o uno con doscientas cincuenta milésimas. Sin saber la convención del origen, no se distingue.
4. La cantidad que viene vacía
Lo que ves. Una fila con la cantidad en blanco.
Lo que pasa. Según el programa, se toma como cero, como error o como "no lo sé", y cada uno produce un resultado distinto en el stock y en la factura.
Table Schema separa dos cosas. Por defecto un valor vacío se trata como nulo, y un campo puede declararse obligatorio con la restricción required. Son decisiones distintas.
La regla. Marcar qué columnas son obligatorias y rechazar el vacío en ellas. En las demás, decidir por escrito qué significa vacío.
El límite. Vacío no es cero. La regla puede decir que falta un dato, pero no sabe cuál es.
5. El código al que se le caen los ceros
Lo que ves. El código de producto 00472 en el fichero de origen.
Lo que pasa. Al abrirlo y guardarlo, queda 472. El producto 472 y el 00472 son distintos, y el pedido apunta a otro artículo.
La ayuda de Microsoft explica la salida. Si una columna de números lleva ceros a la izquierda y quieres conservarlos, hay que convertirla a texto al importar, con el asistente de importación de texto. Table Schema coincide en el fondo, ya que un campo sin tipo se trata como texto.
La regla. Las columnas que son identificadores, no cantidades, se tratan siempre como texto.
El límite. Si el fichero ya se guardó como 472, el cero no se recupera sin más. Rellenar con ceros hasta cinco cifras solo vale si todos los códigos tienen siempre cinco.
6. El total que no cuadra con sus partes
Lo que ves. 3 unidades a 4,00 euros y un total de 21,00.
Lo que pasa. Nada falla en el formato. La fecha, el decimal y el código son correctos. El importe está mal y entra igual.
Aquí no hay fuente técnica que citar, porque no es un error de formato sino de negocio. Y las restricciones de Table Schema se definen campo a campo, no cruzan unas columnas con otras. Es una comprobación que hay que escribir aparte.
La regla. Comprobar que cantidad por precio es igual al total, con un margen de céntimos para redondeos.
El límite. Un descuento, unos portes o el IVA pueden explicar una diferencia legítima. La regla marca la fila para que alguien la mire. No la corrige.
Qué hacer con esto
Si importas ficheros con frecuencia, tres pasos ayudan.
- Mira el fichero como texto antes de abrirlo en Excel. Se ve lo que hay de verdad, sin que nadie lo reinterprete.
- Escribe una regla por columna, con su tipo, su formato, si es obligatoria y si no puede repetirse.
- Deja a una persona lo ambiguo. Una regla bien hecha avisa de las filas dudosas, no las arregla a ciegas.
Si quieres que alguien lo mire contigo, la llamada de diagnóstico dura 20 minutos y está descrita en Qué pasa en un diagnóstico de automatización de 20 minutos y qué te llevas. También puedes pedirla directamente en el formulario de diagnóstico.
Qué cubre este artículo y qué no
Los seis 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 reglas se contrastan con tres fuentes: la RFC 4180 sobre el formato CSV, la ayuda de Microsoft sobre importar o exportar ficheros de texto o CSV y la especificación Table Schema de Frictionless Data. El comportamiento exacto depende del programa y de su configuración regional, y no hemos probado todos los programas.