La entidad de origen y la entidad de destino son los dos lados de una regla entre entidades. La entidad de origen es la que se modifica y dispara la regla: el elemento donde se asigna. La entidad de destino es la que la regla cambia: el elemento cuyos campos se establecen, o donde se crean o eliminan registros. La academia lo describe así: la regla se dispara desde la entidad de origen y los cambios se ejecutan en la entidad de destino.
En AR_Grupo de pago por grado, el origen es la información del puesto, con el modelo de información del puesto como objeto base, y el destino es la compensación. La regla se asigna en jobInfo, al guardar, porque es ahí donde ocurre el cambio que la dispara: el cambio de grado. El grupo de pago, en cambio, se establece en la compensación, aunque el usuario nunca haya abierto esa pantalla.
Las entidades admitidas son limitadas. La nota 2437420 indica que las reglas entre entidades funcionan solo entre entidades del empleo: información del puesto, compensación, componentes de pago recurrentes y no recurrentes, relaciones del puesto y detalles del empleo. No se pueden usar, por ejemplo, para cambiar datos personales desde la información del puesto, ni para cambiar un objeto de fundamento. Y la nota 3338090 agrega una restricción más reciente: los detalles del empleo ya no pueden ser origen de reglas hacia la compensación, los componentes de pago o las relaciones del puesto.
Las combinaciones más frecuentes en los proyectos tienen como origen la información del puesto. Un cambio de grado ajusta el grupo de pago o el rango salarial. Un cambio de ubicación crea o elimina un componente de pago por zona, como el AR_ZONA del ejercicio de la L4. Un cambio de jornada recalcula un componente de pago recurrente. Un cambio de manager actualiza una relación del puesto. En todos los casos, el usuario hace un cambio en el puesto y la regla mantiene coherente el resto del empleo.
Identificar bien el origen evita reglas que no corren. Si el cambio que tiene que disparar la regla ocurre en la compensación, el origen es la compensación, y la regla se asigna ahí. Si ocurre en la información del puesto, se asigna en jobInfo. Una regla asignada en el elemento equivocado no da error: simplemente no corre cuando se espera.
El destino, a su vez, condiciona la acción. Si el destino es un campo de un registro existente, la acción es Establecer. Si es un registro que hay que agregar, como un componente de pago, la acción es Crear. Si es un registro que hay que quitar, Eliminar. En los dos últimos casos conviene pensar qué pasa si la regla corre más de una vez, por ejemplo cuando se edita una solicitud de flujo, como vimos en la L3.
Al documentar una regla entre entidades, conviene escribir en la descripción el origen, el destino y el evento: "origen jobInfo, destino compensación, al guardar". Con un límite de cinco reglas, saber qué origen y qué destino cubre cada una es la información que permite decidir dónde agregar una rama nueva.
