En esta nueva release se trabajaron múltiples funcionalidades y correcciones orientadas a mejorar la experiencia de uso del Sistema de Gestión Escolar (SGE) en todas las jurisdicciones. A continuación, te contamos los cambios más importantes implementados.

🔹 Funcionalidades incorporadas

🟦📝 Salta – Titulación en Nivel Inicial Especial

🔍 ¿Cuál era el problema?

Las titulaciones de Nivel Inicial Especial no permitían la configuración de materias con plantillas de calificación, lo que limitaba la evaluación al formato narrativo y bloqueaba el uso de boletines oficiales.

🛠 ¿Qué se hizo?

Se habilitó la configuración en la titulación, permitiendo asociar plantillas de calificación y períodos a cada espacio curricular, además de definir su visibilidad en boletines (Analítico, Oficial o Informativo).

Principales cambios y características:

Se habilitó la configuración de «Tiene calificación» en la titulación, permitiendo asociar plantillas de calificación y períodos a cada espacio curricular, además de definir su visibilidad en boletines (Analítico, Oficial o Informativo).
Se modificó la interfaz de «Gestión de cursada» para que, al elegir «Generar boletín», el usuario pueda seleccionar explícitamente entre el «Boletín Informativo» y el «Boletín General», activando la planilla de calificaciones correspondiente.
Se integró un selector de tipo de calificación («Notas» vs. «Informativa») que permite alternar entre ambas vistas en la misma pantalla, asegurando la persistencia de los datos al cambiar de modalidad.

Beneficios:

Los administradores ahora pueden estructurar titulaciones de Inicial Especial con materias calificables, permitiendo una gestión más flexible y detallada de la trayectoria escolar de los alumnos.
Los usuarios directivos y preceptores tienen ahora la flexibilidad de emitir el documento de evaluación que mejor se adapte a las necesidades pedagógicas del alumno o grupo dentro de la modalidad especial.
Los docentes pueden centralizar la carga de informes narrativos y calificaciones por períodos en una interfaz unificada, simplificando el proceso administrativo y evitando la duplicidad de tareas.

📌 Motivo del cambio:

Restricción de evaluación: No se podían configurar materias con plantillas de calificación, lo que impedía el uso de notas o escalas numéricas/conceptuales estructuradas.
Bloqueo de documentos oficiales: Al no contar con un sistema de calificación formal, no se podían generar los Boletines Oficiales, limitando la documentación administrativa de los alumnos.
Rigidez en la gestión: Existía una necesidad pedagógica de tener una gestión más flexible y detallada de la trayectoria escolar, permitiendo alternar entre informes narrativos (formativos) y calificaciones por períodos (sumativas) según el caso.

🟦📝 Unificación de reportes bajo un selector común

🔍 ¿Cuál era el problema?

Las pantallas de Alumnos, Cursada, Alertas y Asistencia presentaban botones de descarga individuales (ícono de impresora) para cada reporte disponible, lo que generaba una interfaz saturada y poco escalable ante la incorporación de nuevos documentos.

🛠 ¿Qué se hizo?

Se reemplazó el botón de impresión por un selector desplegable («dropdown») en la esquina superior derecha de cada pantalla. Este selector centraliza todos los reportes habilitados según el contexto (ej. Constancia de alumno regular en Alumnos, Registro de asistencias en Cursada, etc.) y mantiene las reglas de permisos y filtros existentes.

📌 Motivo del cambio:

Saturación de la interfaz: La presencia de múltiples botones individuales (íconos de impresora) para cada reporte hacía que las pantallas principales se vieran visualmente cargadas y desorganizadas.
Falta de escalabilidad: El diseño anterior dificultaba la incorporación de nuevos documentos, ya que no era sostenible seguir agregando botones individuales cada vez que se creaba un reporte nuevo.
Dificultad en el mantenimiento visual: Se buscaba una solución que permitiera agregar futuros reportes sin tener que modificar constantemente el diseño visual de las pantallas.
Optimización de la experiencia de usuario: Era necesario centralizar las opciones en un solo lugar (selector desplegable) para ofrecer una navegación más limpia, profesional y adaptada al contexto de cada pantalla.

