Respuestas de foro creadas
-
Gracias Diego!,
Hasta conseguir verlo tal como lo quería, me ha llevado mi trabajo, es cierto.
Lo de los períodos no es un desarrollo propio (ya me gustaría). Lo aprendí en un curso de PowerBI, allí se utilizó el código M necesario para habilitar la selección por periodos.
La solución (el código y la explicación) es de Chris Webb, actualmente creo que está trabajando en Microsoft. El artículo original está en este enlace.Nos vemos las caras en unos días.
Un saludo!!
Buenos días a tod@s,
Tal como se comentó el martes, este podría ser un buen lugar para intercambiar las dudas que vayan surgiendo a medida que vayamos avanzando en el curso. Entiendo que todos saldremos beneficiados.
Con la intención de animar al resto de compañeros, inicio este tema y planteo una de las dudas que me han surgido hasta el momento :
Cuando se habló de LIVE CONNECTIONS no terminaba de entender las diferencias que tenía con DIRECT QUERY.
Lo revisé y enumero las principales características y diferencias entre ellas :
- LC : no es On PREMISE, está en la nube. Puede ser compartido por cualquiera que tenga acceso al entorno donde se encuentra. Podría ser Common Data Service, DatSet, Dataflow…
Los datos NO se cargan al modelo, es decir, las tablas que forman parte del modelo no son accesibles desde el desktop. Por tanto, cualquier cambio en el contexto (selección de un producto, p.e.) debe consultar al servicio en la nube, como lo hace DQ. El tamaño del pbix es mucho más reducido. No podemos cambiar el modelo, ni sus relaciones. Es un modelo CERRADO. Como se decía en el vídeo sería como “One single source of truth”
- DQ, la principal diferencia es que no es un modelo cerrado. Puede convivir con conexiones distintas. Cualquier cambio de contexto que afecte a la tabla conectada por DQ deberá consultar la fuente allí donde se encuentre, no tendría porque ser siempre en la nube. Ésta si podría ser una conexión ON PREMISE. No carga la tabla al pbix, igual que con LC, pero permite establecer relaciones con el resto del modelo.
Resumiendo :
- la primera es más segura y cerrada. El refresco de datos va a depender de la configuración de las actualizaciones que tenga el origen en la nube.
- la segunda convive con tablas con distintas conexiones y siempre estará actualizada con la fuente de datos, pues lo hace a cada cambio de entorno.
No soy informático, cualquier rectificación y/o aclaración será bien recibida.
Un saludo,
Ya sabemos que el examen será tipo test y que puede tener múltiples respuestas.
La duda que planteo aquí es :
¿Las respuestas incorrectas tienen algún tipo de penalización en el cómputo final?
Hola a todos,
- Una forma rápida de revisar la existencia de “Outliers” en los datos.
- distintas maneras de conocer la calidad de los datos
- Me permitirá reducir el tiempo dedicado a la revisión de los datos.
- en cuanto al examen, todo lo visto seguro que ayudará a entender las preguntas que se planteen y encontrar la respuesta adecuada.
Planteo una duda :
En las tablas “Sales y Budget” aparecen las columnas con el icono correspondiente a un “record” , pero los valores los trata como “Value”. Entiendo que deberían ser “record” o “List”.
¿Por qué “value”?
Por ejemplo, en el resto de tablas hay columnas que contienen tablas anidadas, por eso, aparecen como “Tables”. “Sales y Budget” contienen “records” y así deberían aparecer, en vez de “values”.
Lo planteo por si tiene algún significado que se deba tener en cuenta. Gracias.Nos vemos el martes.
Hola David,
Tal como yo lo veo, el hecho de tener activas cualquiera de las tres opciones de visualización (o las tres a la vez), no va a afectar al rendimiento del modelo ni a su tamaño. Ten en cuenta que cuando estás en Power Query Editor, lo que ves es el resultado del código M que se ejecuta detrás y no es hasta que decides clicar en “Close & Apply” que se cargan las tablas (las que tienen “Enabled Load” activado) al modelo.
Por tanto, una vez estés en el canvas, cuando refresques el modelo, el hecho de que las tres opciones que comentas estén o no activadas no tendrán ninguna incidencia en su rendimiento. Esto es así, tanto en el refresco de los datos de origen, como en las visualizaciones que vayas incorporando al informe.Otra cosa es como afecte dentro del Power Query Editor estando abierto. Cada una de las opciones requiere un análisis de los datos y sí afectará al tiempo requerido, de la misma manera que si solicitas que este análisis lo limite a las mil primeras filas o la tabla entera.
Dicho esto, una vez cerrado el Power Query Editor, ya no debería tener ninguna incidencia ni en el refresco, ni el rendimiento, ni en el tamaño del pbix.
Espero haber aclarado la duda.
Un saludo.
Buenos días,
He intentado cargar la tabla de Inventario y me aparece el siguiente mensaje :
Es como si la tabla estuviera vacía o no existiera. ¿Le ha ocurrido a alguien más?
Gracias y un slaudo.
No aparece, adjunto pantallazo :
Pero me dejó seleccionar la tabla al conectarme y además la pre-visualicé.
Pues la verdad es que no había trabajado con “semi-additive measures”, lo había leído pero nunca lo llegué a poner en práctica.
En los modelos financieros no lo he necesitado, a pesar de trabajar con los movimientos contables al máximo detalle (desde el Diario Contable), las tablas no han llegado al millón de filas y la suma de los importes los realizo con un simple SUM().Todo lo aprendido servirá, si no en un escenario en otro.
Seguimos.
Hola @Diego,
El Balance trabaja con acumulados anuales, por tanto, lo he resuelto con una medida muy simple :
SaldoYTD =
TOTALYTD([Saldo], ‘Calendar’[Date]
)Ahora, siguiendo lo aprendido en el módulo, la cambiaré por :
SaldoYTD =
CALCULATE([Saldo], DATESYTD(‘Calendar’[Date])
)Siendo, [Saldo] =
SUM ( Diario[Debe] ) – SUM ( Diario[Haber] )En las columnas tengo la jerarquía del tiempo, de manera que puedo obtener el balance hasta mensual, más detalle no tendría sentido.
Cada modelo depende de la estructura del Diario, que es la fuente de datos, que a su vez depende de cada Software. Por ejemplo, el modelo SAGE, incorpora en el Diario el nombre de las cuentas contables e incluye el Asiento de apertura, el del ejercicio y el de contabilidad.
Las medidas deben construirse teniendo en cuenta la forma en cómo se tratarán estos asientos. El tener incorporado el asiento de apertura, me permite simplificar la medida DAX para construir el balance.Otra cuestión sería el Estado de Flujo y Efectivo (imprescindible para una buena gestión de recursos),
este informe fue el que más trabajo me costó.
Ahora he aprendido a desarrollarlo por jerarquías directamente desde Power Query, hasta ese momento las había trabajado con tablas dimensionales (cargadas como tablas externas), de forma que al final tenía un modelo SnowFlake, que no era muy flexible a la hora de cambiar la estructura de los informes.
Bueno, no me extiendo más, en estos enlaces (disponibles en mi Linkedin) tienes con lo que he trabajado hasta el momento, estos aún no incorporan la nueva forma jerárquica comentada antes. Los datos usados no contienen nada que no pueda ser público :
Esta Sección va a necesitar mucha práctica para asimilar todos los conceptos y sus sutilezas.
Lo aprendido y más importante para mí :
Cómo aplicar la función ALLSELECTED (siempre se me resiste) y sus posibles combinaciones para obtener los resultados deseados, especialmente cuando necesitamos mostrar porcentajes sobre un total que no sea estático.
Versatilidad de las funciones de Time Intelligence y diferencias entre ellas, a pesar de dar el mismo resultado. Diferenciar los tres grupos :
Las que devuelven una fecha en concreto
Las que devuelven una tabla con fechas (normalmente usadas como filtro de CALCULATE)
Las que evalúan una expresiónPatrones comunes con CALCULATE, muy útiles para resolver buena parte de los escenarios de tiempo.
Resolución de escenarios con importes que no son sumables, como lo hacen por defecto las medidas. Creación de “SEMI-ADDITIVE MEASURES”
Todos los apartados son importantes, pero quizás este, por su especial contenido adquiere mayor relevancia y será de más amplia aplicación en todos los modelos.
Hola Miguel,
Agradezco el comentario y me alegro que puedan servir de ayuda.
Ánimo y seguimos.
- Sólo cuando tengamos cargado el modelo y empecemos a analizar los datos, nos daremos cuenta de la importancia que tiene este apartado. Dominar las posibilidades que nos ofrece Power Query y entender cómo funciona el lenguaje M nos dará ventaja en la fiabilidad de los resultados frente a otros que puedan saltarse el paso de la “transformación” y “limpieza”.
- Diferencia entre MERGE y APPEND. Posibilidad de realizar un JOIN con múltiples columnas.
- Diferencia entre TRANSPOSE y UNPIVOT. Muy importante cuando recibimos datos con formatos heredados de excel para seguimiento mensual de alguna métrica.
- Me ha permitido aclarar dudas respecto al funcionamiento de “Refresh”, cuando la tabla no se carga. Qué ocurre si se utiliza para mantener otra tabla del modelo, a pesar de no tener activada la opción de Refresh. El hecho de que la opción quedara ensombrecida pero activada me generaba confusión.
- La gestión de los errores es muy importante, tenerlos controlados y saber como tratarlos es crucial para nos desvirtuar nuestros datos.
Cualquier detalle que ayude a ampliar nuestra habilidad con Power BI ayudará en los desarrollos futuros y en adaptar a los ya existentes.
A por más.
Un saludo a tod@s
