El SEPE te pide un servicio web SOAP. Te lo dejamos funcionando y validado.

Es un servicio web que se instala sobre tu Moodle y que permite a la administración consultar de forma automatizada los datos de seguimiento del alumnado de tus acciones formativas de teleformación, sin pedírtelos ni esperar a que se los envíes.

Funciona con el protocolo SOAP y responde a un descriptor WSDL publicado por el propio SEPE, que define qué métodos debe exponer tu plataforma, qué parámetros acepta cada uno y en qué formato exacto debe devolver la información.

Lo necesitas porque es un requisito técnico para que tu plataforma pueda quedar inscrita para impartir especialidades formativas en teleformación, dentro de lo que exige el Anexo II de la Orden TMS/369/2019. No es una recomendación: sin ese servicio funcionando y validado, la plataforma no cumple.

Y no vale con implementarlo aproximadamente. Se valida contra un kit de autoevaluación que comprueba las respuestas campo a campo: una etiqueta mal nombrada, un formato de fecha distinto o un campo vacío donde debería haber valor hacen que la validación falle.

El servicio debe exponer los métodos definidos en el WSDL del SEPE, entre ellos los que devuelven los datos identificativos del centro y el listado de acciones formativas, además de los que informan de participantes, conexiones, tiempos y resultados de las actividades de aprendizaje.

El SEPE publica un kit de autoevaluación bastante completo: incluye documentación, una prueba funcional y un proyecto preparado para ejecutar las pruebas con SoapUI. Es la referencia con la que hay que trabajar, y es la que determina si tu servicio da la talla.

Mucha gente empieza probando solo con SoapUI cargando el WSDL a mano y construyendo peticiones. Sirve para ir viendo el comportamiento, pero no sustituye al kit: es habitual tener respuestas que parecen correctas en SoapUI y fallan la validación oficial.

La recomendación práctica, y la que nosotros aplicamos siempre, es probar la URL de seguimiento antes de presentar la solicitud. Descubrir que el servicio no valida cuando el expediente ya está en trámite es el peor momento posible.

Es el error más reportado por quienes intentan implementar esto por su cuenta, y aparece al parsear el WSDL: el cliente SOAP encuentra en el descriptor una extensión de política de servicios web que no sabe interpretar y aborta con un fallo de tipo SOAP-ERROR: Parsing WSDL.

No es un error de tu Moodle ni de tu servidor: viene del propio descriptor. De hecho, se han detectado incidencias tanto en el WSDL como en la aplicación validadora del SEPE, incidencias que el propio organismo ha reconocido y corregido en versiones posteriores del kit.

La consecuencia práctica es que hay que saber contra qué versión del WSDL estás trabajando y cómo tratar esas extensiones para que el cliente pueda procesarlo. Es exactamente el tipo de problema que consume semanas a quien lo aborda sin haberlo visto antes, como reflejan los hilos de los foros técnicos de Moodle en español desde hace años.

En nuestro caso es trabajo conocido. No es que tengamos un truco secreto: es que ya nos hemos peleado con ello y sabemos dónde mirar.

Ese error significa que la respuesta que tu servicio está devolviendo no se ajusta a la estructura que el WSDL declara: falta un elemento obligatorio, hay un tipo de dato que no coincide, o la jerarquía de nodos no es la esperada.

Suele ir acompañado de errores de programación clásicos —usar un objeto donde se espera un array, por ejemplo— que no son propiamente de SOAP sino de cómo se está construyendo la respuesta. Es la fase en la que más gente se atasca: el servicio arranca, responde algo, pero no responde exactamente lo que se le pide.

El origen del problema muchas veces no está en el código del servicio sino en los datos: campos que se devuelven vacíos porque en Moodle nunca se han rellenado, identificadores de alumno que no siguen el formato requerido, o fechas registradas con criterios distintos según quién matriculó.

Cuando el fallo viene de ahí, te lo explicamos y te decimos qué habría que ajustar en la gestión del campus. A veces la corrección está en un campo de matriculación que lleva años rellenándose de forma libre y ahora necesita un criterio.

Esta es una duda muy habitual y la respuesta es más sencilla de lo que parece: el SEPE utiliza siempre el mismo usuario. Lo que tú tienes que facilitar al solicitar la inscripción es la URL de seguimiento de tu plataforma y la contraseña que le hayas asignado.