🟦📝 Chubut – Diseño y adaptación del Boletín General para Chubut

🔍 ¿Cuál era el problema?
La jurisdicción de Chubut requería un diseño específico para el Boletín General de Educación Primaria, que incluyera una estructura de dos páginas con datos detallados de la institución, el alumno y su ciclo de formación, diferenciando entre el Primer y Segundo ciclo.

🛠 ¿Qué se hizo?

Se desarrolló una nueva plantilla de boletín en PDF para Chubut que incluye: un header duplicado en ambas páginas con datos del establecimiento (nombre, código jurisdiccional, localidad) y del estudiante; un apartado de «Documento de Calificación y Promoción» con el ciclo lectivo; secciones para firmas de autoridades y tutores; y un cuadro informativo de notas adaptado al ciclo correspondiente.

📌 Motivo del cambio

Permitir a las escuelas primarias de Chubut generar documentos oficiales que cumplen estrictamente con la normativa jurisdiccional, garantizando que la información sobre la promoción y el rendimiento académico se presente de forma clara, legal y profesional ante las familias y autoridades.

🟦📝 Validación de inconsistencias en la carga de calificaciones por períodos

🔍 ¿Cuál era el problema?

Se detectó una vulnerabilidad en la lógica de aprobación que permitía registrar una nota como «Aprobado» en un período que aprueba espacio (ej. Diciembre) a pesar de que el alumno ya tuviera una calificación registrada en un período posterior (ej. Febrero). Esto generaba inconsistencias en el historial académico y en la determinación del estado final de la materia.

🛠 ¿Qué se hizo?

Se incorporó una nueva regla de validación que bloquea la carga o edición de una nota con el atributo «Aprueba espacio» si existen calificaciones previas en períodos cronológicamente posteriores para ese alumno y materia. El sistema ahora emite un mensaje de error claro solicitando al usuario ajustar o eliminar las notas posteriores antes de proceder.

📌 Motivo del cambio:

El objetivo es garantiza la integridad y consistencia cronológica de los datos académicos. Los docentes y directivos ya no pueden generar estados de aprobación contradictorios, asegurando que el cierre de períodos y los reportes de promoción reflejen la situación real y secuencial del estudiante sin intervenciones manuales posteriores para corregir errores de carga.

🟦📝 Estrategia de Identificación y Validación de Personas

🔍 ¿Cuál era el problema?

Debido al crecimiento de pedidos para corrección de datos unívocos (nombre, DNI, sexo, fecha de nacimiento) y la duplicidad de registros, se identificó la necesidad de proteger la integridad de los datos básicos.

🛠 ¿Qué se hizo?

Se incorporó un atributo de «validación» en los registros de personas. Los datos provenientes de fuentes externas confiables (ej. SINTyS) se marcan automáticamente como válidos.

📌 Motivo del cambio:

Si una persona está validada, los datos base NO pueden modificarse, incluso si el usuario tiene permisos de edición. Para registros no validados, se intenta realizar una validación automática al momento de guardar o actualizar los datos.

🟦📝 Validación de Edades Críticas en Inscripción

🔍 ¿Cuál era el problema?

Se detectaron inscripciones de alumnos en niveles educativos que no correspondían a su rango de edad, generando inconsistencias pedagógicas y administrativas.

🛠 ¿Qué se hizo?

Se incorporaron reglas de validación que verifican la edad mínima y máxima del alumno al momento de la inscripción, basándose en la fecha de corte establecida para el ciclo lectivo.

📌 Motivo del cambio:

