Cómo se calcula el avance
El porcentaje de cumplimiento del PDI no se declara: se deriva. Esta página documenta la cadena completa —de la acción a la meta y de la meta al plan—, incluidas las normalizaciones que hace el código y las excepciones que pueden alterar el número que se muestra.
1. Avance de una acción
Cada acción tiene una ponderación (ponderacion_accion, entre 0 y 1) que representa
cuánto pesa dentro de su meta. La suma de las ponderaciones de las acciones de una meta debe dar 1.
El avance se reporta por año del plan y por fecha de corte, en el nodo
avance_accion_anual:
"A-003": {
"ponderacion_accion": 0.5,
"avance_accion_anual": {
"2025-09-11": { "año1": 0 },
"2025-12-16": { "año2": 0.25 },
"2026-03-10": { "año1": 0, "año2": 0.25 } ← último corte: es el que manda
}
}
año2: 0.25
no significa "la acción va al 25 %". Significa que 0,25 del peso total de la meta ya fue
cumplido por esta acción en el año 2. Por eso una acción con ponderación 0,5 nunca puede sumar más de 0,5 entre
sus cuatro años.ultimoCorte = max(keys(avance_accion_anual))
avanceAccion = clamp( Σk=1..4 ultimoCorte["año"+k] , 0, 1 ) × 100
Consecuencias prácticas de que solo cuente el último corte:
- Reportar un corte nuevo reemplaza la lectura anterior; no se acumula con ella. Si en el corte nuevo omites un año que antes tenía valor, ese año pasa a contar como 0.
- Los cortes anteriores se conservan íntegros como historial y son los que dibujan la curva de evolución.
- Las claves de corte son fechas
AAAA-MM-DD: el orden alfabético coincide con el cronológico.
2. Avance de una meta
Ejemplo real — meta E1M1
"Consolidar el sistema de autoevaluación y autorregulación institucional permanente", con cuatro acciones:
| Acción | Ponderación | Último corte | Aporte al avance |
|---|---|---|---|
A-001 Definir el cronograma | 0,15 | { año1: 0, año2: 0.15 } | 15,00 % |
A-002 Socializar el cronograma | 0,15 | { año1: 0, año2: 0.15 } | 15,00 % |
A-003 Desarrollar el sistema | 0,50 | { año1: 0, año2: 0.25 } | 25,00 % |
A-004 Seguimiento y plan de mejoramiento | 0,20 | { año2: 0 } | 0,00 % |
| Total | 1,00 | 55,00 % |
Nótese A-003: pesa 0,50 y solo ha reportado 0,25, es decir va por la mitad de su
propio compromiso. Y A-004, que pesa 0,20, aún no aporta nada.
Ese 55 % es exactamente el avance_meta que S-PLAN publica hoy para E1M1.
Compruébalo en el explorador del PDI.
0.55) y otros como porcentaje (55). El código aplica en todos
los puntos la misma regla: si v ≤ 1 → v × 100. Por eso un avance real del 0,8 % puede quedar mal
interpretado como 80 % si se escribe a mano en la base sin cuidado.3. Avance del PDI
Cada meta tiene una ponderación dentro del plan completo (ponderacion_meta).
La suma de las 120 ponderaciones es 1.
avance_general = Σ120 metas avance_ponderado
Ambos valores se materializan al guardar cada meta:
S-PLAN/metas_con_ponderacion/{meta}— avance efectivo, avance real, avance ponderado y los ids del eje/programa/proyecto. Es el índice que consumen dashboards e informes: evita recorrer el árbol completo.S-PLAN/avance_general— el número único del PDI.
4. Lo programado: cronograma y proyección
Además de lo ejecutado, S-PLAN necesita saber cuánto debía llevarse a cada año. Hay dos fuentes, y conviene no confundirlas.
a) Cronograma de la acción
cronograma_anual.añoK es un mapa de meses marcados ({ "12": true }). La regla es
binaria y por año:
// su ponderación COMPLETA cuenta como objetivo de ese año.
objetivo[k] = Σacciones ( algúnMesMarcado(acción, k) ? ponderacion × 100 : 0 )
Una acción programada en varios años reparte su peso: en el gráfico de avance por acción, el objetivo de cada
año es ponderación ÷ (número de años programados).
b) Proyección de la meta
proyeccion_anual guarda el reparto planeado por año (por ejemplo
{ año1: 0.1, año2: 0.5, año3: 0.3, año4: 0.1 }) y se interpreta según dos banderas de la meta:
| Campo | Valores | Efecto |
|---|---|---|
tipo_programacion | porcentaje · cantidad |
Si es porcentaje y los valores vienen en 0–1, se escalan a 0–100 antes de graficar. |
tipo_acumulacion | acumulado · no acumulado |
Si es acumulado y la serie parece acumulada (no decreciente, cierra ≈100 y suma >120), se convierte a porciones anuales por diferencias. |
5. Cumplimiento del Plan Anual de Acciones
Es un indicador distinto del avance del PDI y no debe mezclarse con él. Mide, dentro de la vigencia en curso, qué proporción de lo programado para ese año efectivamente se cumplió:
El índice S-PLAN/cumplimiento_meta_paa/{meta} guarda el resultado por meta y año, y es lo que
consume la tarjeta Cumplimiento Plan Anual de Acciones y el informe técnico.
6. Overrides: cuando el número mostrado no es el calculado
En casos puntuales Planeación necesita mostrar un avance distinto del calculado —por ejemplo, mientras se revisa una inconsistencia de reporte—. S-PLAN lo soporta, pero con un mecanismo que conviene conocer porque no basta con escribir en la base de datos.
Mapa overridesPersistentes
Vive en el código de meta.html. Controla el porcentaje grande y la barra de avance. Al abrir la
meta, el frontend reescribe avance_meta, avance_meta_calculado_real,
avance_meta_override_temporal y metas_con_ponderacion/{meta}.
Mapa excepcionesTemporales
También en meta.html, dentro de renderAvanceGeneral. Controla la gráfica
Avance General. Si se omite, el gráfico muestra el calculado y queda incoherente con el número grande.
Escritura directa en RTDB
Necesaria para que los dashboards —que leen avance_meta y metas_con_ponderacion—
reflejen el ajuste sin esperar a que alguien abra esa meta.
overridesPersistentes, al abrir su ficha el frontend borra el override en la base y
vuelve al avance calculado. Es decir: quitar la meta del mapa del código es la forma correcta de retirar un override,
y escribir solo en la base de datos nunca dura.La ficha de meta marca los overrides vigentes en su tooltip (“valor real calculado: X %”), y el explorador del PDI los señala con el chip Avance con override. Actualmente hay … meta(s) con override activo.
7. Metas fantasma
Una meta real siempre tiene id_meta y titulo_meta. Un nodo que solo contenga
ejecucion_financiera, inversion_realizada y fecha_actualizacion_financiera
es un fantasma: una escritura financiera que aterrizó en la rama equivocada del árbol.
Distorsionan los conteos y las sumas de inversión. La defensa está en dos partes:
- Toda escritura financiera valida la ruta contra
S-PLAN/indices_metasantes de guardar. - Las vistas de proyecto filtran los nodos sin
id_meta/titulo_meta.
Este explorador aplica el mismo filtro, así que los conteos que ves aquí ya excluyen fantasmas.
Checklist de diagnóstico
| Síntoma | Causa habitual |
|---|---|
| Reporté avance y la meta no se movió | El corte nuevo omitió los años que antes tenían valor: al contar solo el último corte, esos años quedaron en 0. |
| La meta muestra 80 % y debería ser 0,8 % | Un valor escrito como fracción donde se esperaba porcentaje (o al revés): la normalización v ≤ 1 → ×100 lo amplificó. |
| La meta pasa de 100 % | Las ponderaciones de sus acciones suman más de 1. El valor se recorta a 100, pero el reparto está mal. |
| Cambié el avance en la base y volvió al valor anterior | Hay un override en el código que se reescribe cada vez que se abre la meta. |
| El avance del eje no cuadra con el de sus metas | Los avances agregados de eje/programa/proyecto vienen de la carga masiva, no se recalculan al guardar una meta. Ver Carga masiva. |