sy-energy
Sistema central del ecosistema. Administra clientes, centros de carga, contratos y demanda; procesa los Estados de Cuenta Diarios de CENACE; calcula el costo de la energía por centro de carga; y genera los estados de cuenta y los CFDI que se entregan al cliente y se cargan al portal SIM.
Todos los demás sistemas existen para alimentarlo o extenderlo. Ver el mapa del ecosistema.
Sy Energynombra a la empresa y al conjunto de sistemas relacionados.sy-energynombra al sistema específico documentado en esta sección.
Ficha rápida
| Campo | Valor |
|---|---|
| Tipo | Sistema web con procesamiento batch y asíncrono |
| Stack | PHP 8.5 · Laravel 13 · MySQL · MongoDB · Redis · AWS |
| Despliegue | Deployer, una instancia por participante |
| Comandos propios | Más de 45 |
| Tareas programadas | 9 (8 diarias, 1 semanal) |
| Ciclo mensual | Día 1 costo fijo · Día 4 pass-through |
Una instancia por participante
sy-energy se despliega una vez por participante del mercado, cada instancia con su propia base de datos y sus propias colas. Antes de ejecutar cualquier comando, confirmar en qué instancia se está trabajando. Un comando correcto en la instancia equivocada produce datos incorrectos sin reportar error.
Por dónde empezar
| Si eres… | Empieza por |
|---|---|
| Soporte, primer día | Runbook de operación diaria |
| Quien ejecuta el cierre mensual | Ciclo mensual de facturación |
| Desarrollo, onboarding | Arquitectura general |
| Diagnosticando un incidente | Diagnóstico de batch, scheduler y bots |
| Buscando un comando | Comandos operativos |
Estado documental
- Estado general: Borrador
- Última actualización: 2026-08-02
- Audiencia: soporte, infraestructura, desarrollo interno y stakeholders
- Changelog: ver cambios
| Sección | Estado | Verificado contra | Notas |
|---|---|---|---|
| Overview | Borrador | Código | Arquitectura, tecnologías, integraciones, ambientes y variables. |
| Operación | Borrador | Código | Scheduler, comandos y bots reescritos desde el repositorio. |
| Ciclo mensual | Pendiente de revisión SME | Código + operación | El calendario está confirmado; la secuencia de comandos es una propuesta a validar. |
| Módulos | Borrador | Código | Clientes, centros de carga, demanda, ECD/CENACE, CFDI y billing. |
| Facturación | Borrador | Código | Proceso, CFDI, pass-through y documentos financieros. |
| Troubleshooting | Borrador | Código | Playbooks por dominio. |
| Validaciones | Interno | — | Gaps, contradicciones y preguntas abiertas. No exponer a stakeholders. |
Secciones
Overview
- Arquitectura general
- Inventario de tecnologías
- Integraciones externas
- Ambientes y despliegue
- Variables por ambiente
Operación
- Runbook de operación diaria
- Scheduler y batch
- Ciclo mensual de facturación
- Comandos operativos
- Bots y automatizaciones
Módulos
Facturación
Troubleshooting
- Diagnóstico de batch, scheduler y bots
- Incidentes de scheduler y colas
- Incidentes de CENACE / ECD
- Incidentes de CFDI y Factura.com
- Incidentes de demanda
Validaciones internas
Tres cosas que conviene saber antes de operar
1. Encolar no es procesar. Muchos comandos solo publican trabajos en una cola. Reportan éxito aunque ningún worker los procese. Ante un comando que "funcionó" sin efecto, revisar Supervisor.
2. Los procesos trabajan con desfase. La sincronización de ECD pide el documento de hace 5 días, y el cálculo pass-through aplica una fecha de corte configurable. Confundir la fecha de operación con la de ejecución lleva a conclusiones falsas.
3. Los errores de datos son silenciosos. Demanda o energía incompletas no producen errores: producen importes menores a los reales, que se descubren en el cierre o cuando reclama el cliente.
Seguridad documental
Esta documentación no contiene secretos, tokens, credenciales, IPs productivas, URLs privadas ni códigos de participante reales. Los ejemplos usan placeholders como APP_KEY_EXAMPLE, BUCKET_NAME_EXAMPLE o https://example.com.
Al reportar un incidente, sanitizar los fragmentos de log antes de compartirlos: sin credenciales, RFC ni datos personales.