Buenas prácticas en Power Query: nombres de pasos, tipos y plegado

Distribuidora Costa reparte ferretería por Manta, Portoviejo y Guayaquil. Cada mes su analista descarga los archivos de ventas de cada sucursal, los une en Power Query y publica el reporte en Power BI. La consulta funciona, pero tiene pasos que se llaman “Filtrado de filas1”, “Filtrado de filas2” y “Cambio de tipo3”, y cada actualización tarda más de lo necesario. Un día un compañero necesita el mismo reporte solo de la zona norte y el analista debe copiar toda la consulta y editarla a mano.

Cuando los pasos no tienen nombre, cuando no se definen los tipos de dato al empezar y cuando la fuente se lee dos veces desde el mismo archivo, la consulta se vuelve difícil de mantener y lenta de actualizar. En este artículo ves cuatro buenas prácticas para que tus consultas de Power Query sean ordenadas, rápidas y fáciles de reusar: nombrar los pasos con sentido, asignar tipos desde el origen, usar consultas de referencia en lugar de duplicar datos y vigilar el plegado de consultas para que el origen de datos haga el trabajo pesado.

Paso 1: nombra cada paso con sentido

Power Query registra cada transformación como un paso. Por defecto los nombres son genéricos —”Cambio de tipo1″, “Filtrado de filas2″— y nadie sabe qué hace cada uno sin abrirlo. Cambia el nombre de cada paso nada más crearlo: TipoVentas, FiltroSucursalManta, UnirProductos. En el panel de pasos del editor, un nombre claro te dice de qué trata cada transformación sin leer su fórmula.

let
    Origen = Excel.Workbook(File.Contents("C:Reportesventas.xlsx"), null, true),
    HojaVentas = Origen{[Item="Ventas",Kind="Sheet"]}[Data],
    TipoVentas = Table.TransformColumnTypes(HojaVentas,{{"Fecha", type date}, {"Total", type number}}),
    FiltroManta = Table.SelectRows(TipoVentas, each [Ciudad] = "Manta")
in
    FiltroManta

Cada paso ahora tiene un nombre propio y el código se lee de arriba abajo. Si alguien más hereda la consulta, entiende en segundos qué hace FiltroManta en lugar de adivinar qué significa el paso “Filtrado de filas2”.

Paso 2: asigna los tipos de dato desde el origen

No esperes al final de la consulta para cambiar los tipos. Tan pronto como cargas los datos, convierte Fecha en fecha, Total en número y Ciudad en texto. Así los filtros de fecha, las sumas y las agrupaciones funcionan sin errores, y evitas que Power Query adivine mal el tipo y convierta una columna entera en texto porque la primera fila estaba vacía.

Usa el paso Table.TransformColumnTypes justo después del origen, y repítelo solo si un paso posterior crea una columna nueva que necesite un tipo concreto. El orden importa: primero limpias, luego cambias los tipos y al final filtras.

Paso 3: usa consultas de referencia en lugar de copiar la fuente

Si necesitas el mismo archivo de ventas en dos consultas —una para el reporte mensual y otra para el resumen por sucursal—, no leas el archivo dos veces. Crea una consulta VentasBase que lea el archivo y haga la limpieza, y crea las otras dos con hacer referencia (clic derecho sobre la consulta → Referencia). Una consulta de referencia no carga los datos de nuevo; se apoya en el resultado de la consulta base.

let
    Origen = Excel.Workbook(File.Contents("C:Reportesventas.xlsx"), null, true),
    ...
in
    Origen

La consulta de ventas de Manta sería:

= VentasBase

con un filtro adicional sobre la columna Ciudad. Así, si cambia el nombre del archivo o la ruta, solo editas VentasBase y todas las consultas que hacen referencia a ella se actualizan. Más mantenimiento, menos trabajo duplicado.

Paso 4: cuida el plegado de consultas

El plegado de consultas ocurre cuando Power Query envía al origen de datos (una base de datos, una carpeta de SharePoint, un servicio en la nube) las operaciones que puede hacer él: filtrar, ordenar, agrupar. El origen filtra los datos y solo envía lo necesario, en lugar de descargar todo y filtrar en tu computadora. Si el plegado funciona, actualizar es mucho más rápido.

En el editor, junto al nombre de cada paso aparece un icono: si el origen lo soporta, el icono de plegado se ve activo. Si el icono desaparece tras cierto paso, ese paso rompió el plegado (por ejemplo, una función personalizada que Power Query no puede traducir al origen). Deja los pasos que rompen el plegado al final de la consulta, cuando ya hayas filtrado y reducido los datos al máximo.

Para comprobarlo, abre la consulta y mira el icono de cada paso; si ves que el plegado se detiene, revisa si ese paso es realmente necesario ahí o si puede moverse más abajo.

Errores frecuentes

• Pasos con nombres genéricos: “Filtrado de filas1”, “Filtrado de filas2” hacen imposible mantener la consulta meses después. Ponle nombre a cada paso al crearlo.
• Cambiar los tipos al final: si filtras fechas antes de convertir la columna en tipo fecha, el filtro puede comparar texto en lugar de fechas y fallar silenciosamente.
• Leer el mismo archivo en varias consultas: duplica el trabajo y obliga a editar cada ruta a mano. Usa una consulta base y haz referencia desde las demás.
• Romper el plegado temprano: agregar una columna personalizada antes de filtrar obliga a descargar todos los datos. Filtra primero y deja los pasos sin plegado para el final.

Con pasos bien nombrados, tipos definidos desde el origen, consultas de referencia y plegado de consultas bajo control, tus consultas de Power Query se actualizan más rápido y cualquier compañero puede entenderlas sin preguntarte qué hace cada paso.