Gestion de Proyectos Consof.xlsx

consof proyectos.docx grabacion donde david explica el paso a paos

Entregable parcial (Fase A de 3) del bloque gestion_proyectos · /modulo

PR mergeado: https://github.com/Indunnova16/Consof/pull/81
Revisión Cloud Run (100% tráfico, verificada): consof-00059-8fv
Smoke E2E: ✅ todo verde — 9/9 journeys, 84 asserts, 16 screenshots (Playwright real, no curl)

Contexto del alcance

Este issue pide el Sistema de Gestión de Proyectos CONSOF completo: 5 fases, 25 actividades/entregables, 12 plantillas del xlsx, 3 comités, arquitectura de KPIs en 3 niveles y gestión de excepciones documentales. Es un bloque grande — se decidió partir la construcción en 3 corridas secuenciales (Fase A/B/C) para no arriesgar calidad. Esta entrega es solo Fase A (el backbone). Fase B (riesgos, presupuesto, cronograma, seguimiento semanal) y Fase C (informe mensual, comités de área, acta de cierre, tablero de KPIs) quedan para las próximas corridas del mismo bloque — se abre un issue de seguimiento explícito para eso.

Hallazgo importante de arquitectura: apps/projects ya existía en producción (11 proyectos reales) — este bloque fue gap-analysis + extensión, no construcción desde cero. Se reusaron patrones ya existentes en apps/finance (presupuestos), apps/documents (repositorio documental) y sobre todo apps/contractors (el patrón de excepciones con doble aprobación, replicado casi literal para este requerimiento).

Sub-features entregadas en esta fase

B1 — Clasificación del proyecto A/B/C (Entregable 1.4)

• Estado: 🟢 validado en prod
• Escenario reproducido: /projects/{id}/clasificar/ con los 7 criterios ponderados en Nivel B → guarda, calcula nivel_resultante, dispara la generación automática de 25 entregables obligatorios (ProjectDeliverable) — verificado por BD, no solo por UI.
• URLs smokeadas: /projects/{id}/clasificar/ (form + submit), /projects/{id}/clasificacion/ (detalle) — HTTP 200
• Migraciones: 0003, 0005 (campos de rol + clasificación)
• Tests: 23 unitarios + 1 journey E2E con datos reales

B2 — Checklist de inicio (Entregable 1.5)

• Estado: 🟢 validado en prod
• Escenario reproducido: /projects/{id}/checklist/ sobre un proyecto Nivel A → aparecen los 25 items reales del catálogo (5 categorías, transcritas literal del xlsx) filtrados por nivel de aplicabilidad.
• URLs smokeadas: /projects/{id}/checklist/ — HTTP 200
• Migraciones: 0010 (catálogo + seed de 25 items reales)
• Tests: 16 unitarios + 1 journey E2E. Expone ChecklistService.get_completion_percentage() como contrato para el tablero de KPIs de Fase C.

B4 — Matriz RACI (Entregable 2.4)

• Estado: 🟢 validado en prod
• Escenario reproducido: /projects/{id}/equipo/ asigna una persona real como Líder de Proyecto → /projects/{id}/raci/ la muestra cruzada contra el catálogo fijo de 25 actividades × 186 filas RACI (seedeado del xlsx real) → export PDF real smokeado (/projects/{id}/raci/pdf/, 22KB, application/pdf).
• Hallazgo de datos real: la "regla de oro RACI" (1 responsable + 1 autorizador por entregable) NO se cumple literal en el seed real — 20 de 25 entregables no tienen autorizador formal. Se implementó y validó la regla correcta (≥1 responsable, ≤1 autorizador), documentada en el servicio.
• Tests: 21 unitarios + 1 journey E2E (incluye smoke del PDF)

B7 — Gestión de excepciones documentales (Directriz ERP documentos proyecto)

