Superset en bodegas: tableros, roles y cierre semanal
Caso anonimizado para ordenar cierres comerciales con Apache Superset, PostgreSQL, roles por área, reportes programados y prueba de restauración.
El cierre comercial falla cuando ventas, stock y despacho calculan la misma semana con fechas distintas. En una bodega exportadora de Luján de Cuyo, el reporte del lunes puede mezclar pedidos confirmados, facturas emitidas y pallets todavía retenidos. Apache Superset permite armar tableros sobre PostgreSQL con roles, filtros y reportes programados; este caso muestra qué dato cargar, quién lo ve y cómo probar la salida.
Dónde aparece el tablero con dos números
El encargado de logística mira remitos, reservas de cámara y órdenes de exportación. En la mesa hay una carpeta de remitos con broche metálico y una hoja de cálculo llamada "final_v3". El objeto cuenta la historia: cada área guarda su verdad semanal y después intenta cerrar con una reunión larga. Superset documenta que su instalación con Docker Compose levanta aplicación, base de metadatos PostgreSQL, Redis y workers. También advierte que la base de metadatos guarda tableros, gráficos y usuarios, y que en producción debe respaldarse. Esa línea es concreta para una bodega: perder metadatos significa perder tableros, permisos y reportes, aunque la base comercial siga intacta. El cierre semanal depende de una definición escrita. Stack Overflow 2026 muestra que PostgreSQL fue usado por 57,9% de quienes respondieron sobre bases de datos. El dato no decide la herramienta, aunque explica por qué muchas organizaciones chicas ya pueden consultar ventas, stock y despacho desde una base conocida, sin copiar todo a hojas nuevas cada viernes.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. Primero, el ERP o sistema comercial exporta pedidos, facturas, stock y despacho a tablas o vistas de PostgreSQL. Segundo, PostgreSQL guarda registros estructurados, fechas de corte, estados y auditoría de carga. Tercero, Superset se conecta a esa base con un usuario de lectura y guarda tableros, datasets, permisos y reportes en su base de metadatos. Cuarto, los roles definen quién lee ventas, logística, finanzas o dirección. Quinto, los reportes programados envían PDF, PNG, CSV o XLSX según el gráfico y el canal definido. Sexto, backup y restauración prueban base comercial, metadatos, configuración y capturas de reportes. La frontera de permisos debe quedar visible. Ventas ve clientes, montos y estado comercial. Logística ve bultos, transportista, fechas y despacho. Dirección ve totales y márgenes agrupados. Un usuario de consulta no puede cambiar SQL, conexión ni filtro de seguridad. Superset entrega una vista, no la verdad por sí solo. La regla vive en la consulta: qué fecha define la semana, qué estado cuenta como vendido, qué remito queda pendiente y qué moneda se toma para comparar.
Qué se instala o configura primero
La pila inicial usa Apache Superset, PostgreSQL, Redis, un worker para reportes, SMTP o webhook, proxy TLS, backups y una vista de datos por área. Un servidor con 4 vCPU, 8 GB de RAM y almacenamiento externo puede costar entre USD 40 y USD 95 mensuales; al dólar oficial vendedor de 1.535 pesos, el rango queda entre 61.400 y 145.825 pesos, sin horas de modelado ni limpieza de datos. El primer entregable verificable es un tablero semanal con cuatro vistas: pedidos confirmados, stock disponible, despachos pendientes y facturación emitida. La implementación lleva de dos a cuatro semanas si existen tablas limpias. Si cada área trae archivos con nombres distintos, la primera semana define estados, cortes y responsables de carga. UMSA puede entrar cuando la bodega necesita que el cierre sea repetible. En un caso anonimizado, el cambio útil fue separar datos de negocio, metadatos del tablero y permiso de consulta. Esa separación permitió restaurar un reporte semanal en otro servidor y comparar la misma cifra contra el cierre firmado.
Dónde se rompe y cómo probarlo
El primer riesgo aparece en la fecha de corte. La señal es un pedido contado por ventas y excluido por logística. La prueba ejecuta la misma semana con fecha de pedido, fecha de factura y fecha de despacho; el tablero debe mostrar qué regla usó. El segundo riesgo está en roles. La señal es que logística puede abrir márgenes o finanzas puede editar SQL. La prueba crea usuarios de ventas, logística, dirección y lectura; cada uno intenta ver, editar, exportar y programar reportes. El tercer riesgo vive en reportes programados. La señal es un PDF enviado con datos viejos o con captura incompleta. La prueba fuerza un cambio de datos, ejecuta el worker y compara hora de consulta, archivo enviado y total mostrado. El cuarto riesgo aparece en restauración. La señal es que la base comercial vuelve, aunque Superset pierde tableros y permisos. La prueba restaura metadatos, conexiones y vistas en otro host, abre el tablero y exporta el cierre semanal. Un tablero sirve cuando la discusión cambia de "qué número es" a "qué regla usamos para contarlo".
