Quito, 20 de diciembre de 2014 Gestión Soporte y Logística Control de Flota Versión 1.0
Quito, 20 de diciembre de 2014
Gestión Soporte y Logística
Control de Flota
Versión 1.0
Tabla de Contenidos Módulo: Control de flota 1
R1 – Gestionar vehículo 3 R2- Actualizar registro de combustible. 6 R3- Actualizar registro de kilómetros recorridos del vehículo. 6 R4- Gestionar solicitud de reparaciones 7 R5- Gestionar acciones de mantenimiento 8 R6- Mostrar historial de mantenimiento. 9 R7- Gestionar demandas de movilizaciones. 9 R8- Gestionar planificación de movilizaciones. 11 R9- Actualizar movilizaciones. 13 R10- Historial de movilizaciones. 13
R11- Gestionar incidencias 13
1 de 16
Listado de requisitos generales
R1 – Gestionar vehículo
Descripción
El sistema debe permitir gestionar vehículos. Un vehículo debe tener los
siguientes campos:
• Modelo: Modelo del vehículo, el cual debe incluir información de la marca
del mismo.
◦ Nombre del modelo
◦ Marca: Marca del vehículo. Se incluye un ícono del logo de la marca
en el formulario.
◦ Vendedores: Información sobre los vendedores del vehículo.
• Placa: Número de placa del vehículo. Solo se debe permitir introducir
letras y números hasta 7 caracteres.
• Etiquetas:
• ¿Es contratado?: Este campo determina si el vehículo forma parte de los
AFT de la universidad o es un vehículo contratado a un proveedor.
• Conductor: Conductor del vehículo, que podría no ser un empleado de la
universidad.
• Ubicación: Área o dependencia.
• Número de chasis: Número del chasis del vehículo.
• Número de motor: Número de motor del vehículo.
• Último registro Km recorridos: Cantidad de kilómetros recorridos en su
último viaje.
• Fecha de adquisición: Fecha en que se compró el vehículo.
• Valor del coche: Cuánto costó el vehículo.
2 de 16
• Frecuencia de mantenimiento: Se especificará cada cuántos kilómetros
recorridos será requerido enviar el vehículo a mantenimiento.
Propiedades adicionales
• Nº de puertas: Cantidad de puertas del vehículo.
• Nº de asientos: Cantidad de asientos del vehículo disponibles para
transporte de personal.
• Color: Color del vehículo.
Opciones del motor
• Transmisión
◦ Manual
◦ Automático
• Tipo de combustible: Debe ser un nomenclador, de momento los tipos
con que se trabaja son los siguientes (podrían variar en el futuro):
◦ Gasolina
◦ Diesel
◦ Eléctrico
◦ Híbrido
• Emisiones de CO2: Emisiones de CO2 por cada litro de combustible
consumido en Kg.
Debe permitir acceso a información sobre los Registros de combustible y
Registros de kilómetros recorridos asociados al vehículo.
El sistema debe mostrar alertas sobre los vehículos que deban entrar a
mantenimiento (cambio de aceite) con una diferencia de 500 kilómetros.
Hay dos formas de adicionar un vehículo a la flota de la universidad: a través
de una compra o contratándolo a un proveedor.
3 de 16
• Si el vehículo entra a la flota a través de una compra, se debe crear el
producto con los datos obligatorios del vehículo y en el momento de
confirmar un producto entrante al inventario, se creará de forma
automática el vehículo en estado borrador, el usuario podrá modificar los
campos del vehículo antes de pasarlo a estado Disponible donde sus
campos ya no serán editables. Al pasarlo a estado Disponible, se creará
automáticamente un Activo Fijo. En este caso, se le registrarán algunos
campos por defecto desde la ficha del vehículo, como:
◦ Categoría: A qué categoría pertenece en AFT.
◦ Nombre: Nombre del activo que será el nombre del vehículo.
◦ Categoría: A qué categoría pertenece en AFT el vehículo.
◦ Responsable del activo: Conductor asignado al vehículo.
◦ Fecha de compra: Fecha de adquisición del vehículo.
• Si el vehículo es contratado, se registrará a través del área de flota
haciendo uso del menú Flota / Vehículo. No se resgitrará como Activo
Fijo de la Universidad.
Estados (**)
◦ Disponible: Al crear el vehículo el mismo se encuentra en este estado.
Lo mismo sucede si ha sido contratado, al contratarlo pasa a estado
“Disponible”. Cada vez que el mismo sea liberado de una
movilización, o sea, cuando termine una movilización, el vehículo que
se utilizó en ella pasará a estado “Disponible”. De igual manera al
salir del taller donde se le realicen acciones de mantenimiento, pasará
a estado “Disponible”.
◦ Movilizado: Se encuentra asignado a una movilización.
◦ En mantenimiento: Se encuentra en el taller, pues se le están
realizando acciones de mantenimiento.
4 de 16
◦ Devuelto: Solo para vehículos contratados. Para el caso en que el
vehículo se entregó al proveedor. La ficha del vehículo tendrá un
botón “Devolver” que permita pasar el vehículo a este estado.
Vistas
• Kanban
• Lista
• Formulario
Filtros
• Estado
• Matrícula
Agrupaciones
• Estados
• Marca
R2- Actualizar registro de combustible.
Descripción
El sistema debe permitir mostrar el registro de combustible del vehículo, del
mismo se recogerán los siguientes campos:
• Vehículo: Vehículo al cual se le realiza el abastecimiento de combustible.
• Galones: Cantidad de combustible en galones.
• Precio por galón: Precio por cada galón de combustible.
• Precio total: Campo autocalculado (Galones*PrecioPorGalón)
• Último registro km recorridos: Último registro de kilómetros recorridos.
• Fecha: Fecha del abastecimiento.
• Comprador: Debe registrarse del nombre del chofer del vehículo, si el
mismo ha sido especificado en la ficha del vehículo.
5 de 16
• Referencia factura: Sobre la factura emitida al adquirir el combustible.
• Proveedor: Proveedor de combustible.
• Notas: Cualquier información adicional sobre el reabastecimiento.
En la ficha del vehículo debe mostrarse un botón que se llame Registros de
combustible que nos permita en cualquier momento actualizar el registro de
combustible del vehículo.
También será posible acceder al registro de combustible de todos los vehículos
de la flota de la Universidad a través de una entrada de menú,
R3- Actualizar registro de kilómetros recorridos del vehículo.
Descripción
El sistema debe permitir mostrar el registro de kilómetros recorridos del
vehículo. Se deben registrar los siguientes campos:
• Fecha: Fecha en que se actualiza el registro.
• Vehículo: Vehículo al cual se le actualiza el registro.
• Valor (Km recorridos): Cantidad de kilómetros recoridos que marca el
vehículo.
• Unidad: Unidad de distancia.
El sistema deberá validar que no se permita registrar un valor menor al último
registrado.
En la ficha del vehículo debe mostrarse un botón que se llame Registros de
kilómetros recorridos que permita en cualquier momento actualizar el
registro de kilómetros recorridos del vehículo.
•
6 de 16
R4- Gestionar solicitud de reparaciones
El sistema debe permitir gestionar solicitudes de reparación. Unasolicitud de
reparación debe tener los siguientes campos:
◦ Código: Autogenerado por el sistema.
◦ Autor de la solicitud: Empleado que realiza la solicitud.
◦ Dependencia: Dependencia que realiza la solicitud.
◦ Fecha de emisión: Fecha de emisión
◦ Vehículo: Vehículo para el cual se emite, solo se deben mostrar
aquellos vehículos que se encuentren en estado “Disponible”.
◦ Descripción: Descripción de la solicitud de acción de mantenimiento.
Una vez que sea Aprobada, esta solicitud debe permitir Impresión, pues será la
orden de mantenimiento con que entre al taller.
Vistas
• Listado
• Formulario
Agrupaciones
• Estados
• Vehículos
• Autor
Estados
• Borrador: Al crearla, permite edición.
• Confirmada: Al presionar el botón “Confirmar solicitud”. No puede ser
editada por la dependencia.
• Aprobada: Al presionar el botón “Aprobar solicitud”. Aprobada por el
Director del Departamento de flota.
• Rechazada: Al presionar el botón “Rechazar solicitud”. Rechazada por
el Director del Departamento de flota.
7 de 16
• Atendida: Al registrar la correspondiente acción de mantenimiento.
R5- Gestionar acciones de mantenimiento
Descripción
El sistema debe permitir gestionar acciones de mantenimiento. Una acción de
mantenimiento posee los siguientes campos:
• Tipo de mantenimiento:
◦ Correctivo
◦ Preventivo
• Costo: Monto en USD que costó el mantenimiento. Este campo debe ser
requerido para poder sacar de mantenimiento un vehículo, se debe
validar que se especifique antes de dar por terminado el mantenimiento.
• Acción efectuada:
▪ Si el tipo de mantenimiento es correctivo se registran Arreglos:
• Código: Autogenerado.
• Descripción: Descripción.
▪ Si el tipo de mantenimiento es preventivo se registran Acciones
preventivas:
• Código: Autogenerado.
• Descripción: Descripción.
• Rango de fecha: Tiempo que estará el vehículo en el taller.
◦ Fecha entrada: Fecha de entrada al taller, requerido al registrar la
acción.
◦ Fecha salida: Fecha de salida del taller, se debe especificar al darle de
baja del taller.
• Solicitud de reparación: Solicitud requerida para iniciar la acción de
mantenimiento.
8 de 16
Debe mostrarse un botón “Terminar mantenimiento”, que permita pasar el
vehículo a estado “Disponible”. En este botón se valida que se haya introducido
una fecha de fin de mantenimiento y un costo por las acciones de
mantenimiento realizadas.
Vistas
• Lista
• Formulario
R6- Mostrar historial de mantenimiento.
Descripción
El sistema debe permitir, a través de un asistente, mostrar el historial de
mantenimiento. El historial de mantenimiento no es más que el listado de
todas las acciones de mantenimiento a la que ha sido somentido el vehículo.
• Cada vehículo tendrá un historial de mantenimiento. El historial de
mantenimiento se mostrará al usuario sólo con fines informativos. Esta
información no será editable.
R7- Gestionar demandas de movilizaciones.
Descripción
El sistema debe permitir gestionar demandas de movilizaciones. Cada
dependencia (área o facultad) emitirá demandas de movilizaciones. Una
demanda de movilización tiene lugar cuando la dependencia tiene la necesidad
de realizar un viaje para lo cual requiere de un vehículo.
Una demanda de movilización debe tener:
• Dependencia: Dependencia que la solicita.
9 de 16
• Responsable: Persona que hace la demanda, debe ser un empleado de la
universidad.
• Fecha solicitud: Fecha de solicitud
• Cantidad personas: Cuántas personas viajarán
• Actividad: Actividad para la cual se solicita una movilización, esta
información la utilizará el Departamento de flota para determinar el tipo
de vehículo que proveerá para la movilización.
• Ruta: Lugar al que desea ir o lugares por los que desea pasar.
• Código de la planificación asociada: Este campo toma valor cuando se le
asocian las demandas a una planificación.
Datos de la movilización
• Fecha movilización: Fecha para la que está pidiendo la movilización
• Fecha regreso: Fecha de regreso de la movilización
• Hora salida: Hora de salida de la movilización
• Hora regreso: Hora de regreso de la movilización
Estado (**)
• Borrador: Cuando se realiza la demanda en el área. Se puede modificar.
• Confirmada: Cuando el usuario presiona el botón “Confirmar
demanda”, en cuyo caso la demanda estaría lista para que el jefe de
flota la revise y no podrá ser editada desde el área o dependencia que la
genera.
• Planificada: Cuando se le asocia a una solicitud de movilización (de
forma automática).
• Efectuada: Cuando se ejecuta la movilización. Pasa a ese estado al
mismo tiempo que la solicitud de movilización a la que se asocia la
demanda.
10 de 16
Vistas
• Lista
• Formulario
• Calendario
Filtros
• Estado
• Fecha de movilización
• Dependencia
• Responsable
Agrupaciones
• Estado
Puede existir más de una demanda asociada a una planificación de
movilización.
R8- Gestionar planificación de movilizaciones.
Descripción
El sistema debe permitir gestionar planificación de movilizaciones a partir del
listado de las demandas de movilizaciones previamente Aprobadas.
Una solicitud de movilización debe tener:
• Código: Código de la solicitud, autogenerado.
• Dependencias: Dependencias a satisfacer.
• Fecha salida: Fecha de salida de la movilización.
• Fecha llegada: Fecha de llegada de la movilización.
• Hora de salida
11 de 16
• Hora de llegada
• Ruta: Lugar al que desea ir o lugares por los que desea pasar. Este
campo es requerido.
• Demandas: Demanda o demandas de movilización por las cuales se
realiza esta planificación. Al asociar la o las demandas a esta
planificación, en el campo Código de la planificación asociada que
contiene la demanda, se agrega el código de esta planificación, para que
las áreas puedan ver en qué planificación quedó reflejada su demanda.
Las demandas se podrán seleccionar de un listado donde se muestren
aquellas que se encuentren en estado “Confirmadas” y que además
coincidan en al menos un punto con la ruta especificada en el campo
Ruta, con la intención de que no se planifiquen demandas cuya ruta no
coincida con la planificada. (Si no se especifica una Ruta, el campo
Demandas permanecerá vacío)
• Vehículos: Vehículos que la efectuarán (Si un solo vehículo no fuera
suficiente para transportar a todas las personas que viajarán, el sistema
debe permitir asignar varios vehículos a la movilización).
• Personas a transportar: Listado de las personas que viajarán. Estas
personas deben haber sido ingresadas al sistema previamente en el
área de RRHH, sin embargo es posible planificar una movilización sin
haber especificado quiénes viajarán (El campo no es requerido).
Estados (**)
• Borrador: Cuando se crea la solicitud, esta se encuentra en estado
borrador y puede ser modificada.
• Planificada: Cuando el usuario presiona el botón “Planificar
movilización”, luego de asociarle una demanda de movilización en
cuyo caso no podrá ser editada. (Esta acción pasará al estado
12 de 16
“Planificada” a las demandas asociadas de forma automática). Al
presionar este botón el sistema validará que la cantidad de asientos
disponibles entre los vehículos seleccionados no sea menor que la
cantidad de asientos requeridos en las demandas, y también validará
que la cantidad de personas seleccionadas (si se especifica quiénes
viajarán) no sea mayor que la cantidad de asientos disponibles en los
vehículos. Al planificar la movilización, los vehículos asignados a esta
permanecerán en estado “Movilizado” hasta que termine la misma.
• Efectuada: Cuando se ejecuta la movilización. Al mismo tiempo que la
movilización pasa a este estado, pasarán a estado “Efectuada” todas las
demandas asociadas a ella. Así como deben pasar a Disponibles los
vehículos que estaban asignados a esa movilización.
Filtros
• Mis movilizaciones: Muestra sólo aquellas movilizaciones en que participó
como pasajero el usuario.
• Planificadas: Muestra sólo aquellas movilizaciones en estado
“Planificada”.
• Ejecutadas: Muestra sólo aquellas movilizaciones en estado “Ejecutada”.
Agrupaciones
• Estados
• Fecha de inicio
Vistas
• Lista
• Formulario
• Calendario
13 de 16
A partir del listado de demandas de movilizaciones registradas, se deben crear
las planificaciones de movilizaciones, sólo se mostrarán aquellas demandas en
estado “Confirmada”.
En el rango de tiempo que dure la movilización, el vehículo seleccionado debe
estar en estado “Movilizado.”
Un vehículo que esté en estado “Movilizado” no podrá ser seleccionado para
otra movilización.
Esta funcionalidad será accesible sólo para el Responsable del Departamento
de Flota de la Universidad.
El sistema debe permitir imprimir la planificación de movilización.
R9- Actualizar movilizaciones.
Descripción
Esta actualización se realiza luego de que tenga lugar la movilización.
• La solicitud de movilización y las demandas asociadas pasan a estado
“Efectuada”.
• A partir de esa acción se podrán consultar todos los datos de la solicitud,
pero esta información no será editable.
• El vehículo que efectuó la movilización pasa a estado Disponible.
R10- Historial de movilizaciones.
Descripción
El sistema debe permitir mostrar el historial de movilizaciones. En la ficha de la
planificación de movilizaciones se incluirá un filtro que permita ver las
movilizaciones en las que ha estado involucrado el vehículo.
14 de 16
R11- Gestionar incidencias
Descripción
El sistema debe permitir gestionar incidencias. Una incidencia posee los
siguientes campos:
• Código: Autogenerado.
• Fecha: Fecha en la que se emite.
• Responsable: Nombre de quien la emite, el cual debe ser un empleado
de la universidad.
• Descripción: Descripción de la incidencia. Este campo debe ser
requerido.
• Vehículo: Vehículo al que se le registra la incidencia.
Vistas
• Lista
• Formulario
Agrupaciones
• Vehículo
• Fecha de incidencia
• Responsable
Notas
** El sistema no debe permitir editar los estados de cada concepto. Los mismos deben ser
estáticos predefinidos por el sistema, pues tienen reglas de negocio asociadas a ellos.
15 de 16