Un objeto base de modelo es la variante de objeto base que SAP recomienda para las reglas de Employee Central. Cada elemento HRIS tiene uno: el modelo de información del puesto (Job Information Model), el modelo de compensación, el modelo de información del empleado, y así con los demás. La nota 3338090 los indica como los recomendados, y la academia explica la razón principal: solo con ellos se pueden manejar las propiedades de un campo.
La diferencia con un objeto base estándar se ve en el editor. Con el estándar, cada campo ofrece su valor. Con el de modelo, cada campo ofrece cuatro propiedades, que resumimos en la Tabla 1.3 de la lección. Obligatorio (Required) permite volver un campo obligatorio, o no, según una condición. Visibilidad (Visibility) permite ocultarlo, mostrarlo editable o dejarlo solo para ver. Valor (Value) permite leer o establecer el valor actual. Y Valor anterior (Previous Value) permite comparar el valor nuevo con el que tenía el registro, para actuar solo si cambió.
Las dos primeras propiedades son las que justifican el modelo en las reglas que cambian el comportamiento del formulario. La academia lo dice así: los objetos base de modelo son necesarios para establecer las propiedades de un campo, como obligatorio, con valores verdadero o falso, y visibilidad, con las opciones ninguna, editar o ver. Sin el modelo, una regla no puede, por ejemplo, volver obligatorio el fin del período de prueba solo para AR01, que es la consigna 3 del ejercicio de la L2.
La cuarta propiedad, el valor anterior, es la que más se usa en las reglas que reaccionan a un cambio. En la U5 L4 la usamos para que la alerta del período de prueba no se repitiera en cada guardado. En la L3 de esta unidad, AR_Derivar motivo de evento la usa para detectar un cambio de grado: el grado actual es distinto del grado anterior. Y AR_Grupo de pago por grado, en la L4, usa la misma comparación para decidir cuándo ajustar la compensación.
Usar el modelo desde el principio evita rehacer reglas. Una regla que hoy solo establece un valor puede necesitar mañana una condición sobre el valor anterior o un cambio de visibilidad, y si se creó con el objeto base estándar, hay que crearla de nuevo con el modelo. Por eso, en el caso del curso, todas las reglas de Best Run Argentina sobre la información del puesto usan el modelo de información del puesto.
Hay una aclaración que conviene hacer cuando se habla de propiedades. El modelo de datos también fija la obligatoriedad y la visibilidad de los campos, como vimos en la U3. La diferencia es de alcance: el modelo de datos las fija para todos; la regla las cambia según una condición. Si una propiedad no depende de nada, va en el modelo de datos, no en una regla, porque una regla agrega lógica que hay que mantener y probar.
Cuando se revisa una regla heredada que no funciona como se espera, una de las primeras cosas para mirar es si usa el objeto base de modelo. Muchas veces la limitación está ahí.
