Hablaremos de una función DAX para PowerPivot muy interesante, CROSSFILTER, que nos permite 'saltarnos' las relaciones existentes en nuestro modelo de datos.
La sintaxis de la función es:
CROSSFILTER(columna 1, columna 2, dirección)
siendo:
columna1: Nombre de una columna existente, con la sintaxis DAX estándar y completo, que normalmente representa el lado "varios" de la relación que se va a usar. Si los argumentos se proporcionan en orden inverso, la función los intercambia antes de usarlos. Este argumento no puede ser una expresión.
columna2: Nombre de una columna existente, con la sintaxis DAX estándar y completo, que normalmente representa el lado "uno" o de búsqueda de la relación que se va a usar. Si los argumentos se proporcionan en orden inverso, la función los intercambia antes de usarlos. Este argumento no puede ser una expresión.
Dirección: Dirección del filtro cruzado que se va a usar. Debe ser una de las siguientes:
ninguna: No se produce ningún filtrado cruzado en la relación.
One Way: los filtros en el lado "uno" o de búsqueda de la relación filtran el lado "varios".
Both: los filtros de cualquier lado filtran el otro.
None: no se produce ningún filtrado cruzado en esta relación.
A tener en cuenta!!
La función no devuelve ningún valor!, solo establece la dirección del filtrado cruzado de la relación indicada mientras dura la consulta.
En el caso de una relación 1:1, no hay ninguna diferencia entre las direcciones One Way y Both.
CROSSFILTER solo se puede usar en funciones que toman un filtro como argumento, por ejemplo: funciones CALCULATE, CALCULATETABLE, CLOSINGBALANCEMONTH, CLOSINGBALANCEQUARTER, CLOSINGBALANCEYEAR, OPENINGBALANCEMONTH, OPENINGBALANCEQUARTER, OPENINGBALANCEYEAR, TOTALMTD, TOTALQTD y TOTALYTD.
Si las expresiones de CALCULATE están anidadas y más de una expresión de CALCULATE contiene una función CROSSFILTER, la instancia de CROSSFILTER más interna es la que prevalece en caso de conflicto o ambigüedad.
Veamos algunos ejemplos sobre el siguiente Modelo de datos:
Notemos las relaciones creadas entre las tablas:
TblProducto y TblPdtoPrecio
TblIVA y TblClientes
(marcadas en rojo en la imagen).
Como se ve, el sentido de la relación es contrario al habitual... No importan ahora los motivos de esta definición.
La hipótesis es que estos sentidos no se pueden cambiar ya que podrían cambiar ciertos cálculos, o simplemente porque no está permitido ;-).
Lo que aprenderemos hoy, usando CROSSFILTER, es la forma de 'saltarse' los sentidos definidos de dichas relaciones.
Para el primer ejemplo definiremos la siguiente medida:
Pz_Venta:=sumx(TblVentas;TblVentas[Unidades]*TblVentas[Precio Venta unitario])
Es una simple medida que calcula el producto de 'Unidades' por el 'Precio Venta Unitario', ambos valores de la 'TblVentas'.
El problema surgiría si tuviéramos que resumir la información de estas Ventas por un campo de la 'TblDirector' (tabla con la 'relación invertida'), ya que veríamos la siguiente tabla dinámica:
Además de obtener un 'error de relaciones' en la tabla dinámica, comprobamos fácilmente como el resultado obtenido no responde a lo buscado, ya que repite el importe global en todos los 'Directores'...
La solución pasa por emplear CROSSFILTER para recomponer solo para este cálculo la relación.
Crearemos una nueva medida:
TotalVentasCROSS:=CALCULATE([Pz_Venta];CROSSFILTER(TblDirector[Cod país];TblPais[Cod país];Both))
en este caso apoyándonos en el cálculo de la medida anterior [Pz_Venta].
Si llevamos nuestra nueva medida a la tabla dinámica comprobamos como el resultado se ajusta a la realidad!
Veamos un segundo ejemplo donde aplicaremos CROSSFILTER para montar un informe que muestre los PVP (Precios con IVA incluido) para cada Zona.
Añadimos una primera medida:
PVP:=SUMX(TblVentas;[Pz_Venta]*(1+RELATED(TblIVA[%IVA])))
Y una segunda medida, de manera similar al primer ejemplo, basado en la medida [PVP]
PVP_CROSS:=CALCULATE([PVP];CROSSFILTER(TblDirector[Cod país];TblPais[Cod país];Both))
Al generar la tabla dinámica en la hoja de cálculo con esas medidas verificamos el dispar comportamiento de una y otra...
Únicamente al usar en nuestra medida la función CROSSFILTER obtenemos el dato cruzado correcto para las Zonas de ventas...
Se observa que solo cuando están involucrados campos, de las distintas Tablas de nuestro modelo de datos, por la 'relación inversa' tiene sentido aplicar la función CROSSFILTER en nuestras medidas...
La sintaxis de la función es:
CROSSFILTER(columna 1, columna 2, dirección)
siendo:
columna1: Nombre de una columna existente, con la sintaxis DAX estándar y completo, que normalmente representa el lado "varios" de la relación que se va a usar. Si los argumentos se proporcionan en orden inverso, la función los intercambia antes de usarlos. Este argumento no puede ser una expresión.
columna2: Nombre de una columna existente, con la sintaxis DAX estándar y completo, que normalmente representa el lado "uno" o de búsqueda de la relación que se va a usar. Si los argumentos se proporcionan en orden inverso, la función los intercambia antes de usarlos. Este argumento no puede ser una expresión.
Dirección: Dirección del filtro cruzado que se va a usar. Debe ser una de las siguientes:
ninguna: No se produce ningún filtrado cruzado en la relación.
One Way: los filtros en el lado "uno" o de búsqueda de la relación filtran el lado "varios".
Both: los filtros de cualquier lado filtran el otro.
None: no se produce ningún filtrado cruzado en esta relación.
A tener en cuenta!!
La función no devuelve ningún valor!, solo establece la dirección del filtrado cruzado de la relación indicada mientras dura la consulta.
En el caso de una relación 1:1, no hay ninguna diferencia entre las direcciones One Way y Both.
CROSSFILTER solo se puede usar en funciones que toman un filtro como argumento, por ejemplo: funciones CALCULATE, CALCULATETABLE, CLOSINGBALANCEMONTH, CLOSINGBALANCEQUARTER, CLOSINGBALANCEYEAR, OPENINGBALANCEMONTH, OPENINGBALANCEQUARTER, OPENINGBALANCEYEAR, TOTALMTD, TOTALQTD y TOTALYTD.
Si las expresiones de CALCULATE están anidadas y más de una expresión de CALCULATE contiene una función CROSSFILTER, la instancia de CROSSFILTER más interna es la que prevalece en caso de conflicto o ambigüedad.
Veamos algunos ejemplos sobre el siguiente Modelo de datos:
Notemos las relaciones creadas entre las tablas:
TblProducto y TblPdtoPrecio
TblIVA y TblClientes
(marcadas en rojo en la imagen).
Como se ve, el sentido de la relación es contrario al habitual... No importan ahora los motivos de esta definición.
La hipótesis es que estos sentidos no se pueden cambiar ya que podrían cambiar ciertos cálculos, o simplemente porque no está permitido ;-).
Lo que aprenderemos hoy, usando CROSSFILTER, es la forma de 'saltarse' los sentidos definidos de dichas relaciones.
Para el primer ejemplo definiremos la siguiente medida:
Pz_Venta:=sumx(TblVentas;TblVentas[Unidades]*TblVentas[Precio Venta unitario])
Es una simple medida que calcula el producto de 'Unidades' por el 'Precio Venta Unitario', ambos valores de la 'TblVentas'.
El problema surgiría si tuviéramos que resumir la información de estas Ventas por un campo de la 'TblDirector' (tabla con la 'relación invertida'), ya que veríamos la siguiente tabla dinámica:
Además de obtener un 'error de relaciones' en la tabla dinámica, comprobamos fácilmente como el resultado obtenido no responde a lo buscado, ya que repite el importe global en todos los 'Directores'...
La solución pasa por emplear CROSSFILTER para recomponer solo para este cálculo la relación.
Crearemos una nueva medida:
TotalVentasCROSS:=CALCULATE([Pz_Venta];CROSSFILTER(TblDirector[Cod país];TblPais[Cod país];Both))
en este caso apoyándonos en el cálculo de la medida anterior [Pz_Venta].
Si llevamos nuestra nueva medida a la tabla dinámica comprobamos como el resultado se ajusta a la realidad!
Veamos un segundo ejemplo donde aplicaremos CROSSFILTER para montar un informe que muestre los PVP (Precios con IVA incluido) para cada Zona.
Añadimos una primera medida:
PVP:=SUMX(TblVentas;[Pz_Venta]*(1+RELATED(TblIVA[%IVA])))
Y una segunda medida, de manera similar al primer ejemplo, basado en la medida [PVP]
PVP_CROSS:=CALCULATE([PVP];CROSSFILTER(TblDirector[Cod país];TblPais[Cod país];Both))
Al generar la tabla dinámica en la hoja de cálculo con esas medidas verificamos el dispar comportamiento de una y otra...
Únicamente al usar en nuestra medida la función CROSSFILTER obtenemos el dato cruzado correcto para las Zonas de ventas...
Se observa que solo cuando están involucrados campos, de las distintas Tablas de nuestro modelo de datos, por la 'relación inversa' tiene sentido aplicar la función CROSSFILTER en nuestras medidas...
No hay comentarios:
Publicar un comentario
Nota: solo los miembros de este blog pueden publicar comentarios.