Referencia · S-PLAN

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.

En una línea: el avance de una meta es la suma de lo ejecutado por sus acciones (donde cada acción ya viene expresada como fracción de su propio peso), y el avance del PDI es la suma de cada meta multiplicada por su ponderación.

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
  }
}
Lo que más se malinterpreta: el valor de 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.
// De todos los cortes, se toma SOLO el más reciente (claves ordenadas alfabéticamente = cronológicamente)
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:

2. Avance de una meta

avance_meta_calculado_real = clamp( Σacciones avanceAccion , 0, 100 )

Ejemplo real — meta E1M1

"Consolidar el sistema de autoevaluación y autorregulación institucional permanente", con cuatro acciones:

AcciónPonderaciónÚltimo corteAporte al avance
A-001 Definir el cronograma0,15{ año1: 0, año2: 0.15 }15,00 %
A-002 Socializar el cronograma0,15{ año1: 0, año2: 0.15 }15,00 %
A-003 Desarrollar el sistema0,50{ año1: 0, año2: 0.25 }25,00 %
A-004 Seguimiento y plan de mejoramiento0,20{ año2: 0 }0,00 %
Total1,0055,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.

Normalización 0–1 vs 0–100. Por herencia de las cargas por Excel, algunos campos llegan como fracción (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_ponderado(meta) = avance_meta(0..1) × ponderacion_meta(0..1)
avance_general = Σ120 metas avance_ponderado

Ambos valores se materializan al guardar cada meta:

Avance general hoy
Metas ponderadas
Acciones que lo alimentan

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:

// Si la acción tiene AL MENOS un mes marcado en el año k,
// 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:

CampoValoresEfecto
tipo_programacionporcentaje · cantidad Si es porcentaje y los valores vienen en 0–1, se escalan a 0–100 antes de graficar.
tipo_acumulacionacumulado · no acumulado Si es acumulado y la serie parece acumulada (no decreciente, cierra ≈100 y suma >120), se convierte a porciones anuales por diferencias.
La distinción importa al leer la gráfica Avance General Anual de la ficha de meta: la línea de objetivo puede venir del cronograma de las acciones o de la proyección de la meta, y no siempre coinciden. Cuando difieren, la del cronograma refleja lo que realmente quedó programado.

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ó:

cumplimientoPAA(año) = ejecutado(año) ÷ objetivo(año) × 100

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.

1

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}.

2

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.

3

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.

Efecto colateral, documentado porque muerde: si una meta no está en 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:

Este explorador aplica el mismo filtro, así que los conteos que ves aquí ya excluyen fantasmas.

Checklist de diagnóstico

SíntomaCausa 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 anteriorHay 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 metasLos avances agregados de eje/programa/proyecto vienen de la carga masiva, no se recalculan al guardar una meta. Ver Carga masiva.