Las empresas entregan equipos a su gente todos los meses: notebooks, teléfonos, herramientas, vehículos, credenciales de acceso.
La Asignación de activo es el registro que deja constancia de cada entrega, con la fecha en que ocurrió y la fecha en que el bien volvió.
Sin este registro, la ubicación de los bienes vive en la memoria de dos o tres personas y en una cadena de correos.
Eso se nota en tres momentos concretos, y ninguno de los tres avisa con anticipación.
Se nota cuando alguien se va y hay que saber qué tiene que devolver, se nota en un inventario físico donde falta un equipo que en realidad está en una casa, y se nota cuando un bien caro no aparece y nadie recuerda a quién se le entregó.
Un registro por entrega resuelve los tres con la misma consulta.
La asignación conecta una persona con un bien, y esos dos vínculos están construidos de forma distinta a propósito.
El vínculo con el Empleado es obligatorio y es de los fuertes: la asignación no existe sin su empleado y desaparece con él.
La consecuencia práctica es que toda entrega tiene destinatario, sin excepciones, y que la ficha de cada persona reúne su historial completo de equipos.
El vínculo con el Activo fijo es un campo de búsqueda y es opcional.
Esa flexibilidad permite dejar constancia de una entrega en el mismo momento en que ocurre, y completar después la identificación exacta del equipo entregado.
La fecha de asignación es obligatoria, porque es el hecho que el registro documenta.
La fecha de devolución es opcional, y su ausencia no es un descuido sino información en sí misma: significa que el bien todavía no volvió.
Cuando las dos están cargadas, la distancia entre ellas es el tiempo que el equipo estuvo en uso por esa persona, que es un dato útil para planificar reposiciones.
El registro muestra el nombre del bien acompañado de la palabra asignado, y esa marca aparece sola mientras la devolución esté vacía.
Al cargar la fecha de devolución, la marca desaparece por sí misma, sin que nadie tenga que cambiar un estado a mano.
Es un detalle chico con una consecuencia grande: la lista de lo que está afuera nunca queda desactualizada por olvido, porque no depende de un paso extra.
En el onboarding, la asignación es el último paso de la preparación: el equipo se entrega y la entrega queda registrada el mismo día.
En el offboarding, la consulta se hace al revés: se abre la ficha de la persona, se listan las asignaciones sin fecha de devolución y esa lista es la checklist de la salida.
Tener esa lista escrita evita la conversación incómoda de dos semanas después, cuando alguien recuerda que faltaba un cargador.
Conviene registrar todo bien que tenga valor patrimonial o que sea difícil de reponer, aunque su costo unitario no sea alto.
El criterio útil no es el precio sino la pregunta que queremos poder responder: si nadie va a preguntar dónde está, probablemente no haga falta registrarlo.
La asignación se crea desde la ficha de la persona, se consulta desde los dos lados y se cierra con una sola fecha.
Abrimos la ficha del empleado y creamos la asignación desde su Lista relacionada, con lo cual el vínculo con la persona queda resuelto solo.
Elegimos el activo fijo entregado y cargamos la fecha de asignación, que es la del día en que el bien cambió de manos.
El registro no lleva un título escrito a mano: se identifica con un número que genera el sistema, así que no hay que inventarle un nombre.
Desde la persona, la Lista relacionada muestra todo lo que se le entregó, con lo devuelto y lo pendiente en la misma vista.
Desde el equipo, la consulta corre al revés y muestra por qué manos pasó ese bien a lo largo del tiempo.
Y sobre el conjunto, una Vista de lista filtrada por fecha de devolución vacía devuelve todo lo que está afuera hoy, que es la consulta que más se repite.
Cuando el bien vuelve, cargamos la fecha de devolución en el registro existente en lugar de crear uno nuevo.
La marca de asignado se retira sola, y el equipo queda disponible para una entrega siguiente.
Nos conviene usar el campo de comentarios para dejar anotado el estado en que volvió, porque ese detalle es el que después explica una reparación o una baja.
La revisión que más rinde es cruzar las asignaciones abiertas contra la nómina activa de tu empresa.
Toda asignación sin devolución que pertenezca a alguien que ya no está es un bien a recuperar, y aparece en esa comparación sin necesidad de buscarlo.
Estas son las preguntas que aparecen al empezar a registrar qué equipo tiene cada persona de tu empresa.
Por la fecha de devolución: mientras esté vacía, el bien sigue asignado.
El registro además lo muestra marcado como asignado, y esa marca se retira sola al cargar la devolución.
Sí, porque el vínculo con el activo fijo es opcional.
Aun así, completarlo es lo que le da valor al registro, ya que sin el bien identificado la asignación no responde la pregunta que motivó cargarla.
Se eliminan junto con él, porque la relación con el Empleado es del tipo que hace al registro dependiente del padre.
Por eso conviene cerrar las devoluciones antes de dar de baja una ficha, así el historial de cada equipo queda completo.
Sí, y esa serie es justamente el historial del bien.
Cada vez que el equipo cambia de manos se crea una asignación nueva, y la anterior queda cerrada con su fecha de devolución.
No. La devolución se carga en el mismo registro de la entrega, que es el que ya tiene la fecha de origen.
Crear uno nuevo partiría en dos la historia de una entrega única y haría perder el tiempo de uso.
La asignación hereda el propietario de la ficha del empleado, así que no lleva uno propio.
La consecuencia práctica es que quien ve la ficha de una persona ve también sus asignaciones, con el mismo criterio de acceso.
Esta sección es para quien escribe requerimientos sobre el ERP y necesita nombrar los campos, las relaciones y las fórmulas con precisión.
El objeto se llama EGAFutura__Empleado_Asignacion_activo__c y tiene siete campos propios además del nombre del registro.
| Campo | Tipo | Nota |
|---|---|---|
| Name | Numeración automática | Etiquetado EGA Futura ID, no se escribe a mano |
| EGAFutura__Empleado__c | Master-Detail | Obligatorio, apunta a EGAFutura__Empleado__c |
| EGAFutura__Activo_fijo__c | Lookup | Opcional, apunta a EGAFutura__Activo_fijo__c |
| EGAFutura__Fecha_asignacion__c | Fecha | Obligatorio, es la fecha de la entrega |
| EGAFutura__Fecha_devolucion__c | Fecha | Vacía mientras el bien no vuelve |
| EGAFutura__Comentarios__c | Área de texto(255) | Estado del bien y notas de la entrega |
| EGAFutura__HFFT_Activo_Asignado__c | Fórmula (Texto) | Nombre del activo con la marca de asignado |
| EGAFutura__HFFL_Activo_Asignado__c | Fórmula (Texto) | El mismo texto, como hipervínculo al registro |
Los dos lados del registro se implementan distinto, y esa diferencia define todo el comportamiento del objeto.
| Etiqueta | Nombre de API | Tipo de relación |
|---|---|---|
| Empleado | EGAFutura__Empleado__c | Master-Detail obligatorio |
| Activo fijo | EGAFutura__Activo_fijo__c | Lookup opcional |
Las dos arman el mismo texto y se diferencian en cómo lo presentan.
| Campo | Qué devuelve |
|---|---|
| HFFT Activo Asignado | El nombre del activo, con el agregado de asignado entre paréntesis cuando la fecha de devolución está vacía |
| Activo Asignado | Ese mismo texto convertido en enlace al registro de la asignación |
El objeto no tiene campo de propietario, y eso no es un olvido: al ser hijo Master-Detail de Empleado hereda el propietario del padre. Cualquier requerimiento sobre quién ve qué asignaciones se resuelve sobre la ficha del empleado, no sobre este objeto.
El Master-Detail implica borrado en cascada, así que eliminar un empleado elimina sus asignaciones. Un requerimiento que pida conservar el historial de entregas después de una baja hay que redactarlo teniendo eso presente, porque cambia el tipo de relación y no solo una configuración.
La asimetría entre los dos lados es deliberada y conviene no leerla como un descuido. El Lookup opcional hacia el activo permite registrar la entrega en el momento en que ocurre; el Master-Detail obligatorio hacia el empleado garantiza que ninguna entrega quede sin destinatario.
La marca de asignado sale de una fórmula que evalúa si la fecha de devolución está vacía, así que no existe un campo de estado que alguien pueda dejar desactualizado. Pedir un estado editable a mano sería reemplazar un cálculo confiable por un dato que depende de que nadie se olvide.
El campo Name es una numeración automática, o sea que ningún registro tiene un título legible. Cuando el requerimiento pide ver el par de persona y equipo en una Vista de lista, la vía es una fórmula de texto que concatene los dos nombres, o directamente el campo de fórmula que ya arma el nombre del activo.
Ventas, compras, inventario, finanzas y equipo, con la información al día y disponible desde cualquier dispositivo. Funciona en la nube, así que no hay servidores que mantener.
Quiero llevar mi Empresa a la Nube