1. Evitar errores de trayectoria escolar: Se identificó que algunos alumnos estaban siendo inscriptos en años o grados que no les correspondían legalmente, lo que afectaba la validez de sus certificados y boletines.
   2. Cumplimiento de la normativa jurisdiccional: Cada nivel educativo tiene una «edad teórica» y una «fecha de corte» (generalmente al 30 de junio). El sistema necesitaba asegurar que se respete la regla: Edad teórica – 1 ≤ Edad real ≤ Edad teórica + 3.
   3. Integridad de los datos administrativos: Las inscripciones fuera de rango generaban problemas en los reportes estadísticos y en la gestión de vacantes, ya que el sistema no advertía si un niño de 10 años, por ejemplo, estaba siendo inscripto en Nivel Inicial por error de carga.
   4. Automatización de advertencias: Anteriormente, el sistema dependía del control manual de los directivos o secretarios. Con este cambio, el sistema emite un bloqueo o advertencia automática basándose en la fecha de nacimiento del alumno y el ciclo lectivo configurado.

🟦📝 Tucumán – Limitar permisos al rol Director

🔍 ¿Cuál era el problema?

La jurisdicción de Tucumán requería una delimitación más precisa de las acciones que el rol «Director» puede realizar dentro del sistema, evitando solapamientos con otros perfiles administrativos.

🛠 ¿Qué se hizo?

Se ajustó la matriz de permisos para el rol Director, restringiendo el acceso a ciertas configuraciones globales y centrando sus facultades en la gestión pedagógica y supervisión de su institución.

📌 Motivo del cambio:

Garantiza que las acciones críticas a nivel jurisdiccional no sean alteradas por usuarios de nivel institucional, manteniendo la jerarquía de seguridad definida por la provincia.

🟦📝 Unificación de Descarga de Reportes

🔍 ¿Cuál era el problema?

Las pantallas principales presentaban múltiples botones de impresión, lo que saturaba la interfaz y dificultaba la escalabilidad.

🛠 ¿Qué se hizo?

Se reemplazaron los botones individuales por un selector desplegable («dropdown») centralizado en la esquina superior derecha de las pantallas de Alumnos, Cursada, Alertas y Asistencia.

📌 Motivo del cambio:

Mejorar la experiencia de usuario y permitir agregar nuevos reportes en el futuro sin necesidad de rediseñar las pantallas actuales.

🟦📝 Rediseño del Menú en Unidad de Servicio

🔍 ¿Cuál era el problema?

Se requería modernizar la navegación dentro del módulo de institución para mejorar la accesibilidad a las diferentes funcionalidades.

🛠 ¿Qué se hizo?

Se migró el menú lateral a un nuevo formato componentizado y se actualizó el toolbar para integrar el acceso a los módulos de forma fluida.

📌 Motivo del cambio:

Saturación de la interfaz: Las pantallas tenían demasiados botones de impresión individuales, lo que generaba un diseño visual cargado y confuso para el usuario.
Falta de escalabilidad: El diseño anterior dificultaba la incorporación de nuevos documentos. Cada vez que se quería agregar un reporte nuevo, era necesario rediseñar la pantalla para buscarle un lugar al botón.
Optimización de la experiencia de usuario: Se buscaba una navegación más limpia, organizada y profesional, centralizando todas las opciones de descarga en un solo lugar (selector desplegable) para facilitar el trabajo administrativo.

🟦📝 Reporte de Alertas y Acciones por Alumnos

🔍 ¿Cuál era el problema?

Se identificó la necesidad de centralizar la información de seguimiento de alertas dentro del módulo informativo de reportes de la institución.

🛠 ¿Qué se hizo?

Se agregó el reporte «Alertas y acciones por alumnos» y se actualizó la lógica del reporte existente para que los datos coincidan con el flujo actual de intervenciones.

📌 Motivo del cambio:

Los equipos directivos no tenían un panorama detallado de las alertas activas y las acciones tomadas por los preceptores en un solo documento consolidado.

🟦📝 Reporte XLS de Beneficio Alimentario

🔍 ¿Cuál era el problema?

No existía un reporte en donde se mencionen los datos de los alumnos con beneficio alimentario.

🛠 ¿Qué se hizo?

Se desarrolló un proceso de generación de archivo XLS plano que agrupa a los alumnos por CUE, anexo, nivel y categoría de beneficio alimentario.

