Antes de importar una hoja de cálculo, revisa qué va a cambiar

Por Noe Guerrero III

Antes de que una importación de una hoja de cálculo cambie registros en la app de tu negocio, pide ver qué va a agregar, actualizar, dejar sin cambios o rechazar. Una vista previa útil explica esas decisiones antes de que las apruebes. Una barra de progreso de carga solo cuenta parte de la historia.

Esto importa cuando pasas una lista de refacciones, un directorio de clientes o un historial de trabajos a un software a la medida. “Importar CSV” parece una función pequeña. Las reglas detrás de ese botón merecen una conversación a fondo.

Revisa las columnas y los valores que contienen

CSV significa valores separados por comas. Primero, relaciona cada columna de origen con el campo correcto de la app. Muestra un valor de ejemplo junto a cada asignación para que alguien pueda detectar si, por accidente, un código de proveedor se está asignando a un identificador interno.

Después, revisa cómo se interpretan los valores. Si tu código de producto es 00127, una vista previa que muestra 127 necesita atención. La guía de Microsoft sobre ceros iniciales explica cómo Excel puede convertir texto numérico y quitar esos ceros, y cómo importar columnas como texto permite conservarlos. No des por hecho que un código se conservó solo porque el archivo abre.

Prueba también una descripción que contenga una coma. El formato CSV descrito en RFC 4180 admite comas y saltos de línea dentro de campos entre comillas. Pídele al desarrollador que verifique que la exportación y la importación usen el mismo formato; la descripción de un producto no debería convertirse en varios campos.

Si la exportación original ya perdió información, cambiar cómo la muestra la app no la recuperará. Compara la vista previa con un registro de origen que sepas que es correcto.

Acuerden qué identifica al mismo registro

Imagina un taller de reparación hipotético en McAllen que importa la lista de refacciones de un solo proveedor. En este ejemplo, el criterio acordado para identificar coincidencias es el código único de producto del proveedor. El nombre de un producto es texto descriptivo, no el criterio para encontrar coincidencias.

Decidan qué pasa en estas situaciones distintas:

• El código todavía no está en la app.

• El código ya existe, pero su descripción cambió.

• El mismo código aparece dos veces en el archivo cargado.

• Falta un código obligatorio.

No elijan el primer o el último duplicado sin avisar, a menos que sea una regla intencional y documentada. También decidan qué significa una celda vacía al actualizar: conservar el valor anterior, borrarlo o rechazar la entrada. Esas decisiones pueden producir registros muy distintos a partir del mismo archivo.

Haz que la vista previa explique cada cambio

Para el ejemplo del taller, una vista previa pequeña podría verse así. Son resultados propuestos para un archivo de prueba, no resultados de un sistema de un cliente real.

Pide totales que puedas cotejar con las entradas, incluidos los registros sin cambios y los rechazados. Una muestra de los primeros registros es útil, pero todavía hace falta validar el archivo completo. Cada actualización propuesta debe poder revisarse antes de aprobarla.

Si alguien edita un producto existente después de generar la vista previa, exige que la app vuelva a comprobarlo antes de aplicar un plan desactualizado. El desarrollador debe definir cómo se detectan y se presentan esos cambios.

Decide qué pasa cuando falla parte del archivo

¿Un registro rechazado detendrá toda la importación o se aplicarán los registros válidos mientras los rechazados quedan pendientes? Cualquiera de las dos opciones necesita una explicación clara y un resultado que puedas revisar.

Cada herramienta hace distinciones diferentes. La documentación de HubSpot sobre errores de importación distingue los casos en que los registros no se importan de aquellos en que sí se importan, pero con errores en ciertas propiedades. Para tu propia app, pregunta qué significa “completado” y qué campos cambiaron realmente.

Conserva el archivo original y un comprobante que muestre el resultado, la hora y las entradas que necesitan corrección. Si la importación es parcial, asegúrate de que el proceso de corrección no repita por accidente el trabajo que ya se completó bien.

Prueba el botón dos veces antes de aceptar la función

Dale al desarrollador un archivo de prueba pequeño y acordado que contenga un registro nuevo, uno modificado, un duplicado y uno sin identificador. Compara la vista previa con el resultado que realmente se guardó. Después, prueba qué pasa si la importación termina, pero el usuario no recibe la confirmación e intenta de nuevo. El segundo intento debe seguir la regla acordada, en lugar de crear un segundo conjunto de registros sin explicación.

Nuestra guía para planear apps que funcionan sin conexión profundiza en los reintentos y los cambios que entran en conflicto. Para una función de importación, mantén sencillo el criterio de aceptación: ¿tu equipo puede explicar qué va a cambiar, aprobarlo y verificar qué ocurrió realmente? Nuestros servicios de desarrollo de software pueden ayudarte a convertir esas reglas en un documento claro para orientar el desarrollo.