El evento al cambiar es el que ejecuta una regla cuando el usuario cambia el valor de un campo. Es el único evento de los elementos HRIS que se asigna a un campo y no al elemento: en Gestionar configuración empresarial se entra al elemento, por ejemplo jobInfo, se elige el campo y ahí se agrega la regla. Desde ese momento, cada vez que alguien cambia ese campo en un formulario, la regla corre.
Su gran ventaja es que el resultado se ve en el momento. Cuando AR_CC por departamento está asignada al campo departamento, el centro de costos aparece en cuanto se elige AR_VTA, antes de guardar. El usuario ve qué se completó, puede revisarlo y, si hace falta, cambiarlo. Por eso la lección lo propone como el evento natural de todo lo que ayuda a completar un formulario: valores por defecto que dependen de otro campo, cambios de visibilidad u obligatoriedad, avisos tempranos.
Los valores por defecto de la unidad lo usan así. AR_CC por departamento se asigna al campo departamento. AR_Modalidad por defecto se asigna al campo entidad legal, porque así cubre las altas y los traslados desde otra entidad legal de Best Run. Y la regla del ejercicio de la L2 que vuelve obligatorio el fin del período de prueba para AR01 también va en el campo entidad legal, al cambiar.
El evento tiene limitaciones que conviene conocer. La primera es que solo corre si el campo cambia. Si un empleado de AR01 se edita sin tocar la entidad legal, una regla asignada a ese campo no corre. Por eso, en el ejercicio, la obligatoriedad del fin del período de prueba se complementa con una validación al guardar. La segunda es el comportamiento de los mensajes. La nota 3736295 describe que, en el perfil más reciente, una regla al cambiar con severidad error se muestra como una advertencia que no bloquea. Una validación que tiene que frenar un dato no puede depender solo de este evento: va al guardar, aunque también se asigne al cambiar para avisar antes.
La tercera limitación aparece en las cargas masivas. La nota 2283442 explica que, en las importaciones y en los cambios masivos, las reglas al cambiar se ejecutan aunque el campo no haya cambiado. Eso significa que una regla que en la pantalla corre solo cuando el usuario elige un departamento, en una importación corre en todas las filas. Si la regla no tiene una condición que la proteja, como la de "está vacío", puede pisar datos en forma masiva. Es una de las razones para revisar el contexto de cada regla al cambiar antes de una carga, como vemos en la L4.
El evento al cambiar admite contexto de regla, según la nota 3696599, así que se puede decidir que no corra en las importaciones o en los cambios masivos. En el VIDEO 4.2, AR_CC por departamento queda con No en esos dos contextos.
Un consejo para el diseño: cuando una regla al cambiar dependa de varios campos, asignala a cada campo que puede disparar el cambio, o pensá si no conviene al guardar. Una regla asignada a un solo campo ignora los cambios en los demás.
