Lago 1.51 en cooperativas: consumos, facturas y salida
Mini-caso para cooperativas con servicios variables: eventos de consumo, planes, facturas, permisos y exportación probada.
Un medidor rural cerró julio con 37 eventos y dos facturas distintas. En una cooperativa eléctrica con internet rural, el problema aparece cuando el abono fijo, los gigas extra y el ajuste manual pasan por circuitos separados. Lago 1.51.0 permite modelar clientes, planes, eventos de uso e invoices desde una API abierta. Este caso muestra qué cargar, quién revisa y cómo probar la salida.
Dónde aparece la factura partida
La cooperativa puede tener socios con electricidad, internet, instalación, bonificaciones y cargos eventuales. Lago publicó v1.51.0 el 27 de julio de 2026; su repositorio getlago/lago-api figura con licencia AGPL-3.0, 430 estrellas y 183 forks al momento de esta corrida. La cifra muestra actividad visible y código auditable. Dos totales para un mismo socio ya son un reclamo esperando turno. El dato global viene de Stack Overflow 2025 Work: una parte grande de los equipos trabaja con varias aplicaciones al mismo tiempo. Para tesorería, esa dispersión se traduce en eventos de consumo en un sistema, socios en otro y comprobantes en una carpeta. La facturación por uso necesita una cadena escrita desde el evento hasta la invoice final. En el caso de internet rural, esa cadena empieza en la lectura del enlace mensual, sigue por el plan contratado y termina en una factura que tesorería puede explicar con datos y conciliación mensual. En la oficina técnica, una pinza amperométrica con etiqueta amarilla queda guardada arriba de un tablero de baja tensión. El problema operativo es el cargo manual sin rastro: resuelve el mes y deja una diferencia difícil de explicar.
Cómo funciona por dentro
El flujo arranca cuando atención al socio carga cliente, servicio y plan. Lago recibe el alta de cliente y la suscripción; entrega un identificador externo para unir consumos. El sistema de medición o soporte envía eventos con socio, fecha, métrica y cantidad. Lago agrupa esos eventos según el plan, calcula cargos y crea invoices. Tesorería revisa estado, total, descuentos y pagos. Los reportes muestran consumos por cliente o producto. 1. Atención carga socio, plan y fecha de alta. 2. El sistema operativo envía eventos de consumo con identificador externo. 3. Lago valida métrica, suscripción y período. 4. PostgreSQL guarda clientes, planes, eventos procesados, invoices y auditoría. 5. Redis o Valkey ayuda a colas y procesos de fondo. 6. Tesorería revisa invoice, pago y saldo. 7. El backup restaura base, configuración y exportaciones de un período cerrado. La guía de ingestión de uso define eventos destinados a generar invoices auditables. La guía de asignación de plan explica que una suscripción activa genera facturas según el modelo de plan. El objeto invoice deja campos consultables para revisar totales, estados y períodos.
Qué se instala o configura primero
La pila inicial usa Lago v1.51.0, PostgreSQL 15 o superior, Redis 7.x o Valkey 7.2, proxy HTTPS, correo transaccional, backup y monitoreo. La matriz de compatibilidad recomienda PostgreSQL 15+ para versiones recientes y ClickHouse 25.6+ si se activan funciones de analítica avanzada. El primer entregable verificable es un ciclo cerrado con diez socios, dos planes, veinte eventos, tres invoices y exportación revisada fuera de Lago. Con dólar oficial vendedor a ARS 1.510, una instalación chica de USD 40 a USD 90 mensuales queda entre ARS 60.400 y ARS 135.900, sin soporte ni pasarelas. Un piloto de 32 a 48 horas a USD 30/h queda entre USD 960 y USD 1.440, entre ARS 1.449.600 y ARS 2.174.400. Incluye modelo de planes, API de eventos, roles, backup y prueba de exportación. UMSA puede aplicar este patrón cuando una cooperativa o cámara necesita separar cuota fija, cargos variables y pagos sin perder salida. La primera decisión técnica es definir el identificador externo del socio; si cambia cada mes, la factura queda partida desde el origen.
Dónde se rompe y cómo probarlo
El primer riesgo es duplicar eventos. La señal aparece cuando dos invoices incluyen el mismo consumo. La prueba envía el mismo evento dos veces y exige idempotencia o rechazo controlado. El segundo riesgo está en planes mal fechados. La señal es un socio con cambio de abono y cargos del plan anterior. La prueba crea una suscripción, cambia fecha y compara el período facturado contra la regla escrita. El tercer riesgo es cobrar antes de revisar. La señal es una invoice emitida con descuento manual sin aprobador. La prueba exige estado, usuario, motivo y archivo de respaldo antes de marcar pago. El cuarto riesgo es una salida incompleta. La prueba exporta clientes, suscripciones, invoices y eventos del mes; después abre los archivos fuera de Lago y compara totales contra reportes. La cooperativa aprende rápido si el dato pertenece al sistema o al operador que recuerda la excepción de mostrador.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.