Artículo de Laura Castro, especialista en Formación Bonificada • FUNDAE
Cuando Marcos entró, encontró a Clara revisando un listado interminable de fechas, tipos de contratos y movimientos de personal… ¡Caos en estado puro!
Clara: Oye Marcos, ¿qué pasa si inscribimos a una persona que no está dada de alta en la Seguridad Social el día de inicio y se nos cuela en la bonificación? ¿O si tenemos una persona que trabaja en dos empresas de la Compañía? Incluso tenemos personal en plantilla con beca que no podemos bonificar porque no cotizan en concepto de formación profesional. El riesgo de una bonificación mal aplicada es alto, y eso me preocupa.
Marcos: Es normal que te preocupe. En formación bonificada, el requisito es claro: la persona que finaliza sólo se podrá bonificar si el primer día del curso está dada de alta en el régimen correspondiente y cotizando por contingencia de formación profesional. Si no se cumple, no es bonificable. Y ahora mismo, ese control lo hacéis a mano. Esta forma de trabajar es un riesgo inmenso porque no controlas el estado de contratación y, claro, cuando llega la fase de comprobación de datos (o conciliación del crédito), ya sabes lo que le toca:
Clara frunció el ceño, consciente de que la teoría era impecable pero la práctica caótica.
Clara: Operativamente es muy difícil controlar todos esos supuestos en tiempo real, sobre todo en grupos grandes o en entornos multiempresa.
Marcos: Por eso el control no puede depender solo de una revisión manual previa. Cuando se genera el fichero XML el sistema ya ha realizado previamente una validación automática de los participantes. Antes de comunicar la finalización en FUNDAE se ha comprobado al milímetro si las personas son (o no) bonificables.
Clara levantó la mirada, escéptica por lo que acababa de oír.
Clara: ¿Esa validación detecta, por ejemplo, si alguien no está de alta el día de inicio?
Marcos: Exactamente. El cruce se realiza contra la información oficial disponible. Si la persona no figura de alta o no cotiza por formación profesional, el sistema devuelve la incidencia. Lo mismo ocurre si hay incoherencias en los datos identificativos.
Clara aprovechó para plantear un caso más complejo.
Clara: ¿Y qué pasa con el personal que está contratado en dos empresas del mismo Grupo Empresarial?
Marcos hizo un gesto leve, como quien entra en un terreno más fino.
Marcos: Ahí el matiz es técnico. La bonificación se aplica sobre la empresa que comunica el grupo y que asume el coste. Si el trabajador tiene doble relación laboral, debe estar correctamente vinculado en la empresa que realiza la comunicación y la imputación de costes debe ser coherente. El XML siempre identifica una empresa concreta. Si la situación no es consistente, el proceso en FUNDAE dará error.
Clara: Entiendo… pero depender solo del momento de la comunicación a FUNDAE nos deja un margen de reacción muy limitado.
Marcos: Correcto. Por eso la integración entre GIF y el ERP de RRHH es crítica. Cuando GIF se integra mediante API, la actualización de datos es en tiempo real. Altas, bajas, cambios de centro, variaciones contractuales… todo se sincroniza al instante.
Clara: ¿Al minuto real o mediante procesos batch diarios?
Marcos: Depende de la configuración, pero en entornos bien parametrizados funciona por servicios web o procesos de alta frecuencia. Si una persona causa baja hoy a las 10:00, el dato se replica en GIF casi de inmediato. Si intentas inscribirla en un grupo que empieza mañana, el sistema ya mostrará la situación actualizada.
Clara: Eso reduce mucho el riesgo previo a la comunicación.
Marcos: Es una clave preventiva. Antes incluso de generar el XML, GIF ya trabaja con datos vivos del ERP: régimen de cotización, empresa activa, centro de trabajo, colectivo, situación contractual. Así, cuando se construye el fichero para subir a FUNDAE, la probabilidad de incidencia se minimiza.
Clara: ¿Y qué ocurre con las personas que tienen una beca y que no cotizan por formación profesional?
Marcos: Si en el ERP de RRHH están identificados con un acuerdo de colaboración tipo beca, la integración trasladará esa condición a GIF. El sistema puede bloquear su inclusión como bonificables o marcarlos como no elegibles. De esta forma no se incorporan al XML como participantes bonificados.
Clara repasó mentalmente el circuito y lo verbalizó:
Marcos: Exacto. Es una doble capa de control: coherencia interna gracias a la integración y validación oficial en la carga masiva. El resultado es un proceso con mínima exposición a riesgos técnicos y económicos.
Clara: Ok, eso cambia el enfoque. Ya no es solo comunicar a tiempo, sino comunicar con datos consistentes.
Marcos: Ese es el punto de equilibrio.
Si eres de los que quieren avanzar,, hablemos.