Una vez que hemos visto cómo se crean los objetos MDF, vamos a abordar una solución real. En el post vamos a ver las tripas de la solución y como sería el uso por parte de los empleados.
Como comenté anteriormente, para la funcionalidad, he creado 4 objetos
- Parking: Va a contener el parking, la ciudad y dirección donde esté el parking
- Planta: Va a contener el número de planta del parking, y estará asociado al parking específico
- Plaza: Va a contener el número de plaza con unas características propias y estará asociado a la planta
- Peticionplaza. Va a ser el enlace entre el empleado y la plaza de garaje
El objeto parking se definirá como sigue. En esta pantalla he creado todos los campos que van a formar el objeto (no todos tienen que verse y ya será decisión de lo que queremos mostrar y luego, a lo que los empleados tendrán acceso).
Como en muchas cosas, una cosa es lo que pretendemos hacer y otra lo que podemos hacer, así que lo mejor es mirar hacia el futuro y prever posibles funcionalidades. Que no las usemos ahora, no quiere decir que no las tengamos más adelante.
En este caso vamos a guardar la información del parking, básicamente el nombre, dirección y ciudad y país. Estos últimos con el objetivo de poder filtrar, si se quiere a limitar el uso según la ciudad/país.

Para cada objeto se definen la etiqueta, nombre, tipo de datos, visibilidad y si es obligatorio, pero también otra serie de condiciones, como de donde se obtiene el dato (que puede ser de un objeto o de una picklist o la longitud del campo si es un campo string). Al fin y al cabo, cada campo tiene su propia definición.

El objeto planta se define como sigue. Se puede tener en un parking de 1 a n plantas, de forma que no sea un limitante a la hora de que tengamos un parking con una planta y cambiemos de parking o se disponga de más plantas en un futuro. Todo con vistas y evitar limitaciones. También le veremos más sentido cuando veamos cómo se puede visualizar en el sistema

Este objeto lo he enlazado con el objeto Parking mediante las relaciones. Un campo puede pertenecer al objeto o puede ser un enlace, como en este caso. En ambos casos es un dato a rellenar que además, podemos hacer que esté filtrado en base al dato seleccionado en otro campo.

El objeto plaza quedaría de la siguiente forma. Al igual que los otros objetos, tiene sus campos propios y sus enlaces. En este caso, las plazas tienen distintas categorías para poder utilizarlas o no.

Con enlace a los anteriores

Por último, el objeto peticionplaza. Este objeto es especial porque es el que relaciona al empleado con la plaza, y en el que se podrá solicitar plaza según el parking y la planta solicitada. El empleado podrá solicitar plaza y podrá indicar una en particular. Recursos Humanos, o quien corresponda, podrá tenerlo en cuenta para asignar una cercana si no está libre la que se solicita o tener en cuenta los comentarios del empleado

Una vez que hemos definido los objetos, vamos a ver cómo quedaría la relación entre ellos con un ejemplo.

Todos los enlaces son dependientes temporales, es decir, una plaza estará ocupada por un empleado a través de una petición durante un tiempo y solo a partir de que el objeto superior esté creado. Puede ser infinito o limitado y que después corresponda a otro empleado o quede libre.
El objeto Peticionplaza quedará enlazado con el empleado en el perfil del empleado. Es la configuración del perfil del empleado donde diremos en qué sección y bloque estará esta funcionalidad.
Y por último, cuando el empleado acceda a su perfil, podrá ver la funcionalidad y utilizarla, porque le hemos dado permisos para ello. Al igual que el departamento de Recursos Humanos o quien se encargue de las tareas, pero esto ya depende de los permisos que otorguemos.

La parte más fácil, es el uso (aunque muchos clientes no opinarán igual). El empleado solo debe acceder a su perfil, ir al apartado de plaza de garaje y solicitar la plaza.
En este caso, Juanjo entrará por la opción de editar, lo que le permitirá solicitar la plaza

Por los permisos que tiene, podrá acceder a todos estos campos

Solo es obligatorio indicar que se quiere una plaza de garaje, indicar cual, es optativo

Y en cada una de las opciones se activarán distintos filtros, según lo solicitado. En este caso no se limita la solicitud de parking a ciudad ni país, y la planta y la plaza si serán dependientes de lo elegido en el campo anterior


Una vez solicitado, se activa un workflow de aprobación donde los siguientes responsables decidirán si otorgan la plaza, la cambian o la rechazan.
Y hay que recordar, que al empleado le permitimos poner una plaza de referencia, podría ser únicamente permitido rellenar el campo ¿Desea solicitar plaza de garaje? Todo ello gestionado por los permisos RBP.
En este caso, al pedir Juanjo una plaza de garaje, me salta a mí la aprobación, y una vez confirmada, con cambios o sin cambios, le llegaría un correo a Juanjo y a Charles, como su responsable. Porque así está definido en el workflow.

Una vez grabado, al entrar en mi cuenta me aparece directamente la tarea con la solicitud de Juanjo


En este punto puedo poner comentarios a la petición, devolverla, actualizarla con la nueva plaza si es necesario y por último, aprobarla.

Y una vez aprobado, Juanjo podrá ver la plaza que le ha sido asignada y, si se lo permitimos, como en este caso, ver las características de la misma. Y con esto, se ha completado el proceso de petición de la plaza de garaje.

Con esto doy por finalizada esta segunda parte, pero voy a dejar lanzadas unas preguntas para el siguiente.
¿Cómo se dan de alta y baja nuevos parkings, plantas y plazas?
Recursos Humanos tiene que gestionar todo esto (o a quién corresponda) pero, ¿cómo pueden hacerlo?
Como comentario personal a este post, todo es mejorable funcionalmente, es decir, podemos dar más funciones al empleado, podemos darle menos, podemos mostrarle información de la plaza antes de enviar o podemos dotarle de un informe con la situación y característica de cada plaza. Así sin pensar mucho es lo que se me ocurre a mí, pero en lo que más pienso es en no limitar de entrada la funcionalidad y pensar en los actores actuales y posibles actores a futuro. Como digo normalmente, ahora no quieres eso pero… ¿podrías quererlo?
Estos puntos los veremos en el siguiente post