Buscando sugerencias sobre el modelo de datos para una pantalla PnL

[Syndicate_Admin]

Hola a todos

Tengo una tabla contabilidad con un número significativo de filas

La administración está buscando un PnL PERO la secuencia y los valores no son simples suma en este libro mayor

1) quieren mostrar cuenta / subcuenta, pero no folllwing COA

2) quieren agrupar algunas subcuentas o dividir algunas de ellas usando otra dimensión

3) algún detalle no viene del Libro Mayor, sino de otras fuentes

Logré encontrar una solución usando una tabla de configuración. En esta tabla, enumeraría todos los criterios de filtro y dónde mostrar en la tabla PnL

ex:

| de cuentas | de subcuenta (canal) .... | displayAccount | displaySubAccount (| .... |

| automatizado | al por menor .... | | de ingresos sin conexión

| automatizado | de mercado .... | | de ingresos en línea

En aras de la simplicidad, me salto la parte donde necesito mostrar el resultado en diferentes monedas, etc ...

A continuación tengo un conjunto de medidas que aplicará el filtro calcular la cantidad correcta.

Funciona.

pero mi problema ahora es que puede tardar hasta 1 minuto en actualizar los datos, lo mismo si cambio el período de tiempo o cambio otra segmentación de datos

si entiendo correctamente la tabla extensible que crea Power BI, significa que ya sea que filtre en la columna de la tabla de dimensiones O en la columna de la tabla de hechos, el rendimiento sería el mismo?!

Supongo que debido a que no tengo relaciones entre mi tabla de configuración y mi libro mayor, aquí es donde es propbably no óptimo como filtro no se propaga en mi tabla de contabilidad.

Pensé en construir alguna relación, pero se vuelve "compleja", ya que necesitaría 10ish nuevas tablas de dimenship + 20 relación (2 para cada tabla de "filtro" de mi tabla de configuración).

Esto para sólo uno de los PnL necesito para construir un informe.

Tabla de configuración <---- tabla DimFilterTable[1,2,...,10] ---> Ledger

Entiendo que debería preparar mis datos mucho mejor en el datawarehouse para que el cálculo de PBI se mantenga simple.

Pero para otras consideraciones, me gustaría ver si no hay ninguna "mejora" que podría hacer en la forma en que produzgo mi PnL antes de adoptar una estrategia completamente diferente.

Lo siento, no puedo compartir datos más particulares, pero espero que mi explicación sea suficiente.

Gracias de nuevo por leer este poste. Gracias aún más si tienes alguna sugerencia 😉

saludos

sangre

[Syndicate_Admin · Accepted solution]

@sangdelattre,

Las relaciones entre las tablas de hechos y de dimensiones son esenciales para la optimización. Es preferible filtrar las columnas de las tablas de dimensiones en lugar de las tablas de hechos. La tabla de configuración es una buena solución para crear agrupaciones que no existen en la tabla COA. La tabla COA tendría una relación con las tablas de configuración y de hechos. Los objetos visuales usarían columnas en la tabla de configuración. Por ejemplo, podría colocar Configuration[displayAccount] en una matriz (filas) y eso segmentaría la tabla de hechos por Revenue.

Se pueden crear agrupaciones adicionales como columnas adicionales en la tabla de configuración, si se basan en la misma dimensión subyacente o combinación de dimensiones. Si se requiere una agrupación basada en la combinación de SubAccount y Department, por ejemplo, crearía una segunda tabla de configuración.

En cuanto a algunos detalles procedentes de otros orígenes, tendría varias tablas de hechos y cada tabla de hechos tendría una relación con el COA y las tablas de configuración. Cree medidas para cada tabla de hechos y, a continuación, una medida general que resuma la medida de cada tabla de hechos. ejemplo:

Total Amount = [FactTable1 Amount] + [FactTable2 Amount]