Rentabilidad por SQL
Diez mil líneas de venta y una pregunta: qué se vende mucho y deja poco.
Datos y BI · SQL · Demo navegable
El problema
Facturar no es ganar. Casi todo negocio tiene una familia de producto que llena el escaparate y vacía el margen, y otra que sostiene la cuenta sin que nadie la mire. Eso no se ve en el total: se ve al cortar por producto, por región y por quién la vende.
Qué hace
- Genera un conjunto de ventas reproducible con su script, para que el análisis se pueda repetir entero.
- Cinco consultas planas sobre SQLite, sin uniones ni subconsultas: agregación, agrupación y orden.
- Corta la rentabilidad por región, vendedor, categoría, tipo de cliente y mes.
- Deja la salida preparada para Power BI.
Lo que se decidió al construirlo
- El panel lee las consultas, no una copia
- El exportador abre el propio fichero de consultas y las ejecuta sobre el mismo conjunto de datos que publica el repositorio. Si alguien cambia una consulta, el panel cambia con ella. Una copia pegada en el script acabaría, tarde o temprano, enseñando un número que la consulta ya no da.
- El margen sale de los totales, no del promedio de promedios
- El margen de cabecera se calcula sobre la suma del beneficio y la suma del ingreso, no promediando los márgenes de cada región. Promediar promedios da otro número, igual de creíble y equivocado, y es el error más repetido de cualquier informe de rentabilidad.
- El troceador entiende los comentarios
- La última consulta termina con un comentario detrás del punto y coma, y partir el fichero por ese carácter convertía el comentario en una sexta consulta fantasma. Hay una prueba que lo fija, porque el fallo no se ve: produce una consulta vacía que no rompe nada y descuadra el recuento.
- El motor se declara: es SQLite
- La consulta de tendencia mensual usa una función de fecha propia de SQLite, así que estas consultas no son portables sin tocarlas. Decir «SQL estándar» habría sonado mejor y habría sido falso: quien las lleve a otro motor tiene que cambiar esa línea, y conviene que lo sepa antes.
Hasta dónde llega
- Son cinco consultas planas: agregación, agrupación y orden. No hay uniones, ni subconsultas, ni funciones de ventana. El «ranking» de vendedores es un orden descendente con un límite de cinco.
- Los datos son sintéticos y, además, cada columna se sortea de forma independiente. Región, categoría y vendedor no guardan relación con el importe: qué región es más rentable es ruido de muestreo, no un hallazgo.
- La consulta de bajo margen no devuelve ninguna fila con estos datos, porque el umbral queda por debajo del beneficio medio que genera el script. Se publica el contexto para que se vea, en lugar de ajustar el umbral hasta que salga algo.
- El generador de datos escribe en una ruta absoluta de la máquina donde se escribió y no fija la semilla de las fechas: el conjunto publicado es reproducible, volver a generarlo tal cual no lo es.
- 10.000 líneas de venta
Construido con
- SQL
- Python
- Power BI
De dónde salen los datos
Datos sintéticos generados por el propio repositorio: no hay información de ningún cliente.