¿Quién no ha trabajado en modelos semánticos con orígenes de datos de mucha interacción manual? seguramente hay reportes en casi todas las empresas que tienen algún origen de excel u otra fuente que tiene mucha manipulación. Para estos casos, suele suceder que las actualizaciones tienen fallas muy frecuentes.

Cambian el nombre de una columna, la borran, ponen mal los datos, etc. Todo esto puede romper nuestras actualizaciones programadas. En este artículo, te muestro como evitar que la actualización se rompa y alertes en el reporte que hay un problema en los datos detallando cual es para que los usuarios que cargan los datos puedan tomar ownership en el asunto.

Comenzaremos el post destacando que esta estrategia esta enfocada en escenarios de tableros que tienen mucha manipulación manual y generan errores frecuentemente. Lo que vamos a ver a continuación, no sería necesario en un escenario ideal con datos que provienen de un data warehouse o lakehouse ya procesados y con controles que aseguran que los datos mantengan su formato, tipo y esquema.

El problema surge cuando trabajamos con orígenes manuales. Los usuarios que cargan los datos difícilmente sigan siempre las prácticas recomendadas. Esto afectará las actualizaciones.

La solución implica que las actualizaciones no fallen, sino más bien alerten en el reporte si hay un fallo y que sea posible ver los detalles. El resultado sería algo así:

Solución

Para comenzar veamos nuestro modelo semántico:

Una estrella sencilla y una tabla errores desconectadas. Para construir esto iniciemos ajustando nuestro Transform Data, el espacio de power query para que capture errores. Vamos a armar grupos. Primero vamos a definir a nuestras tablas manuales actuales limpias bajo el grupo de staging. Podemos poner prefijo "stg_". A partir de esa tabla crearemos dos tablas más que la llamen. Una bajo el grupo Dimensiones o Hechos (dependiendo como hayan modelado) y otra bajo errores. Nos quedaría algo así:

Si bien el hecho de Ventas y el Error ERR_Ventas comenzarán igual haciendo de su paso origen STG_Ventas, el segundo paso marcaría la diferencia.

• El segundo paso de Ventas será seleccionar todas las columnas y "Quitar filas con errores". Nuestra tabla no fallará porque quitaremos los errores que hayan ocurrido en la limpieza o transformaciones.
• El segundo paso de ERR_Ventas será el contrario. Seleccionamos todas las columnas y ponemos "Conservar filas con errores" para analizarlas.

Nuestro Hecho Ventas esta listo. Pero la de errores no. Para poder ajustar la tabla de filas con errores, vamos a utilizar una función personalizada de power query que les dejo a continuación.

La pueden copiar de mi GitHub. La función pivoteará todos los valores de las columnas para buscar los errores y expandirlos dando más información, así también prevendría que falle esa actualización. Para cargarla pueden obtener datos de una consulta en blanco y pegarla.

Gracias a esta función podemos simplemente llamarla y solo nos resolverá darnos una tabla que tenga el nombre de la columna que falla, el valor que esta fallando y mensajes adicionales para dar contexto de la falla.

Si vamos a realizarlo sobre muchas tablas, les sugiero que el último paso sea crear una columna personalizada con el nombre de la tabla. De esa forma podremos unirlas a todas, puesto que tienen el mismo formato, en una sola tabla de errores que se vería así:

Antes de terminar, vamos a dar click derecho en las tablas con prefijo STG y ERR para quitar su carga. "Enable load". Vamos a prevenir que se carguen en nuestro modelo porque confundiría a los usuarios. No es necesario que conozcan esos detalles. El nombre de las tablas saldrá en cursiva si todo se hizo correctamente.

NOTA: Al cargar puede que la combinación de tablas les pida definir el nivel de privacidad de los orígenes, recomiendo usar Organizacional para todas las tablas.

De esta forma tenemos nuestro modelo que captura errores y evita la falla de una actualización. Pero esto no termina aún, falta lo más importante. Lo importante es alertar al usuario al respecto puesto que no vamos a recibir un correo de una falla de carga de datos pero si pueden suceder errores. Para generar el efecto, elegí colocar un botón largo debajo del título y mostrarlo si la tabla errores tiene filas gracias a esta columna:

Luego en el formato de texto del botón le puse en el botón "Fx" para delimitar que use esta medida como texto.

Tan importante como alertar es mostrar porque falló. Esto lo lograremos creando una página oculta a la vista del usuario. La misma solo se accederá con este botón. Sin embargo, para mejorar la experiencia, solo debería ser posible el ingreso si el mensaje sale. Si no tenemos errores y hay un cuadrado blanco, no deberíamos poder tocar el botón e ir a la página de errores vacía. Esto lo conseguiremos con la siguiente medida:

Esta medida la usaremos en el apartado de Acción de nuestro botón. Usaremos la acción de navegación de página y de nuevo el botón "FX" para poner la medida. Nuestra página oculta se llama "Errores", entonces cuando la condición falle y existan errores la función de navegación no intentará ir a "" sino a "Errores". Así el usuario navegará a una página donde podemos poner una tabla que muestre los errores por Tabla:

Así rápidamente el usuario que tiene acceso a los excels puede ver fechas y montos que fallaron. Esos no son parte de ventas ni compras por los errores que menciona. Ahora el usuario puede ir al excel a buscar las fallas para corregirlas.

Eso sería todo. Ojala esto los ayude a los usuarios manuales a involucrarse más en la carga consiente de datos y fomentemos una mejor experiencia de usuario. Pueden encontrar el pbix de ejemplo en este link.