Demanda

Objetivo

Documentar de dónde sale la demanda eléctrica que usa sy-energy, cómo se procesa y qué hacer cuando falta.

Responsabilidad del módulo

Mantener la demanda de cada centro de carga en las granularidades que necesitan los cálculos y los estados de cuenta.

Audiencia

Operación, soporte y desarrollo interno.

Estado documental

• Estado: Borrador
• Última actualización: 2026-08-02
• Owner: Pendiente
• SME requerido: operaciones / datos
• Fuente resumida: comandos de demanda, servicio de sincronización y configuración de integraciones.

Por qué importa

La demanda es lo que se cobra. Un hueco en la demanda no produce un error visible: produce un estado de cuenta con importe menor al real, y se descubre en el cierre mensual o después.

Fuentes

Fuente	Qué aporta	Cómo llega
Servicio de sincronización de demanda	Demanda de los centros de carga	service:demand-sync, diario a las 06:00
CFE TX	Mediciones de alta tensión cada 5 minutos	Cola SQS alimentada por cfetx-microservice
ECD de CENACE	Energía del mercado por fecha de operación	Módulo de ECD / CENACE

Granularidades

Granularidad	Uso
5 minutos	Dato crudo de medición. Base para reconstruir la demanda horaria.
Horaria	La que usan los cálculos de mercado, que operan por hora.
Mensual	La que consolida el estado de cuenta.

La demanda horaria se puede recalcular a partir de los datos de 5 minutos, lo que permite corregir un periodo sin volver a pedir la información a la fuente.

Comandos

Comando	Uso
service:demand-sync {--rmu=} {--rpu=} {--start_date=} {--end_date=}	Sincroniza la demanda desde el servicio externo. Sin parámetros procesa todo.
demand:fix-hourly {starting_at} {ending_at?} {--rmu=} ⚠️	Recalcula la demanda horaria a partir de los datos de 5 minutos. --rmu acepta varios separados por coma.
demand:monthly {date} {rmu} {--force=} {--retry=} ⚠️	Crea la demanda mensual de un centro de carga. --force la crea aunque exista; --retry la reprocesa.
demand:fixfdp {--rmu=} {starting_at} {ending_at} ⚠️	Corrige el FDP de un centro de carga en un periodo.

Identificadores

Identificador	Qué es
RMU	Identifica el centro de carga en el sistema. Es el parámetro de casi todos los comandos.
RPU	Registro permanente del usuario. Vincula el punto de suministro con la información de CFE.

Un mapeo incorrecto entre RPU y centro de carga hace que la demanda se asigne al centro equivocado. El dato existe, los totales del participante cuadran, y aun así dos clientes reciben importes incorrectos.

Relación con el ciclo mensual

Antes de generar estados de cuenta hay que confirmar que la demanda del mes está completa. Si hay huecos:

php artisan demand:fix-hourly <inicio> <fin> --rmu=<RMU>
php artisan demand:monthly <fecha> <RMU>

Ver Ciclo mensual de facturación.

Errores comunes

Síntoma	Causa probable	Acción
Faltan horas en un día	La sincronización diaria falló o llegó incompleta.	demand:fix-hourly para ese rango.
Falta la demanda de un centro completo	Problema de mapeo o el centro no está en la fuente.	Verificar RMU y RPU.
La demanda mensual no existe	No se generó para ese periodo.	demand:monthly con la fecha y el RMU.
Los importes salen bajos	Demanda incompleta que nadie detectó.	Revisar completitud antes de regenerar el estado de cuenta.
La demanda de alta tensión no llega	La base externa rechaza la conexión por IP no autorizada.	Escalar; requiere autorización del proveedor externo.

Evidencia esperada

• Registro de sincronización del día en el log de servicio.
• Demanda presente para cada centro de carga y cada hora del periodo.
• Sin trabajos fallidos en las colas de demanda.

Riesgos y gaps

• No existe una verificación única de completitud de demanda por periodo; hoy hay que revisar centro por centro.
• No está documentado el margen de tolerancia: cuántas horas faltantes son aceptables antes de bloquear un cierre.
• No hay alerta cuando la sincronización diaria llega incompleta.
• No está documentado el origen de la demanda para cada tipo de centro de carga.

Próxima revisión

Al documentar demand-sync-service y cfetx-microservice.