Lo que de verdad mira FUNDAE en tu Moodle (y por qué me he puesto a escribir un plugin para eso)

El malentendido

He trabajado trece años en un centro de formación para el empleo. Coordinaba cursos, daba clase y en los últimos años me tocó la parte técnica de la plataforma de teleformación, que es la que nadie quiere: las acreditaciones ante el SEPE, el validador, el servicio web SOAP, las visitas de seguimiento. Cuando el centro cerró en junio me quedé con un plugin que habla SOAP con el SEPE y con una lista bastante larga de preguntas que me hacían otros centros.

La que más se repite es esta: ¿tu plataforma está homologada por FUNDAE?

Y la respuesta, que sorprende a casi todo el mundo, es que eso no existe. Para la formación bonificada (la que las empresas se descuentan de los seguros sociales, lo que ahora se llama formación programada por las empresas) no hay ningún trámite previo que homologue, acredite ni inscriba una plataforma. Lo que hay es otra cosa, y es bastante más incómoda: un técnico de seguimiento que puede entrar en tu Moodle mientras el curso está en marcha, con las claves que tú misma le has comunicado en el inicio del grupo, y comprobar una serie de cosas muy concretas. Si no las encuentra, la bonificación se minora o se anula, y desde este año el asunto pasa directamente a la Inspección de Trabajo. O sea, no hay homologación previa, pero sí inspección a posteriori. Es lo peor de los dos mundos si no sabes qué van a mirar, y lo mejor si lo sabes.

La confusión viene de que sí existe una acreditación de plataformas, pero es la del SEPE para los certificados de profesionalidad, que es otra norma, otro trámite y otro servicio web (el SOAP del que te hablaba). Yo he pasado por ese trámite varias veces, con 20/20 en el validador, y precisamente por eso te puedo decir que no tiene nada que ver con lo que pide FUNDAE en un curso bonificado.

Lo que mira el técnico

Me he pasado la semana pasada leyendo la norma con lupa: el Real Decreto 694/2017, la resolución del SEPE de noviembre de 2025 para el ejercicio 2026, las instrucciones de seguimiento y control y las preguntas frecuentes de FUNDAE. No te lo recomiendo como lectura de playa, pero de ahí se saca una lista corta.

En teleformación el técnico entra y busca, en primer lugar, que la plataforma registre la actividad de cada participante, y no me refiero a que haya un curso, sino a que se pueda reconstruir, alumno a alumno, cuándo entró, cuánto tiempo estuvo, qué vio y en qué orden. Después busca que haya controles de aprendizaje repartidos a lo largo del curso y que cada alumno que se declara finalizado haya hecho al menos el 75 % de ellos, porque ese es el criterio que decide quién se bonifica y quién no. Aquí hay un detalle que conviene saber entero: una sentencia de 2018 tumbó el criterio del 75 % de tiempo de conexión porque no estaba escrito en ninguna norma, y la instrucción del SEPE de 2019 lo recoge así. Sobre el papel, lo exigible son los controles. En la práctica, y esto lo he vivido en actuaciones de seguimiento, el técnico te pide las horas de conexión igual y espera ver ese 75 % (un curso de sesenta horas con cuarenta minutos de conexión canta, y no hay controles que lo arreglen). Así que yo trabajo con las dos cosas: lo que dice la norma y lo que mira la persona que tiene delante tu plataforma.

Luego busca que exista un tutor de verdad, con actividad registrada en la plataforma (mensajes, respuestas en el foro, tiempos de respuesta), a razón de uno por cada ochenta alumnos como máximo. Busca que las claves que comunicaste funcionen y le dejen verlo todo sin tocar nada. Y da por hecho que todo eso se conserva cuatro años, porque el requerimiento puede llegar dos ejercicios después y te dan diez días hábiles para contestar.

Cuando lo escribes así parece poca cosa. El problema viene ahora.

Lo que Moodle no guarda

Moodle registra cuándo entras, pero no registra cuándo sales. Parece un detalle, pero significa que el tiempo de conexión no existe en un Moodle recién instalado. Lo que existe es una lista de clics con su hora, y a partir de ahí cada uno estima como puede. Hay un plugin de la comunidad muy usado que hace exactamente eso, estimar sesiones a partir de la distancia entre clics, y a mucha gente le ha servido en una visita. Pero es una estimación, y lo sabes tú, lo sabe el técnico y lo sabe la persona a la que le toca explicar por qué las horas no cuadran.

Tampoco hay nada que calcule el 75 % de controles. Se puede sacar con informes configurables o con SQL, y yo lo he hecho más veces de las que me gustaría, normalmente la tarde antes de una visita. No hay un rol de técnico de seguimiento preparado, se fabrica a mano a partir de un profesor sin permiso de edición quitando capacidades una a una. Y no hay ningún sitio donde pulsar un botón y que salga el expediente completo de un alumno.

