Validación — Facturación

Uso interno. No exponer como material para stakeholders.

Estado

• Última actualización: 2026-08-02
• Owner: Desarrollo / documentación

Ciclo mensual — resuelto por operación

2026-08-02. Operación entregó la secuencia real de comandos de los días 1 y 4. El documento Ciclo mensual de facturación se reescribió con ella y sigue en Pendiente de revisión SME solo por las preguntas que quedan abajo.

Preguntas cerradas con esa entrega:

Pregunta previa	Respuesta
¿Cómo se separa costo fijo de pass-through el día 1?	Se usa file:statement-account por RMU, no run:statement-account.
¿passthrough:estimated entra en el ciclo?	Sí, en el día 4, antes de generar el estado de cuenta.
¿dispatch:calculations entra, y en qué punto?	Sí, es el primer paso del día 4.
¿El orden importa?	Sí. La secuencia del día 4 es estricta.
¿calculate:by-passthrough se usa?	No aparece en el procedimiento real. Se usan los dispatch:* y passthrough:estimated.
¿Qué hace validate:rates?	Es la revisión final: imprime el desglose por concepto de cada estado de cuenta del mes. No valida tarifas de CFE.

Preguntas abiertas

#	Pregunta	Por qué importa
1	¿Por qué dispatch:calculations, distribución, MDA y MTR arrancan dos días antes del inicio del mes, mientras ancho de banda y congestión usan el mes calendario? ¿El desfase es fijo?	Recortar el rango produciría un cierre incompleto; nadie sabría por qué.
2	¿Qué criterio define qué centros de carga reciben ancho de banda y congestión?	Hoy es conocimiento de quien ejecuta el cierre, no del sistema. Es el punto más frágil del ciclo.
3	¿Se recorren todos los centros de carga uno por uno con file:statement-account, o hay una lista acotada?	Determina el esfuerzo real del cierre y si conviene usar run:statement-account.
4	¿Cuánto hay que esperar entre despachar los cálculos y generar el estado de cuenta? ¿Cómo se confirma que las colas terminaron?	Generar antes de tiempo produce importes incompletos sin error.
5	¿Cuál es el procedimiento ante una reliquidación de un periodo ya facturado?	Sigue sin existir.
6	¿Cuánto tarda cada día del ciclo?	Sin línea base no hay criterio para saber cuándo algo va mal.
7	¿Alguien revisa la salida de validate:rates antes de emitir?	No hay control de cuatro ojos documentado.

Discrepancia — comandos de tarifas CFE

Detectada: 2026-08-02.

Operación ejecuta en producción dos comandos de cfe-rates-microservice:

• app:import-rates-from-csv --filename=
• app:calculate-rate-command --rmu= --period= --owner=

Ninguno de los dos existe en la rama principal de ese repositorio, verificado contra origin/main. El repositorio solo declara app:ask-bot-cfe-rates, y el cálculo de tarifas existe ahí como acción de API, no como comando de consola.

Hipótesis: trabajo sin integrar a la rama principal, o un despliegue productivo que difiere del repositorio.

Pendiente: confirmar con desarrollo dónde vive el código que corre en producción. Mientras tanto, ambos comandos están documentados según la operación, marcados como no verificados.

Hallazgos confirmados en código

Verificados contra el repositorio y ya reflejados en la documentación publicada:

• El sistema exige exactamente un contrato activo por centro de carga y periodo. Con cero o con más de uno, ese centro no genera estado de cuenta y se notifica al administrador.
• run:statement-account sin --year/--month usa el mes anterior al día de ejecución.
• Los tipos de producto son fixed, fixed-with-energy-loss y pass-through. Los dos primeros usan el constructor de costo fijo.
• Cada participante tiene una fecha de corte pass-through configurable, con valor por omisión de 3 días, que desplaza la ventana de búsqueda de ECD por fecha de emisión. Explica por qué el ciclo pass-through corre el día 4.
• dispatch:calculations excluye ciertos slugs de cálculo según el participante. Es intencional y refleja diferencias de modelo de negocio.
• Las reglas fiscales de los comprobantes a CENACE están codificadas, no configurables: cambiarlas requiere despliegue.

Gaps abiertos

Gap	Detalle	Quién lo cierra
Lista de centros con ancho de banda y congestión	Vive fuera del sistema, en el procedimiento de quien ejecuta el cierre. Si se omite un centro, su estado de cuenta sale sin ese concepto y solo se detecta revisando el desglose.	Operación / Desarrollo
Registro manual de tarifas CFE	Depende de que alguien obtenga el CSV de CFE y lo cargue. Sin alerta si falta.	Operación
Idempotencia	No está confirmado qué comandos se pueden repetir sobre un periodo ya procesado. Es el dato que más falta al operar.	Desarrollo
Reversión	No hay procedimiento de cancelación ni sustitución de CFDI.	Facturación / Desarrollo
Fórmulas	Las fórmulas de cada componente pass-through no están documentadas.	Producto
Fechas de corte reales	Falta confirmar el valor configurado para cada participante productivo.	Operación
Registro de cierres	No hay bitácora de qué se ejecutó en cada cierre mensual.	Operación
Vista de avance	No existe una vista consolidada del estado del cierre.	Desarrollo
Complementos de pago	Flujo no documentado de punta a punta.	Facturación

Riesgos identificados

• Sin reversión. Un error de facturación no tiene ruta de corrección documentada; toda prevención está en la verificación previa con ecd:create_invoice --csv.
• Errores silenciosos. Demanda o energía incompletas producen importes menores sin generar ningún error.
• Traslape de contratos. Es la causa más frecuente de centros de carga sin facturar, y no hay validación preventiva antes del cierre.