Skip to content

Changelog de sy-energy

2026-08-02 (segunda entrega)

Actualizado

  • Ciclo mensual de facturación: reescrito con la secuencia real de comandos entregada por operación, para el día 1 (costo fijo) y el día 4 (pass-through), incluido el paso previo de tarifas CFE en cfe-rates-microservice.

Corregido

  • validate:rates no valida tarifas de CFE. Imprime el desglose por concepto de cada estado de cuenta generado del mes — transmisión, administrativo, potencia MTR y MDA, pérdidas, capacidad, congestión y total — y es el paso de revisión final de ambos días del ciclo.

Confirmado por operación

  • El cierre usa file:statement-account por RMU, no run:statement-account.
  • dispatch:calculations es el primer paso del día 4.
  • calculate:by-passthrough no forma parte del procedimiento real.
  • Distribución, MDA y MTR se calculan con un rango que arranca dos días antes del inicio del mes; ancho de banda y congestión usan el mes calendario.
  • Ancho de banda y congestión se despachan solo para ciertos centros de carga, con una lista que vive fuera del sistema.

Pendiente

  • Confirmar por qué el rango extendido arranca dos días antes.
  • Formalizar la lista de centros de carga con ancho de banda y congestión.
  • Aclarar dónde vive el código de app:import-rates-from-csv y app:calculate-rate-command: no están en la rama principal de cfe-rates-microservice.

2026-08-02 (primera entrega)

Reescritura completa de la documentación contra el código del repositorio, que hasta ahora no estaba disponible localmente.

Agregado

  • Ciclo mensual de facturación: procedimiento del día 1 (contratos de costo fijo) y del día 4 (contratos pass-through), con precondiciones, validaciones, qué hacer si algo falla y las preguntas abiertas que faltan por confirmar.
  • Sección de ecosistema fuera de sy-energy: mapa general, inventario de sistemas y calendario operativo.

Actualizado

  • Scheduler y batch: se documentaron las 9 tareas programadas reales con su hora, comando, log destino y encadenamiento. Se explicó el desfase de 5 días de la sincronización de ECD.
  • Comandos operativos: se pasó de 7 comandos marcados "pendiente SME" a más de 45 comandos con su firma y descripción reales, agrupados por dominio y con advertencias sobre los que escriben datos o emiten documentos fiscales.
  • Bots y automatizaciones: se documentaron los 6 bots del SIM, su mecanismo vía cola, el orden obligatorio de las etapas bancarias y por qué las notificaciones deben correr primero.
  • Runbook de operación diaria: revisión en cuatro niveles con los logs reales del sistema y acciones correctivas concretas.
  • Overview: arquitectura, tecnologías, integraciones, ambientes y variables reescritos contra el repositorio.
  • Módulos: clientes y participantes, centros de carga, demanda, ECD/CENACE, CFDI y billing.
  • Facturación: proceso end-to-end, CFDI y Factura.com, billing pass-through y documentos financieros.
  • Troubleshooting: los cinco playbooks reescritos con síntomas, diagnóstico y recuperación reales.
  • Validaciones internas: gaps, riesgos y preguntas abiertas por dominio.

Corregido

  • El inventario de tecnologías describía un stack de React, Vite, TypeScript y Supabase que no corresponde a sy-energy. El sistema es Laravel 13 sobre PHP 8.5 con MySQL y AWS. La misma información incorrecta afectaba integraciones externas y variables por ambiente.
  • El scheduler figuraba como "pendiente de confirmar existencia".
  • Se registró la naturaleza multi-participante del sistema, ausente de la documentación previa y con impacto operativo directo.

Hallazgos documentados

  • La fecha de corte pass-through es configuración por participante, con valor por omisión de 3 días. Explica por qué la facturación pass-through corre el día 4.
  • El sistema exige exactamente un contrato activo por centro de carga y periodo; es la causa más frecuente de centros sin facturar.
  • dispatch:calculations excluye ciertos cálculos según el participante, de forma intencional.

Pendiente

  • Validar con operación la secuencia real del ciclo mensual de facturación.
  • Confirmar qué comandos son idempotentes.
  • Documentar el procedimiento ante reliquidaciones y ante cancelación de CFDI.
  • Documentar el modelo de datos.

2026-05-13

Agregado

  • Estructura inicial de documentación para sy-energy.
  • Dashboard documental con estado por sección.
  • Documentos base de primera fase para overview, operación, módulos críticos, facturación, troubleshooting y validaciones internas.