En el lado de Moodle eso implica tener habilitado el protocolo SOAP en los servicios web, un servicio configurado con las funciones necesarias, un rol con los permisos adecuados y un usuario asociado a ese servicio. Es una configuración que hay que hacer con cuidado, porque unos permisos de más son un riesgo de seguridad y unos de menos hacen que la validación falle.

Nosotros dejamos esa configuración hecha y documentada, con los permisos ajustados a lo mínimo necesario para que el servicio responda.

Ten en cuenta que esos datos forman parte de tu expediente. Si cambias la contraseña o mueves la plataforma de URL después de la inscripción, hay que actualizarlo, y no es infrecuente que un servicio deje de responder por este motivo meses después.

Técnicamente se puede: hay implementaciones publicadas y los foros de Moodle en español acumulan años de hilos de gente intentándolo. Ahora bien, esos mismos hilos son la mejor descripción de lo que implica: mensajes de personas que llevan semanas peleándose con el mismo error y acaban pidiendo ayuda.

El trabajo no es solo escribir un servicio SOAP. Es entender el modelo de datos que espera el SEPE, mapearlo contra cómo tu Moodle guarda realmente la información, manejar las particularidades conocidas del WSDL y validar contra el kit hasta que responde a todo correctamente.

Si tienes un desarrollador con experiencia en servicios web y tiempo disponible, adelante: te ahorrarás el coste. Si lo que tienes es un informático que además lleva las impresoras y el correo, la cuenta suele salir a favor de externalizarlo, sobre todo porque el coste real no es el dinero sino el retraso en poder impartir.

Te lo decimos así de claro porque preferimos que decidas con la información completa antes que venderte urgencia.

Funciona sobre cualquier instalación razonablemente actualizada, incluidas las que llevan años en marcha con temas personalizados, plugins de terceros y configuraciones heredadas. No exigimos una instalación limpia ni una versión concreta y reciente.

Antes de nada hacemos una revisión técnica: versión de Moodle, versión de PHP, extensiones disponibles en el servidor —especialmente el soporte SOAP—, estado de la configuración de servicios web y salud general de la base de datos. Con eso te decimos si funciona directamente, si hace falta un ajuste previo o si hay un impedimento real.

El caso más frecuente de bloqueo no es la versión de Moodle, sino un servidor con las extensiones de PHP recortadas o con los servicios web desactivados por política del proveedor de alojamiento. Se resuelve, pero conviene detectarlo el primer día.

Si aparece un impedimento serio, te lo decimos antes de cobrarte nada. Preferimos perder un proyecto a instalar algo que va a fallar la validación y dejarte con el problema.

No. El servicio se instala sobre tu Moodle actual, en tu dominio actual y en tu alojamiento actual. No hay migración, no hay cambio de URL y no hay que avisar a los alumnos de nada.

Es una diferencia importante frente a la alternativa habitual, que es contratar una plataforma nueva ya preparada y mover todo el histórico. Si tu campus lleva años funcionando, tiene cursos vivos y una configuración que tu equipo conoce, mover todo eso tiene un coste y un riesgo que no siempre compensa.

Tampoco tocamos el núcleo de Moodle. Se instala como componente independiente, de modo que las actualizaciones futuras de tu plataforma no lo van a romper ni él va a impedir que actualices.

Si más adelante decides cambiar de alojamiento o migrar el campus, el servicio se reinstala en el destino. No te ata a un proveedor concreto, aunque recuerda actualizar la URL de seguimiento en tu expediente.

No los sustituye, los complementa desde otro ángulo. Tus informes sirven para la gestión interna y para la documentación del expediente. El servicio SOAP sirve para que la administración consulte los datos directamente, sin intermediarios y sin transcripciones.

La diferencia está en la naturaleza del dato. Un informe es una foto que alguien generó en un momento dado, y entre esa foto y la realidad puede haber errores de transcripción o criterios distintos según quién lo preparó. El servicio web devuelve el dato tal y como está registrado, en el momento de la consulta.

Esa distinción importa cuando llega una comprobación: la coherencia entre lo que dice tu documentación y lo que dicen los registros de la plataforma es exactamente lo que se revisa.

Lo que sí puede ocurrir es que, al conectarlo, aparezcan incoherencias que ya existían en tus datos. Es incómodo, pero mucho mejor descubrirlas ahora que en un requerimiento.

