Un tablero puede abrir rápido, actualizar sin fallas y mostrar ventas que la empresa nunca hizo. Basta combinar tablas con niveles de detalle diferentes para repetir valores y después sumarlos como si fueran operaciones independientes. El gráfico no tiene por qué advertirlo: está calculando sobre los datos que recibió. Para una empresa colombiana que conecta su operación con Power BI, la pregunta decisiva llega antes del diseño: ¿qué representa exactamente cada fila? Esta guía propone controles para detectar cifras infladas y construir un modelo que permita explicar los resultados, sin convertir cada reunión en una discusión sobre cuál archivo tiene la razón.
Defina qué representa una fila antes de sumar
Imagine una factura de un millón de pesos con tres líneas de producto. En una extracción que repite el total de la factura en cada línea, sumar esa columna produce tres millones. La empresa no vendió más: la preparación del dato multiplicó su representación. Es un ejemplo ilustrativo, no un hallazgo sobre los sistemas de Wondertech ni de un cliente. Cambiar colores o formatear la cifra no corrige el problema.
Escriba una frase por tabla: una fila representa una línea de factura, un pago aplicado o una meta mensual por equipo. Después identifique la combinación de campos que debería hacer única esa fila. Si no puede describir esa unidad con claridad, posponga las medidas del tablero. El área usuaria debe entender esa definición sin necesitar leer código.
Microsoft recomienda mantener un nivel de detalle consistente en las tablas de hechos. Esa orientación ayuda a separar eventos que parecen similares pero responden preguntas diferentes. Vender, facturar y recaudar no son la misma observación. Pueden analizarse juntos, siempre que el modelo conserve su identidad y que cada indicador declare cuál de esos procesos está midiendo.
Combinar tablas puede multiplicar registros legítimos
Considere una factura con tres líneas y dos pagos. Si una transformación combina ambos detalles únicamente por el identificador de factura, puede generar seis filas: cada línea aparece con cada pago. Las fuentes pueden estar correctas y no contener duplicados. El error surge de la combinación. Por eso, borrar filas repetidas sin revisar su significado puede eliminar operaciones válidas y empeorar la trazabilidad.
Nuestra propuesta es documentar cada combinación importante con tres controles: cantidad de filas antes y después, claves sin coincidencia y suma del importe relevante. Un aumento de filas no demuestra por sí solo una falla; debe tener una explicación acorde con la unidad de análisis. Revise también valores vacíos y registros excluidos, porque un total menor puede ser tan engañoso como uno inflado.
Cuando los equipos pidan una tabla única con ventas, pagos, metas y productos, pregunte primero qué comparación necesitan. Para analizar recaudo mensual quizá no haga falta llevar cada pago a cada línea de producto. Diseñar desde la pregunta reduce cruces innecesarios y facilita explicar por qué una cifra pertenece a un período, una empresa o un responsable concreto.
Use relaciones que respeten el significado del negocio
La guía de esquema estrella de Microsoft distingue dimensiones para filtrar y agrupar, y hechos para resumir eventos. Clientes, productos y fechas suelen ayudar a organizar el análisis; las transacciones aportan las observaciones. Esta separación permite que diferentes procesos compartan criterios de consulta sin obligar a mezclarlos físicamente en una sola tabla con columnas repetidas.
Microsoft también documenta escenarios válidos de relaciones muchos a muchos y el uso de tablas intermedias. No son una solución automática para cualquier clave repetida. Antes de elegir una relación, determine si la repetición representa una situación real, como una asignación compartida, o una dimensión mal preparada. Resolver el mensaje del programa no demuestra que se haya resuelto el significado del dato.
La documentación de relaciones explica la propagación de filtros entre tablas. Revise ese comportamiento con preguntas concretas: al seleccionar una ciudad, ¿qué ventas cambian y cuáles deberían cambiar? Evite activar direcciones de filtro adicionales solo para obtener un resultado esperado en un gráfico. Una corrección local puede alterar otras páginas; cada recorrido debe tener una razón comprensible para el equipo.
Un total diferente a la suma visible puede ser correcto
No toda diferencia es duplicación. Imagine dos productos comprados por el mismo cliente: cada producto tiene un comprador, pero el total de clientes únicos es uno. Sumar las dos filas visibles respondería otra pregunta. De manera similar, un porcentaje consolidado necesita una definición: promediar porcentajes de grupos con tamaños distintos puede producir una lectura que el negocio no pretendía.
Acuerde qué medidas pueden sumarse y en qué dimensiones. Ventas, clientes distintos, saldos y tasas requieren tratamientos propios. Para cada indicador crítico, escriba numerador, denominador cuando corresponda, período y exclusiones. Incluya cómo se interpreta el total. Esa ficha evita que alguien cambie una fórmula correcta únicamente porque esperaba ver la suma aritmética de una tabla.
Prepare ejemplos pequeños calculados por separado: una factura con varias líneas, un cliente en dos categorías, una devolución y una operación sin clasificación. Compare el resultado del modelo con la explicación del caso. Si hay una diferencia, identifique si viene de la transformación, la relación, el filtro o la medida. Cambiar varias capas al tiempo dificulta saber qué arregló realmente el resultado.
Concilie resultados antes de convertirlos en decisiones
Para comenzar, elija un indicador y un período cerrado que el responsable del proceso pueda validar. Compare el total y algunas agrupaciones relevantes contra la fuente autorizada, usando exactamente las mismas reglas de fecha, estado y moneda. No contraste ventas antes de impuestos con un total que los incluye. Las diferencias de definición deben resolverse antes de atribuir el problema a Power BI.
Conserve los identificadores de los documentos del ejemplo, la consulta utilizada y el resultado esperado. Si los datos provienen de Odoo, esa referencia permite regresar al documento y explicar su tratamiento. Repita la comparación después de corregir el modelo y revise los informes que dependen de él. La evidencia debe mostrar tanto la cifra final como la causa de la diferencia anterior.
La siguiente reunión de gerencia debería comenzar con una cifra que alguien pueda explicar hasta su origen. Nuestra recomendación es revisar primero el indicador que más decisiones mueve y registrar los controles como parte de su mantenimiento. Si su empresa necesita revisar un modelo de Power BI en Colombia, converse con Wondertech para definir un diagnóstico acotado: detalle de tablas, relaciones, medidas y conciliación con la operación.
Más artículos de analítica y Power BI · Converse con Wondertech
Fuentes oficiales Microsoft Learn: Esquema estrella · Relaciones muchos a muchos · Relaciones en Power BI