Cuando me di cuenta de que llevaba años resolviendo esto a mano, con SQL y paciencia, y de que los centros con los que hablo ahora lo resuelven igual o peor, dejó de parecerme un problema mío y empezó a parecerme un producto.

Lo que estoy construyendo

Se llama local_fundae y es un plugin local de Moodle. La lista de lo que hace sale directamente de la lista de lo que mira el técnico, y no al revés, y eso me parece importante: no he empezado por las funcionalidades que quedan bonitas, he empezado por el guion de una inspección.

Lo primero ha sido medir el tiempo en vez de estimarlo. Un módulo JavaScript late cada minuto mientras el alumno está activo en el curso y se para cuando la pestaña se esconde o cuando no hay ratón ni teclado durante el tiempo que configures. Cada sesión tiene inicio, fin y duración activa de verdad. Ha ido primero por una razón: es lo único que no se puede reconstruir a posteriori. Los controles y las tutorías están en la base de datos aunque el plugin no exista; el tiempo, si no lo mides cuando pasa, se ha ido. Y ya que estamos, te cuento lo primero que ha salido mal, que prometí contarlo: el trozo de código que inyecta el latido en el pie de cada página leía la configuración del plugin antes de comprobar si Moodle estaba instalado del todo, y me reventó el asistente de instalación de una Moodle nueva con un error de tabla inexistente. Se arregla poniendo las comprobaciones que no tocan la base de datos por delante, y ya está corregido, pero me parece importante contarlo porque es el tipo de fallo que no aparece en ningún manual y que solo sale instalando en limpio.

Después va el 75 % calculated y con aviso a tiempo, y aquí he tomado una decisión por lo que te contaba antes: el plugin lleva tres indicadores por alumno, el de controles de aprendizaje, el de contenidos del itinerario recorridos y el de horas de conexión frente a las horas del curso, cada uno con su umbral y su interruptor, los tres al 75 % por defecto. Si un centro solo quiere el criterio de la norma, apaga los otros dos; si su técnico le pide horas, ya las tiene. Marcas qué actividades del curso son controles, el plugin lleva la cuenta y a mitad de curso avisa al tutor de quién va retrasado, que es cuando todavía sirve de algo avisar. Si todos los controles tienen la misma fecha también avisa, porque "distribuidos a lo largo del curso" quiere decir precisamente eso.

Luego un rol de seguimiento hecho para esto, de solo lectura, con auditoría de cada acceso y una pantalla que genera el texto que se pega en la comunicación de inicio (URL, usuario y contraseña, con las contraseñas cifradas y visibles solo con permiso). Y cuando el técnico entra no aterriza en la portada de Moodle, aterriza directamente en el expediente del grupo. Eso no lo pide ninguna norma; lo pide haber estado en una visita viendo a alguien buscar un informe durante diez minutos.

También el dossier, un PDF por alumno y otro por grupo con fecha y una huella SHA-256 impresa en el pie y guardada en base de datos, para poder demostrar que el documento de hoy es el mismo que generaste el día que cerraste el grupo. Un requerimiento se contesta en minutos en vez de en días. Con la misma maquinaria salen el diploma y el certificado de asistencia, con los códigos de acción y de grupo, y el alumno no puede descargar el diploma hasta que ha contestado el cuestionario de evaluación de calidad, que es otra de las cosas que el técnico pide y que en Moodle no hay forma de encadenar sin un plugin.

Y un panel con tres vistas sobre los mismos datos: la del tutor, con semáforos por alumno; la del técnico, con el expediente; y la del gestor del centro, con todos los grupos y sus plazos. Este lo añadí al plan después de una conversación en la que caí en que un plugin que solo contabiliza es un plugin que nadie enseña en una demo.