La validación entra en el servicio. No te entregamos el plugin instalado y te dejamos la responsabilidad de que pase las pruebas: lo conectamos, lo probamos contra el kit de autoevaluación del SEPE y trabajamos sobre él hasta que responde correctamente a todos los métodos.

Los motivos habituales de fallo son concretos y conocidos: campos vacíos porque el dato no se registra en el campus, formatos de fecha que no coinciden, identificadores que no siguen el formato requerido, permisos del servicio web mal ajustados o particularidades del propio WSDL.

Si el fallo procede de cómo está registrada la información en tu Moodle y no del servicio en sí, te lo explicamos y te decimos qué habría que corregir en la gestión.

El compromiso es dejarlo validado. Si eso implica más iteraciones de las previstas por una particularidad de tu instalación, se hacen, sin recargo.

El plazo depende sobre todo del estado de tu instalación y de la agilidad para conseguir los accesos técnicos al servidor y al panel de administración. Ese suele ser el cuello de botella real, especialmente cuando el alojamiento lo gestiona un tercero.

El trabajo tiene tres fases: revisión técnica de la instalación, instalación y configuración del servicio, y validación contra el kit hasta que responde correctamente. Te damos una estimación al arrancar, una vez visto con qué nos encontramos.

No damos un número de días cerrado antes de haber mirado tu instalación, y desconfía de quien lo haga. Un Moodle limpio y actualizado no tiene nada que ver con uno que arrastra ocho años de plugins y tres administradores distintos.

Lo que sí te decimos desde el principio es el precio, que es cerrado y no varía porque tu instalación resulte más trabajosa de lo previsto.

El marco normativo lleva años en movimiento —Ley 30/2015 y su Real Decreto 694/2017, Orden TMS/369/2019, Ley Orgánica 3/2022, Real Decreto 659/2023, Real Decreto 1189/2025— y es razonable esperar que los requisitos técnicos se sigan ajustando. El propio WSDL ya ha tenido revisiones.

Si el SEPE modifica el descriptor, añade métodos o cambia el formato de respuesta, el servicio necesita actualizarse. Te avisamos cuando ocurra y te decimos qué implica en tu caso, sin esperar a que te enteres por un requerimiento.

El precio es un pago único por URL, no una suscripción, así que las actualizaciones por cambio normativo se valoran cuando se producen. Somos transparentes con esto: no vendemos actualizaciones ilimitadas de por vida porque no sabemos qué pedirá la normativa dentro de cinco años.

Lo que sí puedes esperar es que estemos al tanto. Seguimos el BOE y los canales técnicos del SEPE porque es nuestro trabajo, no como favor.

Además del servicio SOAP tenemos tres módulos que cubren las otras dimensiones del seguimiento que la normativa exige y que, por separado, la mayoría de los centros resuelve a mano.

El control de IP y accesos registra desde qué dirección y en qué momento se conecta cada alumno, lo que permite acreditar la actividad real y detectar patrones que conviene revisar antes de que lo haga otro. Enlaza directamente con la obligación de generar registros de interacción de cada usuario.

Los informes de auditoría generan de un clic los listados que se piden en un seguimiento: tiempos de conexión por participante, progreso por control periódico, actividad por grupo y por acción formativa, y participantes por tutor y periodo, todo exportable.

Los diplomas con verificación QR emiten certificados con un código único verificable en línea, de modo que una empresa o una administración pueda comprobar su autenticidad sin llamar a tu centro. Los cuatro módulos funcionan de forma independiente: puedes instalar solo el que necesites.

Es un pago único por URL de plataforma. Instalado y validado, el servicio es tuyo y no genera cuota mensual, ni recargos por número de alumnos, ni límites de uso que se activan al superar cierto volumen.

Lo estructuramos así por una razón concreta: el número de alumnos de un centro fluctúa mucho a lo largo del año, y un modelo por participante convierte una buena temporada en una factura más alta justo cuando estás gestionando más trabajo. Nos parece un mal incentivo.

Si tienes varias plataformas en URLs distintas, cada una necesita su instalación y su validación, y se factura por separado, porque el trabajo técnico se repite en cada una.

Fuera del pago único quedan las actualizaciones por cambio normativo, si llegan a producirse, y cualquier desarrollo específico que pidas más allá de lo que exige la validación estándar.