Energía 121/2026: bonificación, factura y tablero
La prórroga de bonificaciones SEF obliga a revisar cuadros tarifarios, facturación, padrón, evidencia y permisos antes de liquidar consumos de junio.
¿Qué debería registrar una cooperativa cuando Energía cambia el porcentaje de bonificación de una factura? La pregunta cae sobre gerencias chicas, áreas comerciales y sistemas que liquidan consumos con padrones, cuadros tarifarios y reclamos abiertos. La Resolución 121/2026 prorrogó y cambió bonificaciones SEF para junio; esta nota explica qué dato guardar, quién lo aprueba y cómo probar el tablero antes de facturar.
Qué cambia en la factura de junio
La Resolución 121/2026 fue publicada el 28 de mayo de 2026. Prorrogó para junio la bonificación adicional del 25% sobre consumo de gas natural y gas propano por redes para beneficiarios SEF. También fijó una bonificación adicional del 11,97% para electricidad, en reemplazo de la prevista para el mismo mes.
La cifra corrige una rutina que suele quedar pegada a la factura anterior. Si el sistema liquida con un porcentaje viejo, el error no aparece en una sola boleta: se replica por categoría, período, medidor y padrón. El Decreto 943/2025 creó el régimen SEF y ordenó criterios para consumos residenciales vulnerables; la resolución de mayo mueve el cálculo que las distribuidoras deben trasladar.
La factura quedó bajo control de fechas, porcentajes y responsables.
La referencia técnica viene de una base conocida. Stack Overflow 2024 registró PostgreSQL con 48,7% de uso entre desarrolladores y lo ubicó como la base más usada por segundo año. Para una cooperativa cuyana, esa adopción importa porque permite guardar padrón, período, categoría, consumo, bonificación y auditoría con una tecnología que no depende de un proveedor raro.
El antagonista operativo es la planilla de cuadros tarifarios sin versión. Alguien la descarga, alguien la corrige y alguien la pega en el sistema. Si esa planilla no deja firma, fecha y origen normativo, cada reclamo obliga a reconstruir el cálculo. La Resolución 26/2026 del ENREGE muestra el mismo problema en escala regulatoria: cuadros, topes, bonificaciones y vigencia deben convivir en una liquidación verificable.
Cómo funciona por dentro
El flujo empieza en el padrón comercial. El usuario carga o importa medidor, titular, categoría, consumo base, período de facturación y condición SEF. La aplicación valida formato, fecha de vigencia y fuente normativa antes de calcular el importe. PostgreSQL guarda registros estructurados: usuario, medidor, consumo, porcentaje aplicado, norma usada, estado de aprobación y auditoría.
Un módulo de cálculo toma esos datos y entrega el detalle de factura. Metabase lee una vista de solo lectura y muestra cantidades por categoría, total bonificado, facturas pendientes y diferencias contra el período anterior. GLPI o una mesa de ayuda recibe reclamos con número de factura y medidor; no calcula tarifas, pero deja dueño, prioridad y cierre del incidente.
Los permisos separan acciones. Comercial puede cargar consumos y ver facturas propias. Administración puede aprobar el cuadro tarifario de un período. Sistemas puede restaurar base, revisar logs y bloquear una versión, pero queda fuera de la edición comercial. El backup copia base, archivos de cuadro tarifario y reportes emitidos; la restauración prueba una factura real y compara porcentaje, importe y usuario aprobador.
La alerta mínima muestra tres señales: porcentaje fuera de vigencia, factura aprobada sin norma asociada y reclamo con cálculo distinto al registro original. Esa alerta evita que el soporte responda con capturas sueltas.
Qué se instala o configura primero
La pila mínima tiene PostgreSQL 17 o 18, un importador de padrón, un módulo de reglas tarifarias, Metabase para tableros y un repositorio de documentos de soporte. En un servidor de 2 vCPU, 4 GB de RAM y 60 GB de disco, el costo mensual ronda USD 18 a 35, entre ARS 25.776 y ARS 50.120 al dólar vendedor de ARS 1.432. Ese costo no incluye horas de ajuste del sistema de facturación ni revisión fiscal.
El primer entregable verificable es una corrida con diez medidores: dos beneficiarios SEF con gas, dos con electricidad, dos sin bonificación, dos reclamos simulados y dos facturas corregidas por una nueva versión de cuadro. UMSA suele pedir que esa prueba tenga captura del cálculo, registro de aprobación y exportación del tablero, porque la discusión útil aparece cuando todos miran la misma base.
La implementación toma de una a tres semanas si el sistema ya exporta consumos. Si los cuadros viven en archivos dispersos, el primer trabajo es cerrar una tabla de vigencias: norma, fecha desde, fecha hasta, porcentaje, categoría y responsable.
Dónde se rompe y cómo probarlo
El primer riesgo es aplicar una vigencia equivocada. La señal aparece cuando una factura de junio usa un porcentaje de mayo. La prueba carga dos períodos y exige que el sistema rechace una regla fuera de fecha.
El segundo riesgo es mezclar padrón y consumo. La señal es una bonificación aplicada a un medidor que no aparece en el padrón vigente. La prueba importa un padrón viejo, liquida una muestra y compara cada factura contra la versión aprobada.
El tercer riesgo es perder evidencia del reclamo. La señal aparece cuando el ticket tiene una captura, pero la base no muestra el cálculo original. La prueba restaura base y documentos en otro servidor, abre cinco facturas y verifica norma, porcentaje, usuario y adjunto.
Si la factura no dice qué regla usó, el reclamo ya empezó tarde.