• Estado: 🟢 validado en prod
• Escenario reproducido: sobre un entregable pendiente, solicitar una excepción TIPO 1 (temporal) con responsable + un segundo usuario designado como aprobador → la excepción queda registrada abierta, sin autoaprobación posible (regla validada en 3 capas: form/servicio/modelo), y el entregable permanece pendiente hasta que el aprobador designado la apruebe formalmente — este diseño (aprobación real de 2 usuarios, no un trámite) va más allá de la redacción literal del requerimiento pero es fiel a su intención ("flujo de aprobación de 2 usuarios... nunca autoaprobada").
• URLs smokeadas: /projects/entregables/{id}/excepcion/nueva/, /projects/{id}/entregables/ (dashboard) — HTTP 200
• Recordatorios automáticos vía Celery implementados y testeados (31 tests unitarios); el registro de la tarea periódica se hizo idempotente vía migración de datos.

Validación funcional pendiente

@Indunnova — favor revisar:
1. Clasificar un proyecto real (no de prueba) en /projects/{id}/clasificar/ y confirmar que los 7 criterios y sus umbrales (ej. presupuesto <$150M=A, $150M-$500M=B, >$500M=C) coinciden con el criterio real de la compañía.
2. Revisar /projects/{id}/equipo/ y /projects/{id}/raci/ sobre un proyecto real con equipo asignado — confirmar que los 8 roles del catálogo (Gerencia/Dir.Admon/Líder Proy/Supervisor/Comercial/SST/Compras/Diseño) cubren la operación real.
3. Confirmar el criterio de "excepción documental" en /projects/{id}/entregables/ — específicamente que el flujo de 2 usuarios (solicitante + aprobador designado) es el comportamiento esperado (no un simple registro informativo).

URLs clave para validar (usar un proyecto real, ej. id=1 AIU-0326-001):
- https://consof-rvfp6uj2va-uc.a.run.app/projects/1/clasificar/
- https://consof-rvfp6uj2va-uc.a.run.app/projects/1/checklist/
- https://consof-rvfp6uj2va-uc.a.run.app/projects/1/equipo/
- https://consof-rvfp6uj2va-uc.a.run.app/projects/1/raci/
- https://consof-rvfp6uj2va-uc.a.run.app/projects/1/entregables/

Pendiente explícito (Fase B y C — próximas corridas del mismo bloque)

• Fase B: matriz de riesgos, presupuesto itemizado (extiende apps/finance), cronograma con seguimiento semanal por capítulo.
• Fase C: informe mensual narrativo, comités de área (mensual/trimestral), acta de cierre (con el bloqueo de cierre por entregables pendientes), tablero de KPIs en 3 niveles.
• Se abrirá un issue de seguimiento (gestion_proyectos-followup) para trazabilidad de este pendiente.

NO cerrar

Este issue queda OPEN — cubre el sistema completo y esta entrega es solo la Fase A. Validar lo entregado y comentar acá; el cierre definitivo espera a Fase B y C.

Comentario generado por mbrt26 vía /modulo. Bundle del RUN MODULO_Consof_gestion_proyectos_2026-07-09_1644. Detalles forenses en el repo SPRINTS/.

Discovery — confirmación pendiente + hallazgo sobre el adjunto

Estado: ⏸ Bloqueado — esperando tu confirmación, @Dvillac97