El plugin lo vamos a vender desde [FormaFlow](https://formaflow.esopen_in_new), que es la empresa que montamos Inma y yo para dar servicios digitales a centros de formación, junto con la implantación y el acompañamiento en la primera visita de seguimiento, que al final es lo que un centro necesita de verdad. Ahí estará la ficha y la demo cuando esté publicado.

Te digo desde ya lo que no va a hacer, para que no haya sorpresas: no va a subir los ficheros a la aplicación de FUNDAE ni va a firmar nada. FUNDAE no tiene API. Tiene una carga masiva de ficheros XML validados contra unos esquemas que cambian cada enero, y la firma la hace una persona con su certificado digital. Eso se puede preparar, y de hecho lo estoy preparando en otra pieza que hablará con el plugin, pero prometer que se automatiza la firma sería mentir sobre lo que permite el procedimiento.

Cómo lo estoy construyendo

Esta es la parte que más me apetecía contar y la que más me cuesta resumir.

Tengo un plan de doce jornadas (voy por la séptima y está previsto terminar el 15 de septiembre), con un objetivo por día, un criterio de terminado que se comprueba contra el sistema y no contra el documento, y una acción comercial que abre cada jornada antes de tocar la terminal. Esto último viene de un proyecto anterior en el que llegué al día nueve con un sistema precioso en producción y cero euros facturados, porque el plan solo miraba al producto. Esta vez el día no está cerrado si la llamada no se ha hecho, por muy bien que esté el código.

Cada jornada es una sesión nueva de Claude Code con la carpeta del proyecto conectada. La sesión lee el estado del proyecto (una pantalla, se reescribe entera cada día), las reglas y el contexto del día, que trae los bloques de trabajo con el prompt exacto de cada uno. Y aquí está lo que más me ha cambiado la forma de trabajar: cada bloque lo hace un tipo de agente distinto con un modelo distinto. El inventario del servidor lo hace un agente de solo lectura con el modelo más barato, porque describir no es decidir. El código con riesgo (el latido, los permisos, el cálculo del 75 %) lo escribo con Opus en la sesión principal. Las pruebas, las cadenas de idioma y los informes los hace un subagente con Sonnet a partir de una especificación cerrada. Y el modelo grande, el caro, lo uso tres veces en todo el proyecto: para la arquitectura del primer día y para dos revisiones en las que un agente que no ha escrito ni una línea del plugin se dedica a intentar romperlo.

El revisor nunca es quien escribió. Esa regla la tengo por escrito porque, cuando no está escrita, una se revisa a sí misma y se aprueba.

En la sexta jornada Inma, mi socia, hizo de técnica de FUNDAE. Entró solo con las claves del usuario de seguimiento y el texto de la comunicación de inicio, sin que yo le explicara nada, y recorrió la lista de lo que mira un técnico. La regla era que el acta tenía que tener al menos un "no pasa", porque si no lo tiene es que no se ha mirado bien. Encontró que el informe del expediente no mostraba la fecha de emisión del diploma cuando el alumno aún no lo había descargado, obligando al técnico a deducirlo. Lo corregimos esa misma tarde añadiendo el estado del certificado y la marca temporal exacta de generación.

Hoy estoy en la parte en la que el plugin empieza a hablar con el resto: unos servicios web para que nuestro ERP lea los grupos, los alumnos y sus evidencias sin tocar la base de datos de Moodle, que es la puerta por la que después saldrán los ficheros XML. Y me quedan por delante los dos días en los que la máquina no puede hacer nada por mí: el día que bajo los esquemas XML del ejercicio 2026 con mi certificado y el día que subo una acción de prueba a la aplicación real de FUNDAE a ver qué me dice. Esos dos días están acotados en tiempo y tienen plan B escrito, porque nada que dependa de una administración puede bloquearme una semana.

Lo que no sé todavía

Sé lo que mira el técnico, sé lo que le falta a Moodle y sé cómo lo estoy construyendo. Lo que no sabía hasta esta semana es cuánto cuesta esto de verdad, y por eso lo primero que hice, antes de escribir código, fue llamar a centros y preguntar. Lo que me han dicho es que un centro mediano hace entre cincuenta y doscientos grupos bonificados al año y que cerrar cada uno le lleva entre tres y cuatro horas de justificación, o sea, entre ciento ciento cincuenta y ochocientas horas al año dedicadas a preparar evidencias e introducir datos. Y un detalle que no esperaba: cuando dicen que lo que más tarda es "meter a los alumnos", no hablan de Moodle, hablan de la aplicación de FUNDAE. Por eso la otra pieza, la que preparará los ficheros XML, no es un extra, es la mitad del problema.

Lo que sigo sin saber es cuánto le han minorado o anulado a un centro en los dos últimos años por evidencias flojas, porque esa es la cifra que nadie te dice de primeras. Si la tienes a ojo, me harías un favor enorme contándomela, con un número me vale.

Y si quieres probar el plugin cuando esté terminado, avísame y te aviso yo cuando lo tenga listo para testar (lo publicaremos en [formaflow.es](https://formaflow.esopen_in_new) y ahí podrás verlo funcionando). Quien lo pruebe en esta primera ronda lo va a tener gratis, porque lo que yo necesito ahora no es cobrarlo, es verlo funcionando en un Moodle que no sea el mío y con grupos de verdad, y eso vale más que cualquier factura.

Me puedes escribir a [rocio@rociofperal.com](mailto:rocio@rociofperal.com) o por LinkedIn.

En la siguiente entrega te cuento qué me dice la aplicación de FUNDAE cuando le subo los primeros ficheros XML generados desde el plugin, que es la parte más delicada, y lo que salga mal, que algo saldrá.

Un saludo, Rocío Fernández Peral Desarrolladora Full-Stack · Integración de IA