📌 Motivo del cambio:

El equipo de análisis necesitaba una herramienta para investigar cómo se registran las categorías de alimentación en las provincias.

🟦📝 Tareas de Infraestructura – Altcha

Actualización y configuración de Altcha

🔍 ¿Cuál era el problema?

Se requería unificar la versión de la librería Altcha utilizada en el sistema para asegurar la compatibilidad entre el SGE y el Portal Escolar, evitando inconvenientes detectados en ciertos navegadores.

🛠 ¿Qué se hizo?

Se realizó un rollback controlado de la versión de Altcha (de la 2.0.3 a la 1.1.1) para mantener paridad con el Portal Escolar. Asimismo, se configuraron las URLs productivas en los archivos de propiedades de todos los ambientes de producción.

📌 Motivo del cambio:

Falta de paridad entre sistemas: Existía una diferencia de versiones entre el SGE (que usaba la 2.0.3) y el Portal Escolar (que usaba la 1.1.1), lo que impedía que funcionaran de manera unificada.
Errores en navegadores: Se habían detectado fallos e inconvenientes técnicos en ciertos navegadores al utilizar la versión más reciente (2.0.3).
Inestabilidad en el acceso: El mecanismo de seguridad y validación (Altcha) no era lo suficientemente estable, lo que ponía en riesgo el acceso de los usuarios a los ambientes de producción.

🟦📝 Tareas de Seguridad – Gestión de Sesiones

Mejora en la seguridad de gestión de sesiones (Cookies vs JWT)

🔍 ¿Cuál era el problema?

La arquitectura anterior de manejo de sesiones utilizaba tokens JWT almacenados en el frontend, lo que presentaba limitaciones en términos de seguridad y estandarización de la persistencia de sesión entre los diferentes módulos del ecosistema (SGE y Portal Escolar).

🛠 ¿Qué se hizo?

Se migró la lógica de autenticación para reemplazar el uso de JWT por cookies seguras (HttpOnly, Secure). Esta implementación incluyó la adaptación de la toolbar, la componentización de menús y la actualización de las reglas de CORS para permitir la navegación fluida mediante cookies.

📌 Motivo del cambio:

Vulnerabilidad de los datos: La arquitectura anterior guardaba los tokens (JWT) directamente en el frontend (navegador), lo que exponía la sesión a ataques que pueden acceder al almacenamiento local del usuario.
Falta de estandarización: No había una forma común de mantener la sesión iniciada entre el SGE y el Portal Escolar, lo que generaba una experiencia fragmentada y menos estable.
Necesidad de mayor protección: Se buscaba implementar Cookies Seguras (HttpOnly y Secure), que son invisibles para scripts maliciosos del navegador, garantizando que el identificador de sesión esté mucho más protegido.
Estabilidad de la conexión: La migración permite una «navegación fluida» entre módulos, evitando que el usuario pierda la conexión al saltar de una aplicación a otra dentro del mismo ecosistema escolar.

🔹 Correcciones y ajustes

Salta: Error al descargar el boletín seleccionando todos.
Se solicitó no mencionar fecha exacta de inicio del ciclo lectivo en certificado de escolaridad.
Corrección de permisos en accesos específicos tras el Hotfix.
Jujuy: Corrección técnica en la visualización de datos de alumnos.
Salta: Corrección de la visibilidad de alumnos para calificar fuera de los periodos correspondientes.
Ajuste en la lógica de cálculo y visualización de la fila «Calificación Final» en los boletines.

✅ Conclusión

La versión 2.64 del Sistema de Gestión Escolar (SGE) consolida un proceso de maduración técnica y operativa, priorizando la integridad de los datos académicos y la seguridad del ecosistema digital. Mediante la implementación de validaciones críticas en inscripciones y calificaciones, así como la modernización del esquema de seguridad y navegación, esta actualización no solo resuelve desafíos funcionales de las provincias, sino que también establece una base más robusta, escalable y eficiente para la gestión educativa nacional.