La Fase A (clasificación A/B/C, checklist, matriz RACI) ya está deployada y validada en código (PR#81, 100% tráfico, 9/9 E2E verdes). Antes de seguir a Fase B/C necesito que confirmes los 3 puntos que ya te habíamos posteado:

1. Clasificar un proyecto real en /projects/{id}/clasificar/ y confirmar que los 7 criterios ponderados y sus umbrales (ej. presupuesto <$150M=A, $150M-$500M=B, >$500M=C) coinciden con el criterio real de la compañía.
2. Revisar /projects/{id}/equipo/ y /projects/{id}/raci/ sobre un proyecto real con equipo asignado y confirmar que los 8 roles del catálogo (Gerencia / Dir. Admón / Líder Proy / Supervisor / Comercial / SST / Compras / Diseño) cubren la operación real.
3. Confirmar que el flujo de excepción documental de 2 usuarios (solicitante + aprobador designado, sin autoaprobación) en /projects/{id}/entregables/ es el comportamiento esperado y no solo un registro informativo.

Hallazgo nuevo sobre el adjunto

El archivo consof proyectos.docx (descrito como "grabación donde David explica el paso a paso") en realidad es la transcripción de otra llamada — cuentas por pagar, compras, pipeline comercial. No menciona clasificación/RACI/checklist. La propia transcripción cierra con que la revisión del módulo de Proyectos contigo quedó pendiente para la semana siguiente. Cuando esa grabación/explicación esté disponible, es insumo directo para validar Fase B (riesgos/presupuesto/cronograma), que ya tiene blueprint propio en #82.

Analizado vía sistema multiagente Indunnova16.

Validación funcional Fase A — 10/07/2026

✅ Validado y OK

• Formulario de clasificación /projects/1/clasificar/: 7 criterios presentes con umbrales en texto de ayuda ✅
• Gestión de equipo /projects/1/equipo/: selector de personas, campos de rol, nivel de autoridad y botón "Agregar al equipo" funcionan ✅
• Matriz RACI /projects/1/raci/: carga con 25 entregables de las 5 fases, roles R/A/C/I por entregable, botón "Exportar PDF" presente ✅
• Flujo de dependencia checklist → clasificación: correcto — muestra "Proyecto sin clasificar" hasta completar Entregable 1.4 ✅

🐞 Bugs encontrados

Bug 1 — CRÍTICO: Todas las listas de criterios de clasificación muestran las mismas opciones genéricas
URL: /projects/1/clasificar/

Todos los criterios tienen el mismo dropdown con opciones A-Simple / B-Medio / C-Complejo, sin importar el criterio. Las etiquetas no reflejan el significado real de cada campo:

Las opciones de cada dropdown deben usar las etiquetas propias del criterio, no "Simple/Medio/Complejo" genérico.

Bug 2 — Miembros del equipo muestran "Sin rol RACI" aunque tienen roles de proyecto
URL: /projects/1/equipo/

Catalina Molina Pareja (Coordinadora SST), Luis Martinez (Ingeniero Residente), Sebastian Lopez Mendez (Maestro de Obra) y Sergio Palacio Cuartas (Director de Proyecto) muestran badge "Sin rol RACI". El campo "Rol de proyecto (catálogo RACI)" no fue mapeado al crearlos — la Matriz RACI no puede cruzarlos correctamente.

Bug 3 — Usuario "QA Claude" con datos de prueba en producción
URL: /projects/1/equipo/

Aparece un miembro "QA Claude" con rol "SST (Catalina)", cargo "a" y contacto "d" — registro de prueba que quedó en producción. Debe eliminarse.

⏳ Pendiente de confirmación por @Dvillac97

Pregunta 1 — ¿Los umbrales de clasificación son correctos?
Los umbrales implementados son los del texto de ayuda del formulario. ¿Coinciden con el criterio real de CONSOF o necesitan ajuste?

Pregunta 2 — ¿Los roles del catálogo RACI coinciden con la operación real?
La Matriz RACI usa 8 roles genéricos (Gerencia, Dir. Admón, Líder Proy, Supervisor, Comercial, SST, Compras, Diseño). El issue #77 define los roles reales de CONSOF que son diferentes. @mbrt26 debe alinear el catálogo RACI con los roles del #77 antes de continuar con Fase B.

Pregunta 3 — ¿El flujo de excepción documental de 2 usuarios es correcto?
URL: /projects/1/entregables/
¿El flujo donde un usuario solicita la excepción y otro usuario distinto debe aprobarla (sin autoaprobación) es el comportamiento esperado, o debe ser solo un registro informativo?

Pregunta 4 — Acceso desde la ficha del proyecto
¿Desde /projects/1/ hay acceso directo a todas las funcionalidades (clasificar, checklist, equipo, RACI, entregables)? Necesito captura de esa pantalla para confirmarlo.

⏳ Fase B y C bloqueadas hasta

• Resolución de Bug 1 (clasificación incorrecta)
• Confirmación de preguntas 1, 2 y 3 por David
• Alineación de roles RACI con #77
• Grabación/transcripción de la sesión de proyectos del 19/06 con David y María Victoria (el archivo subido era de otra reunión)

No cerrar — Fase A parcialmente validada, Fases B y C pendientes.

mejoras luego de la reunion ## Validación funcional — Fase A (Punto 1: INICIO / GENERACIÓN) — 15/07/2026

Continuando la validación de Fase A, se revisó específicamente la Fase 1 (Inicio/Generación) contra la grabación de la sesión con David (19/06) y las pantallas ya deployadas. Se detalla punto a punto (1.1 a 1.7) + hallazgos en Equipo/RACI.

🐞 Bug 1 — CRÍTICO (ampliación): Clasificación A/B/C con dropdown genérico en vez de campo numérico

URL: https://consof-rvfp6uj2va-uc.a.run.app/projects/1/clasificar/

Ya se había reportado que las opciones de los dropdowns son genéricas (A-Simple/B-Medio/C-Complejo) en vez de las etiquetas propias del criterio. Se confirma y se detalla el comportamiento esperado:

Criterios que deben ser campo numérico con autoclasificación automática (el usuario escribe el valor real y el sistema calcula el nivel A/B/C, sin dropdown):

Ejemplo esperado: usuario escribe 140.000.000 en Presupuesto → sistema asigna automáticamente A. Usuario escribe 5 en Duración (meses) → sistema asigna automáticamente B. Igual para N° de especialidades/Contratistas.

Criterios que se mantienen como dropdown (no son un valor numérico puro):

🐞 Bug 4 — No se muestran las respuestas guardadas al reclasificar

URL: https://consof-rvfp6uj2va-uc.a.run.app/projects/1/clasificacion/

El detalle de clasificación sí calcula correctamente el ponderado por criterio (peso, nivel marcado, referencia) — esto está bien y se debe mantener. Pero al entrar a reclasificar/editar, el formulario no trae precargadas las respuestas ya guardadas anteriormente (valores numéricos ni selecciones de los dropdowns). El usuario debería poder ver y ajustar lo que ya había registrado, no partir de cero cada vez.

💡 Mejora — Maestro de Matriz de Clasificación (pesos y configuración)

Relacionado con el Entregable 1.4 (Analizar criterios y asignar nivel A/B/C al proyecto — RACI: I / I / R / C / C / I / I / I).

Actualmente los pesos por criterio (0.28, 0.20, 0.15, 0.08, 0.12, 0.05...) y los rangos que definen cada nivel están fijos en el sistema. Se necesita un maestro configurable con:
- Nombre del criterio
- Peso (%) asignado
- Rangos de valor por nivel (A/B/C), tanto para los numéricos como para los cualitativos
- Umbral del total ponderado que define el nivel final del proyecto (A/B/C)

⏳ Pendiente de confirmación por @Dvillac97 / María Victoria: el mecanismo de ponderación (de dónde salen los pesos y contra qué umbral se compara el total) no quedó definido en la grabación disponible — David menciona textualmente no saber "con qué lógica lo montó Claudia". Los rangos por criterio (ej. <$150M COP = A) sí están confirmados en el texto de ayuda actual del formulario, pero el peso y el umbral total del ponderado siguen abiertos. El maestro debe permitir dejar estos valores editables mientras se resuelve, sin bloquear el uso del sistema.

💡 Mejora — Punto 1.5: Maestro de Checklist de Inicio + automatización de tareas

URLs:
- https://consof-rvfp6uj2va-uc.a.run.app/projects/1/checklist/
- https://consof-rvfp6uj2va-uc.a.run.app/projects/1/checklist/editar/
- https://consof-rvfp6uj2va-uc.a.run.app/tareas/

✅ Correcto, mantener: el checklist ya filtra los ítems según el nivel/clasificación del proyecto (A/B/C) — este comportamiento es el esperado, confirmado en grabación.

Falta complementar con:
1. Maestro de checklist con: nombre del entregable, nivel al que aplica (A/B/C), rol responsable (dropdown de roles activos del catálogo) — configurable, no hardcodeado.
2. En la pantalla de edición (/checklist/editar/), el usuario solo debe asociar la persona que ya tiene asignado ese rol — no elegir de la lista completa de usuarios.
3. Al guardar o editar el checklist, el sistema debe generar automáticamente la tarea correspondiente en el módulo de Tareas, con: entregable, responsable y fecha.
4. Desde la tarea, al dar "ver", debe regresar directamente al checklist (/projects/1/checklist/) del entregable correspondiente.
5. En la vista de checklist falta un campo de link del entregable, para poder adjuntar la evidencia y marcarlo como completado.

💡 Mejora — Punto 1.6: Matriz de riesgos iniciales

Confirmado en grabación como pendiente de desarrollo — corresponde a Fase B (no a esta entrega de Fase A). Sin acción por ahora en este issue.

💡 Mejora — Punto 1.7: Portal de aprobación del cliente

Relacionado con el Entregable "Aprobación del cliente – Correo de confirmación".

En vez de subir el PDF del correo como evidencia, la idea (expresada en grabación, a confirmar como decisión final) es generar un portal donde el cliente pueda aprobar directamente vía link — mismo patrón que se plantea usar para el módulo de Compras. Se confirma la regla de bloqueo: la fase de Ejecución y Desarrollo no se habilita hasta que el cliente apruebe, salvo que un usuario de rol superior (Juan, David o Jimena) fuerce el avance sin esa aprobación.

🔁 Nota — Equipo del Proyecto y Matriz RACI

URLs:
- https://consof-rvfp6uj2va-uc.a.run.app/projects/1/equipo/
- https://consof-rvfp6uj2va-uc.a.run.app/projects/1/raci/

Se mantienen vigentes los Bugs 2 y 3 ya reportados (miembros del equipo sin rol RACI mapeado; usuario de prueba "QA Claude" en producción). Adicional confirmado por grabación:

• El rol de proyecto (RACI) es informativo/de responsabilidad — distinto del rol de permisos del ERP. No deben chocar entre sí ni configurarse en el mismo lugar.
• Falta un maestro de rol de proyecto: selector que, al elegir la persona, autocomplete cargo, teléfono, correo y nivel de autoridad.
• La Matriz RACI no es un entregable de cliente — es un documento interno. No debe duplicarse ni aparecer en la pestaña de Entregables del proyecto.

🔁 Nota — Entregables 1.1 y 1.2

Sin hallazgos nuevos — ambos puntos comparten el mismo mecanismo ya existente: el botón "convertir oportunidad a proyecto" desde el módulo Comercial. Al convertir, la primera pantalla debe ser la de clasificación/presupuesto, heredando automáticamente la información capturada por quien creó el centro de costo.

💡 Mejora — Dashboard del proyecto: sección de acceso a Fase 1

URL: https://consof-rvfp6uj2va-uc.a.run.app/dashboards/project/1/

Agregar en el dashboard una sección para la fase "1. INICIO / GENERACIÓN" con:
- Botones de acceso directo a: Clasificar, Checklist, Equipo, RACI, Entregables
- Resumen de avance de la fase (completados/pendientes)

Referencias

• Issue relacionado: #62
• Issue de seguimiento Fase B/C: #82
• PR mergeado (Fase A): #81
• Roles reales de CONSOF: #77

@Dvillac97 — pregunta puntual sobre el Equipo del Proyecto (id=1) para completar el mapeo de rol RACI (role_code) de los miembros reales:

Ya mapeamos con confianza a Sergio Palacio → Comercial, Catalina Molina → SST, y Sebastián López → Supervisor (nombre + cargo coinciden con el catálogo). Y retiramos el usuario de prueba "QA Claude" del proyecto.

Falta uno: Luis Martínez (cargo real "Ingeniero Residente"). No tiene equivalente directo en el catálogo actual de roles de proyecto (Gerencia / Dir. Admón / Líder Proy / Supervisor / Comercial / SST / Compras / Diseño). ¿David nos confirma:
- ¿comparte el rol Supervisor con Sebastián?, o
- ¿hace falta agregar un rol de proyecto nuevo (ej. "Ingeniero Residente / Residente de Obra") al catálogo?

Con eso cerramos el mapeo completo del equipo. (No inventamos el rol para no dejar un dato incorrecto.)

#62 — Refinamiento de Fase A (Inicio/Generación): desplegado y validado en prod

Tras tu validación del 15-jul, este ciclo refina la Fase A del Sistema de Gestión de Proyectos. Todo desplegado en la revisión consof-00125-zuz (100% del tráfico) y validado con E2E real (7/7 journeys, incluido el smoke del PDF de RACI):

• 🟢 A1 — Clasificación numérica con autoclasificación por umbral (absorbe el Bug 4). Presupuesto, Duración y N° de especialidades/contratistas ahora son campo numérico: el usuario escribe el valor real y el sistema calcula A/B/C por umbral (<$150M=A / $150M–$500M=B / >$500M=C, y equivalentes de duración y frentes). El detalle muestra el valor con separador de miles es-CO y precarga al reclasificar. Los otros 4 criterios siguen como dropdown.
• 🟢 A2 — RACI fuera de la pestaña Entregables (es documento interno, no entregable de cliente). Validado: ya no aparece en /projects/{id}/entregables/.
• 🟢 A3 — Dashboard del proyecto: sección "1. Inicio/Generación" con accesos directos (Clasificar/Checklist/Equipo/RACI/Entregables) + resumen de avance.
• 🟢 A4 — Maestro de Matriz de Clasificación configurable (criterios, pesos %, rangos por nivel), sembrado con los pesos actuales como default editable.
• 🟢 A5 — Maestro de Checklist + asociar el responsable real + generación automática de la Tarea + campo de link de evidencia.
• 🟢 A6 — Autocompletar cargo/teléfono/nivel al elegir la persona en el Equipo.

Data-fix aplicado (Bug 2/3): se mapeó el role_code RACI de Sergio (Comercial), Catalina (SST) y Sebastián (Supervisor), y se retiró el usuario de prueba "QA Claude" del proyecto real. Pendiente: el rol de proyecto de Luis Martínez ("Ingeniero Residente") — ver la pregunta a David en el comentario de arriba.

Para validar:
1. /projects/1/clasificar/ → escribí un presupuesto/duración/N° de frentes y confirmá el nivel A/B/C automático.
2. Maestros → Clasificación de Proyectos → editá un peso o rango.
3. /projects/1/checklist/editar/ → asigná un responsable y confirmá que se crea la Tarea (con botón "ver" de vuelta al checklist).
4. /projects/1/equipo/ → elegí una persona y verificá que autocompleta cargo/teléfono.
5. Dashboard del proyecto → sección "1. Inicio/Generación".

Sigue pendiente (por eso este issue NO cierra): la lógica de ponderación (pesos/umbral — David: "no sé con qué lógica lo montó Claudia"), el portal de aprobación del cliente (1.7), y la Fase B/C (riesgos, presupuesto, cronograma, informe mensual, comités, acta de cierre, tablero de KPIs) — trazadas en #82.

🔁 Reproceso — post-mortem de la intervención previa

Qué afirmamos antes: la entrega inicial de Fase A (PR#81) cerró como parcial y quedó a validación. La clasificación se construyó con dropdowns genéricos A/B/C y el RACI dentro de la pestaña de Entregables.

Qué faltaba/no coincidía: en la validación (10 y 15-jul) el cliente precisó que 3 criterios deben ser numéricos con autoclasificación (no dropdown), que el RACI es documento interno (fuera de Entregables), y pidió los maestros configurables + autocompletar + dashboard de fase. No fue un fix roto, sino el intent fino que emergió al validar.

Por qué no lo atrapamos antes: la primera Fase A fue un backbone deliberadamente incremental; el detalle de UX (numérico vs dropdown, ubicación del RACI) se cristalizó recién en la validación con la grabación de David.

Corrección de esta vez: se implementaron los 6 refinamientos (A1–A6) como v1.0, validados end-to-end contra la revisión promovida (7/7 E2E verde), y se aplicó el data-fix del equipo. Se dejó explícito lo que sigue dependiendo del cliente (ponderación, portal) para no volver a asumirlo.

https://consof-rvfp6uj2va-uc.a.run.app/projects/2/clasificar/
1-

ppto proyecto ✅
Duracion del proyecto ✅
Numero de especialidades ✅
Riesgos SST

preguntar por bajo medio y alto pero cambiar a botones

Complejidad tecnica

cambiar a botones y poner Estandar espacializada y Alta ingenieria

Numero de Stake holders

cambiar a campo de numeros

Requermientos del cliente

cambiar a botones y poner definiciones propias requerimientos complementarios requerimientos mas tecnicos o espacializados

la idea es que cuando guarde entonces calcule internamente el a b o c y te dejo aqui los criterios del calculo para que los complementes

Clasificacion Proyecto ABC Ejemplo.xlsx

y aqui muestre el valor real

y un poco mas explicito como dice el excel

📋 Rollup de estado — Sistema de Gestión de Proyectos CONSOF

Este issue sigue OPEN como tracker del sistema completo (Fase A ya deployada desde PR#81). Actualización de estado de los issues hijos activos tras la corrida del 2026-08-13/14:

Cerrados en esta corrida

En curso, pausados con plan persistido

Ambos quedaron deliberadamente pausados en un checkpoint seguro (cambios aditivos, sin romper nada existente) para retomar en una corrida dedicada dado el tamaño de cada epic.

Sin tocar en esta corrida

Los demás sub-ítems del sistema (#96-#109 y siguientes) no formaron parte del scope de esta corrida — siguen en su estado previo.

Refs #62

✅ Listo para que lo valides — probado por Andrea (Indunnova).

queda bloqueado hasta que david no resuelva dudas con el modulo de compras

Si quedó bien, márcalo como resuelto en tu ticket. Si algo falta, responde aquí mismo.

🔁 Devuelto por Andrea — no quedó validado.

Ejecutar

— Andrea vía NOVA

🟡 Cabecera del proyecto e indicador de cronograma corregidos (proyecto 48)

Revisión: consof-00212-dkg (100 % del tráfico, cuenta sa-consof) · PR #340

David, gracias por la prueba con la tarea 228. Encontramos dos causas:

1. La cabecera nunca leía el cronograma. Los recuadros «Avance Planificado» y «Avance Real» buscaban dos datos que el resumen del proyecto no calculaba, así que mostraban 0 % en cualquier proyecto.
2. El indicador leía el avance real de la versión equivocada. Cuando se aprueba una línea base, el ERP crea la versión de trabajo siguiente y mueve las tareas a ella (en el proyecto 48: línea base v2 y versión de trabajo v3). La tarea 228 actualizó la v3, pero el indicador tomaba el avance real de la v2, que seguía en 0 %.

Cómo queda: el avance planeado sale de la línea base vigente y el avance real de la versión de trabajo, que es donde se acumulan las tareas. La cabecera y el indicador usan la misma fuente.

Respuesta a sus preguntas

ℹ️ Si prefieren que el avance real se cuente desde la fecha de ejecución reportada (y no desde el registro), es un cambio de regla: confírmenlo aquí y lo programamos.

Estado

Lo que verificamos en producción: proyecto 48 (cabecera 100 % / 100 %; Fase 4: 100 %, Cumple). Dos proyectos anteriores al cambio: el 11 (cabecera 100 % / 50 %; indicador 50 %, No cumple) y el 171. Además, los listados de proyectos, oportunidades, cuentas objetivo, terceros y tareas responden 200.

Cómo validarlo: abrir el proyecto 48 y revisar los recuadros de avance de la cabecera; luego, en Fase 4, la fila «Cumplimiento de cronograma».

🔁 Reproceso: post-mortem de la intervención previa

• Qué afirmamos antes: que asignar una actividad crea la tarea y que completarla actualiza el avance del cronograma (eso sí funciona y ustedes lo validaron).
• Qué falló: la cabecera nunca recibió el avance y el indicador leía la línea base, no la versión de trabajo donde quedan las tareas.
• Por qué no lo atrapamos: las pruebas usaban un cronograma con una sola versión. Nunca probaron una línea base aprobada con su versión de trabajo siguiente, que es el caso real.
• Corrección: la prueba nueva reproduce su caso (línea base aprobada, tarea completada después) y revisa la cabecera y el indicador.