Metabase 59 y PostgreSQL: métricas de cobranza con dueño
Cómo armar métricas de cobranza con Metabase 59 y PostgreSQL: vistas, permisos, definiciones, auditoría y prueba de cierre mensual.
El cierre mensual falla cuando dos reportes calculan “cobrado” con fechas distintas. En un colegio profesional de Cuyo con 1.800 matriculados, ese desacuerdo nace en la definición que alimenta el gráfico. Tesorería mira imputación, administración mira fecha de pago y comisión directiva mira saldo final. Metabase 59 puede ordenar esa conversación si PostgreSQL entrega una fuente común. Esta nota explica cómo viaja la métrica, quién la puede cambiar y qué prueba confirma que el tablero sirve para cerrar el mes.
Dos totales distintos revelan una definición rota
La cifra molesta puede ser chica: una planilla dice $38.214.000 cobrados y el sistema lista $37.846.000 después de notas de crédito y pagos rechazados. Ninguna persona falsificó nada. Cada área recortó el universo con una regla distinta.
Metabase documenta conexiones a bases existentes para consultar datos sin copiarlos a una hoja nueva. En marzo de 2026, Metabase 59 sumó Data Studio y generación de SQL en la edición abierta. La utilidad para una pyme está en una idea concreta: la pregunta guardada reemplaza la captura improvisada.
El dato global ayuda a medir la escala cultural. Octoverse 2025 reportó más de 180 millones de desarrolladores en GitHub y 630 millones de proyectos. Esa masa deja una señal útil para una cámara empresaria: las herramientas abiertas ya son una forma común de revisar cambios, permisos y definiciones.
Una métrica sin dueño es una discusión guardada para el último día del mes.
Cómo viaja una métrica desde PostgreSQL hasta el tablero
El flujo recomendable tiene seis pasos. Primero, el sistema de cobro escribe pagos, notas de crédito, bajas y rechazos en PostgreSQL. Segundo, sistemas crea una vista SQL de solo lectura, por ejemplo cuotas_resumen, con reglas explícitas: fecha de imputación, estado válido, medio de pago y tratamiento de rechazos.
Tercero, Metabase se conecta con un usuario limitado que solo puede leer vistas aprobadas. Cuarto, tesorería arma preguntas guardadas sobre esa vista: cobrado por período, deuda por antigüedad, bajas y excepciones. Quinto, cada pregunta entra a un tablero con permisos por rol. Sexto, el cierre mensual compara ese tablero contra el asiento contable y deja una fecha de aprobación.
PostgreSQL guarda registros estructurados, estados y auditoría del sistema principal. Metabase recibe consultas y entrega preguntas, tableros y enlaces revisables. Los permisos deciden quién ve datos personales, quién arma preguntas y quién publica tableros. El backup recupera base, configuración de Metabase y definiciones guardadas. Si falla la vista, el tablero muestra una cifra mala con aspecto prolijo. Si fallan los permisos, una pantalla compartida puede exponer DNI, deuda o datos de contacto.
La definición escrita de cada métrica sostiene el tablero: qué cuenta como cobrado, qué fecha manda, cómo se tratan notas de crédito y quién aprueba un cambio.
Qué se instala primero para cerrar el mes
Un piloto sobrio usa PostgreSQL como fuente, Metabase 59 para preguntas y permisos, una réplica o usuario de lectura cuando producción no debe recibir carga, y copias verificables. El conector oficial de Metabase con PostgreSQL alcanza para empezar sin mover la base a un SaaS.
El primer entregable debe ser pequeño: cinco preguntas y un tablero de cierre. Cobrado por período, deuda por antigüedad, bajas, medios de pago y excepciones manuales. Cada pregunta tiene dueño y descripción visible. Cada tablero tiene dos perfiles: lectura para comisión directiva y edición para tesorería o sistemas.
El costo de un piloto puede quedar entre USD 900 y USD 2.600, según cantidad de tablas, limpieza de datos, permisos y capacitación. La operación mensual puede ir de USD 20 a USD 80 si se autohospeda con copia externa. Ese costo incluye servidor, mantenimiento básico y prueba de respaldo; no incluye corregir años de datos mal cargados ni unificar sistemas que todavía no comparten identificadores.
UMSA suele pedir un cierre de prueba con dos meses reales. La comparación busca que una persona pueda explicar por qué una cuota entró, quedó pendiente o fue anulada.
Dónde se rompe y cómo probarlo
Primer riesgo: conectar Metabase directo a producción con permisos amplios. La señal es un usuario que puede leer tablas sensibles o ejecutar consultas pesadas. La prueba crea un usuario de solo lectura, mide la consulta más lenta y bloquea acceso a campos personales que no deben mostrarse.
Segundo riesgo: cambiar definiciones sin registro. La señal aparece cuando “moroso” significa 30 días para tesorería y 60 para comisión. La prueba guarda un diccionario de métricas con fecha, responsable y motivo de cambio.
Tercer riesgo: publicar tableros con datos personales. La señal es una pantalla de reunión que muestra DNI o deuda individual. La prueba revisa cada tablero con un perfil de lectura y confirma que la morosidad se agrupa cuando no hace falta detalle nominal.
La prueba mínima compara dos meses contra el cierre contable, revisa usuarios, borra una pregunta duplicada y restaura una copia. Si la reunión deja de pedir una captura nueva, el tablero empezó a trabajar. Si cada cierre exige exportar otro Excel, la métrica todavía no tiene dueño.