Ha decidido cambiar de sistema y alguien le ha pasado una lista: sucursales, clientes, maestro de artículos, pedidos abiertos. La lista suele venir de administración o de un consultor, y quien tiene que rellenarla suele estar en el almacén. Las dos partes usan las mismas palabras sin querer decir lo mismo. Para administración una ficha de artículo es una fila; para el almacén es una caja en una estantería. Casi todos los fallos que aparecen el primer día del cambio nacen de esa distancia.
La tesis de este artículo cabe en una frase: la lista de migración viene de contabilidad, pero la respuesta correcta a cada línea está en el almacén. Si un código de artículo es realmente único, qué cuenta de verdad una unidad de medida y cuántas piezas caben en una caja son decisiones que solo puede tomar quien está en el muelle. Por eso la limpieza de datos no es un trabajo de hoja de cálculo, sino de almacén. A continuación repartimos la preparación en nueve decisiones y luego planificamos el día del cambio.
La lista viene de contabilidad, las respuestas del almacén
Sea cual sea el sistema al que se cambie, la lista que le entregan es prácticamente la misma: datos de empresa y sucursales, fichas de clientes, maestro de artículos, pedidos abiertos y unos "saldos iniciales". Casi todo lo que encontrará escrito sobre esto repite exactamente esa lista y se detiene ahí. Justo donde se detiene empieza el problema, porque cada línea esconde una pregunta que alguien tiene que responder físicamente.
Un ejemplo. "Prepare el maestro de artículos" es, sobre el papel, rellenar un formulario. En el almacén significa otra cosa: ¿qué fila del sistema corresponde a lo que hay en esta estantería, la unidad de esa fila coincide con lo que aquí contamos, y el mismo producto está además registrado con un segundo código? Administración no puede saber nada de esto; administración tiene códigos e importes. Por eso el primer movimiento más rentable de un cambio de sistema no es rellenar la lista, sino llevarla a la persona correcta.
Hay un segundo hecho: el cambio de sistema es el único momento en que estas preguntas pueden hacerse en bloque. Una vez el sistema está en marcha, nadie abre cuatrocientas fichas una a una para rellenar medidas; el trabajo diario siempre gana. La hoja que prepare ahora será la fuente de los documentos que leerá durante años. Y la hoja de cálculo no es el enemigo aquí: como formato de transporte para una migración es justo la herramienta adecuada. Donde se queda corta es cuando se le pide gestionar la operación, algo que argumentamos aparte: hasta dónde llega la hoja de cálculo.
Si un artículo tiene dos códigos, la migración lo parte en dos
Una ficha de artículo duplicada puede vivir años sin que nadie la detecte en el sistema antiguo, por una razón sencilla: los dos códigos funcionan. Uno lo abrió compras, el otro ventas; uno lleva el código del importador, el otro el interno. De ambos salen documentos y ambos parecen correctos. La migración rompe esa paz, porque en el sistema nuevo las dos fichas nacen como dos productos distintos y ya no queda ningún vínculo entre ellas.
Buscar duplicados por parecido de nombre no funciona: el mismo producto aparece con dos nombres distintos, mientras que productos realmente distintos aparecen con nombres casi idénticos. Lo que sí funciona es el trío físico: medidas, peso y unidades por caja. Dos fichas que coinciden en los tres son probablemente la misma cosa, se llamen como se llamen; dos fichas que no coinciden son cosas distintas aunque el nombre sea el mismo. Por eso el barrido se hace en el almacén: decide quien tiene la caja en la mano, no quien abrió la ficha.
El segundo patrón habitual es la variante hueca de un código antiguo: se abrió una ficha para un producto, nunca se rellenaron sus medidas ni su peso, pasaron uno o dos documentos por ella y se olvidó. Son las fichas más peligrosas en una migración, justamente porque al estar vacías no las detecta ningún barrido. La única pregunta que vale la pena hacerse es: ¿esta ficha sigue significando algo? Si no, no se traslada: el cambio de sistema es también la única oportunidad de dejar atrás fichas muertas. Si sí, quienes piden y expiden ese producto deciden juntos qué ficha sobrevive; no es una operación técnica sino una cuestión de propiedad.
Aquí dejamos fuera dos temas a propósito, porque cada uno tiene su propio artículo. La forma del código —cuántos dígitos, ceros a la izquierda, caracteres que se confunden entre sí— es diseño de esquema de códigos, y sus reglas están en otro sitio: las reglas para diseñar un esquema de códigos. Y si ese código va o no a un código de barras es otra decisión completamente distinta, y no tiene por qué ser la misma cadena que su código de artículo: qué número va en el código es otra decisión.
Si tiene que cambiar un código, dónde se queda el antiguo
Cambiar un código durante una migración a veces es inevitable: dos fichas se fusionan, o el esquema antiguo lleva un carácter que el sistema nuevo no acepta. El coste de cambiarlo suele pasarse por alto. En el momento en que el código antiguo desaparece, todos los documentos pasados impresos con él se vuelven ilegibles. Coja un albarán de hace un año y no podrá buscar el código que lleva: el documento se convierte en historia.
La solución no es complicada: mantenga vivo el código antiguo en algún campo. Basta con que aparezca dentro del nombre del artículo, del campo modelo o de una descripción en el sistema nuevo: solo tiene que ser buscable, no necesita un campo propio. Hacerlo durante la migración cuesta un minuto; hacerlo después es casi imposible, porque para entonces nadie encuentra la hoja que recuerda la correspondencia. Deje la regla por escrito: conserve también después del cambio la tabla que muestra qué código antiguo pasó a ser cuál nuevo. Es el fichero que más va a necesitar y el primero que se pierde.
Unidad de medida: lo que cuenta el muelle frente a lo que dice la factura
"¿Pongo kilos o unidades?" consume más tiempo de preparación que cualquier otra pregunta, y casi siempre se formula en el marco equivocado. El marco correcto es este: hay dos clases de unidades. Las unidades discretas describen enteros contables: unidad, caja, palé, par. Las unidades continuas (fraccionadas) describen magnitudes medidas: kilogramo, metro, metro cúbico, litro. La diferencia no es académica sino del todo práctica: una unidad continua, por sí sola, no sirve para contar.
Piense en un producto que se vende al peso. La factura dice kilos, y hace bien. Pero en un muelle nadie cuenta kilos; nadie dice "he cargado veintitrés coma cuatro kilos". Un muelle cuenta cajas. Es decir, esa ficha tiene que llevar dos unidades a la vez: la fraccionada que usa ventas y la discreta que usa el almacén, más la conversión entre ambas. Sin ese trío la ficha no es válida, y aunque lo parezca el recuento no cuadrará en el primer envío.
En nuestra propia aplicación esto no está codificado como consejo sino como regla dura: al importar artículos, si la unidad es fraccionada, la segunda unidad y el factor de conversión tienen que estar rellenos y la segunda unidad tiene que ser discreta; si no, esa fila no se importa. La regla parece severa, y la severidad es deliberada: una ficha abierta solo con una unidad fraccionada parece impecable hasta que se imprime la primera etiqueta de caja.
Consejo práctico: repase la columna de unidades de su exportación línea a línea, porque lo que encontrará ahí a menudo no es una unidad sino una palabra que alguien tecleó un día. "Ud", "ud.", "UD", "unidad", "unidades", "pza" pueden significar lo mismo para una persona y son seis valores distintos para un sistema. Unificarlos es medio día de trabajo ahora y casi imposible después del arranque.
La unidad es un campo codificado, no texto libre
Hay una razón documentada para tomarse tan en serio la columna de unidades. En los formatos de documento electrónico, la unidad que acompaña a una cantidad no es texto libre sino un código tomado de una lista publicada; cada administración indica qué lista se aplica y qué valores son válidos. La consecuencia es la misma en todas partes: una unidad que solo existe como una palabra que alguien tecleó no puede convertirse en código, y la capa documental no se puede generar a partir de ella.
La consecuencia es esta: si una ficha dice "ud", otra "UDS" y una tercera "unidades", las tres tienen que resolverse al mismo código, y tarde o temprano alguien hará esa resolución. Si ese alguien es usted, ocurre durante la migración; si no, ocurre años después, cuando un documento no se pueda generar. En nuestra aplicación el nombre de la unidad puede escribirse en cualquiera de los tres idiomas de la interfaz y se resuelve a un código canónico; una fila con una unidad que no se puede resolver se omite en lugar de importarse, y hay una pantalla de referencia de unidades que muestra qué códigos se aceptan y marca cada uno como continuo o discreto.
Unidades por caja: un solo número, tres sitios donde revienta
El campo obligatorio que más objeciones genera en una plantilla de migración suele ser las unidades por caja. "El producto tiene precio, nombre y código; ¿por qué hace falta saber ahora cuántas caben en una caja?" Porque ese número no se usa en un sitio sino en tres, y los tres fallan en silencio.
Primero, la etiqueta: cuántas etiquetas se imprimen sale de la relación entre número de bultos y unidades por caja. Rompa esa relación y le sobrarán etiquetas o le quedarán cajas sin etiquetar. Segundo, el recuento de carga: si carga escaneando, el número esperado de lecturas viene de la misma relación; si está mal, la carga da por "terminado" antes de tiempo o no termina nunca. Tercero, el packing list: la coherencia entre cantidad y número de cajas depende justamente de que este número sea correcto. Una sola celda equivocada se propaga a tres documentos a la vez y en cada uno se disfraza de otra cosa.
La regla práctica que se deriva: no estime las unidades por caja. Abra una caja y cuéntelas. Es la tarea más aburrida y más rentable de toda la preparación. Qué campos acaban en la etiqueta que lleva ese mismo número lo tratamos aparte: qué campos lleva la etiqueta de una caja.
Los campos de medidas y peso que se dejan vacíos no se rellenan después
Ancho, largo, alto y peso neto/bruto son casi siempre campos opcionales en una plantilla de migración, y justo por eso casi siempre se quedan vacíos. El coste no aparece de inmediato, sino unos meses después. El volumen es un valor que se calcula a partir de las medidas; sin medidas no hay volumen. Sin volumen no hay plan de carga, no se puede contrastar una oferta de flete ni estimar cuántos palés caben en un contenedor.
Con el peso la cosa es más clara: el peso neto y el bruto se piden en la documentación de exportación, y en ese momento nadie se pone a reabrir cientos de fichas. Lo que ocurre en la práctica es que el peso se teclea a mano mientras se prepara el documento, cada vez de nuevo y cada vez un poco distinto. Después dos documentos muestran dos pesos distintos y nadie sabe cuál es el correcto.
El cambio de sistema es el único momento en que estos campos pueden rellenarse en bloque, porque ya está trabajando fila a fila sobre una hoja. Medir una caja son treinta segundos; introducir esas mismas medidas una a una después del arranque es una tarea que no empieza nunca. Anote también la unidad de medida: una columna de dimensiones que no dice si son centímetros o milímetros es más peligrosa que una vacía, porque parece rellena.
Clientes y sucursales: una dirección es un punto de entrega, no un texto
Se suele dar por hecho que las fichas de clientes son la parte fácil de una migración, porque administración ya las mantiene ordenadas. Pero lo que administración mantiene ordenado es la dirección de facturación: la del NIF, la de la razón social y la del pago. Lo que necesita el almacén es la dirección de entrega, y en la mayoría de los clientes no son la misma. Se factura a una central y se entrega en una fábrica; se factura a una cadena y se reparte en cinco tiendas.
La misma separación vale para el teléfono. El número de la ficha de cliente suele ser el de administración; la persona a la que hay que llamar el día de la entrega es quien va a descargar el camión. Una migración es una buena ocasión para separarlos: anote una vez qué campo sirve a quién y durante años todo el mundo llamará al número correcto.
Un aviso de terminología: en muchos sistemas una sucursal y un almacén no son el mismo objeto. En nuestra aplicación una sucursal es una unidad organizativa de su propia empresa, no una ubicación ni un hueco de estantería. Confundir ambos al rellenar una plantilla de migración es de los errores más costosos de deshacer, porque las fichas abiertas con el concepto equivocado se van propagando a los documentos. Direccionar las ubicaciones internas de su almacén es un trabajo de diseño completamente aparte: el sistema de direcciones de estanterías.
Orden de carga: qué datos entran antes que cuáles
Cuando los ficheros están listos queda una pregunta, y suele hacerse la última: ¿cuál cargo primero? El orden no es arbitrario, porque las fichas dependen unas de otras. El orden correcto es sucursales → clientes → artículos → pedidos. La razón es sencilla: una línea de pedido cuelga de un cliente, de un artículo y de una sucursal; si esos tres no existen todavía, no hay de qué colgarla.
Aquí hay que corregir algo con franqueza, porque el aviso habitual de que "si carga en otro orden las filas desaparecen en silencio" no es cierto en nuestra aplicación, y el comportamiento real es en realidad más traicionero. Cuando la importación de pedidos encuentra un código de cliente o de artículo que no existe, la fila no se descarta: la aplicación crea la ficha ella misma y le muestra un aviso. Lo que crea está hueco: el nombre es el propio código, la unidad es la predeterminada, las unidades por caja son una, sin medidas y sin peso. Si el que no existe es un código de sucursal, avisa y le lleva a la pantalla de alta de sucursales.
¿Por qué es peor? Porque una fila descartada se nota y una ficha hueca no. Mire la lista de artículos en el sistema nuevo: las fichas están ahí, el número cuadra y todo parece correcto. Lo único que no está bien es que ninguna de esas fichas lleva medidas, peso ni unas unidades por caja reales, y eso no aflora hasta que se imprime la primera etiqueta. Cargar en el orden correcto hace que esas fichas huecas no lleguen a nacer.
Fíjese también en el mensaje con que termina la importación: nuestra aplicación indica cuántas fichas se importaron y cuántas se omitieron. Hay que decir claramente un límite: no enumera qué fila se omitió ni por qué, solo el total. Así que si el número de omitidas es mayor que cero, repasar el fichero es cosa suya. Mírelo a propósito; un número de omitidas distinto de cero no es un detalle para pasar por alto.
Por qué la previsualización va antes de guardar
La importación de pedidos tiene un paso de previsualización antes de guardar, y ese paso tiene una función real: marcar las filas en las que el mismo código de artículo llega con dos unidades distintas dentro del fichero. Es el último punto en el que se puede detectar una incoherencia de unidad de medida. Una vez guardado, dos unidades se convierten en dos realidades, y cuál es la correcta ya no lo recuerda el fichero sino una persona.
Aquí también hay un límite y conviene decirlo: esta previsualización existe solo en la importación de pedidos. La importación de artículos no tiene previsualización: el fichero se procesa directamente, las filas que incumplen las reglas se omiten y al final solo ve un número. Por eso el fichero de artículos es el que hay que leer con más cuidado antes de acercarlo al sistema.
El día del cambio: qué se detiene y qué pasa con la mercancía en tránsito
La parte que más se aplaza de una migración es el momento del corte en sí. Todo el mundo habla de preparar datos; nadie deja por escrito la respuesta a "¿a qué hora dejamos de crear registros en el sistema antiguo?". Y esa sola frase evita el error más caro de un cambio de sistema: que el mismo documento se abra en los dos sistemas a la vez.
Dejar el corte por escrito no consiste en fijar una fecha; hay que escribirlo por tipo de documento. ¿Cuándo empieza a tomar pedidos en el sistema nuevo? ¿A partir de qué fecha emite allí los documentos de expedición? ¿Y las facturas? Los tres no tienen por qué caer el mismo día y normalmente no lo hacen. Cuando no está escrito, cada uno actúa según su propia suposición y una semana después encuentra documentos a medias en los dos sistemas.
La partida que más se olvida es la mercancía en tránsito: envíos que han salido pero aún no se han entregado. En el sistema antiguo ya se fueron; en el nuevo nunca existieron. Cuando llegan no hay registro contra el que recepcionarlos, y nadie piensa en esto antes del corte. La regla debería ser: todo envío en tránsito en el momento del corte tiene que existir como registro abierto en el sistema que vaya a cerrarlo. Usted decide cuál es ese sistema, pero tiene que estar decidido.
Trabajar en paralelo —mantener los dos sistemas durante un tiempo— se recomienda a menudo y de verdad reduce el riesgo, pero el precio es introducir cada documento dos veces. No vamos a poner una cifra a cuánto debe durar, porque lo único que lo determina es su volumen documental y el aguante de quien haga la doble introducción. Lo que sí puede decirse es que la condición de salida del trabajo en paralelo tiene que escribirse desde el principio. "Usemos los dos un tiempo" suele durar meses justamente porque no tiene condición de salida, y deja datos incompletos en los dos sistemas.
Antes de apagar el sistema antiguo: llévese los datos
Cuando el sistema nuevo está en marcha, mantener viva una suscripción o un contrato de mantenimiento del antiguo parece absurdo, y suele ser la primera partida que se recorta. Antes de apagarlo hay una pregunta que responder: si vuelvo a necesitar esos datos, ¿dónde los miro?
Si la respuesta es "imprimimos los informes en PDF", no basta. Un montón de PDF no es un archivo: no puede buscar dentro, ni comparar dos registros, ni recalcular un total. Exportar los datos en un formato legible por máquina —CSV o JSON— cuesta menos esfuerzo que imprimir PDF y a cambio le da un archivo de verdad. Nuestra propia aplicación ofrece los dos formatos; pero la cuestión no es qué software use, sino no saltarse este paso antes de apagar la luz.
Hay además una vertiente de obligación. Los registros mercantiles y contables tienen que seguir siendo legibles durante el plazo de conservación que le corresponda, y "legible" no significa un fichero de base de datos encerrado en un programa que ya nadie puede arrancar. En España, el Código de Comercio obliga a los empresarios a conservar los libros, la correspondencia, la documentación y los justificantes de su negocio, debidamente ordenados, durante seis años a partir del último asiento realizado en los libros (Código de Comercio, art. 30). Confirme con su asesor qué alcanza en su caso; el plazo cambia según el tipo de documento.
Un último aviso: llevarse los datos no es lo mismo que poder leerlos. Abra la exportación una vez antes de la fecha de apagado y busque un registro dentro. Si no abre, o si los encabezados de columna no significan nada, lo que tiene es un fichero y no un archivo.
El mismo principio funciona a la inversa: al meter datos hacia dentro, vigile el riesgo de sobrescritura. Nuestro motor de transferencia es conservador en esto: si en el destino ya existe un registro con el mismo número o código, no lo sobrescribe, lo omite. Eso impide que una transferencia relanzada por error corrompa los datos; y también desmonta cualquier expectativa de que "lo he transferido, así que está actualizado". Sea cual sea el software, averigüe qué comportamiento se aplica antes de la primera ejecución.
Qué hacemos en este lado y qué no
En lugar de cerrar con un argumento de venta queremos cerrar con un límite, porque el error más caro al planificar una migración es partir de una expectativa equivocada. Smartifie Logistic no es un ERP ni pretende sustituir a uno; es una aplicación que se sitúa en el lado de la expedición.
Lo que sí hacemos. Cuatro pantallas —artículos, clientes, pedidos y sucursales— ofrecen una plantilla de Excel descargable y una importación; en la ficha de artículo el código, las unidades por caja y la unidad son obligatorios; si se usa una unidad fraccionada, la segunda unidad y el factor de conversión también pasan a serlo; el volumen no se teclea, se calcula a partir de las medidas que introduzca; la importación de pedidos muestra una previsualización antes de guardar y marca las filas en las que un mismo código llega con dos unidades distintas; y puede recuperar sus datos en CSV o JSON.
Lo que no hacemos, y preferimos enumerarlo sin rodeos. La aplicación no guarda saldos de stock ni cantidades disponibles; no existe en ella nada parecido a un registro de "inventario inicial". No hay módulo de recuento de existencias. No hay seguimiento de lote, partida, número de serie ni fecha de caducidad. No hay contabilidad: aquí un "cliente" es una ficha de cliente, no una cuenta; no hay saldos, ni facturas abiertas, ni plan contable. No tenemos conector con ningún ERP; los datos se mueven mediante la plantilla de Excel, más la opción de transferirlos a su propia base de datos. Y no hay ningún asistente de limpieza que encuentre o fusione fichas duplicadas; el barrido que describe este artículo lo hace usted, no el software.
Lo enumeramos por practicidad, no por modestia: si alguno de esos puntos es un requisito para usted, la respuesta está en otro sitio y conviene saberlo antes del cambio, no después. Del mismo modo, está claro en qué lado de la migración nos situamos: existimos para que el pedido, la orden de expedición, la carga, la etiqueta de la caja y el documento de entrega salgan todos de un mismo registro. Y para cerrar con la tesis inicial: la lista de migración viene de contabilidad, pero la respuesta a cada línea está en el almacén. Haga ahí la preparación y se romperán menos cosas, sea cual sea el sistema al que se cambie.