Clases para gestión del Mantenimiento

Visión general

Base de ejemplo: test-tareas y test-movil

La gestión de mantenimiento en Ingrid consiste en la aplicación de herramientas para controlar trabajos y recopilar información sobre activos o bienes de inventario singulares identificados de forma única, de los que se quiere tener una trazabilidad en cuanto a las acciones realizadas sobre ellos para su mantenimiento preventivo, correctivo u otros.

Para ello, hay una serie de clases especializadas que trabajan contra esos bienes; aunque los Bins son una pieza indispensable en este sistema, su descripción se encuentra en la página de Control de Inventario.

A continuación, el resto de las clases que intervienen en este control para programación de tareas preventivas: las Operaciones (ope) que actúan como programadores de tareas, los grupos de trabajo (tra) y sus posibles componentes individuales: Personas (per) y Equipos (equ). Para entender bien para qué queremos estas clases y herramientas no olvide ver el tema Mantenimiento, tareas, en cuya introducción se describen las "patas" sobre las que se apoya este sistema y qué generan en definitiva. 

Operaciones

Nociones previas

Las operaciones son programadores que nos permiten generar tareas preventivas automáticamente con un patrón temporal y en algunos, casos, espacial.

Supongamos el caso de una inspección mensual a una familia concreta de equipamiento o bins: compresores.

La primera serie de tareas pendientes se crea al pulsar el botón de Chequea tareas de la operación, cuando tengamos los datos imprescindibles de definición de la operación:

  • Programación en el espacio > Bins a los que se aplica
  • Programación en el tiempo > Programación de frecuencias
  • Medidas o acciones a aplicar; casi imprescindible en el caso de las tareas preventivas generadas por una operación (programador)

Esas tareas (una por cada bin seleccionado) serán las únicas creadas realmente en BD. Al ejecutar una de esas tareas (contra un compresor) y cerrarla, se creará la siguiente para ese bin, según el esquema temporal de programación en el tiempo. Y así sucesivamente.

ATENCIÓN a que este chequeo, o preparación del preventivo en cada momento, bien para la operación actual o para toda la BD, pone en el preventivo los datos correctos por si una manipulación de un script nuestro, u otras incidencias en al BD han dejado algún dato incorrecto o incoherente: operación, bin, ámbito y resumen correctos, que no más de una tarea abierta a la vez para cada bin, que siempre exista al menos una tarea pendiente, etc.) y además se crean o eliminan las tareas que por modificación de inventario, o de programación de la operación, hay que crear o borrar.

Si queremos comprobar la corrección de los datos que el usuario modifica habitualmente en el plan preventivo (Grupo de trabajo y Fecha programada), que hayamos podido cambiar a mano en las tareas preventivas, para adecuaras a los datos previstos en las operaciones, tenemos que pulsar los botones de chequeo con CONTROL + clic. La fecha programada se chequea basándose en la fecha programada de la última tarea cerrada para cada bin, y en el patrón de Programación en el tiempo de la operación.

Programación en el espacio

Programar en el espacio es indicar en cada operación sobre QUÉ aplicamos el mantenimiento: los objetos y la agrupación de espacios en los que se encuentran.

Bins a los que se aplica, permite especificar una búsqueda Ingrid o find() de mongoDB, que especifique una lista de conceptos (no tiene por qué ser de clase de bin obligatoriamente), como por ejemplo: cla=panel rut=rut.B, es decir paneles con un campo ruta concreto, que puede ser la de inspección semestral, por ejemplo. La búsqueda mongoDB equivalente sería:  {find:{"cla":"panel","rut":"rut.B"}, sort:{"_id":1}}

Con esto se crea una tarea por cada bin de los seleccionados y se le aplican todas las Medidas (si ha alguna definida en la persiana Medidas).

Podemos ver especificación y ejemplos de sintaxis de búsqueda en: Anexo: Sintaxis de Búsquedas en mongoDB y reducidas

Subbins donde se toman las medidas, permite pasar la aplicación de las medidas en cada tarea, de los bins principales a los bins o conceptos "hijos" relacionados con esos bins principales mediante el campo especificado aquí. Se puede aplicar a varios niveles separador por barras verticales ( | ). El subcampo por defecto es le identificador _id, pero se podría poner otro. Los habituales son: recl.rec, desl._id, desl... También se puede poner el código de campo como el código de la clase superior, por ejemplo: espbar.espdis o espbar, siendo espbar espacios de clase Barrio y espdis espacios clase Distrito (su superior). 

En las bases de test indicadas al comienzo del tema, podemos ver el uso de estas combinaciones.

Espacios para agrupar los bins, sirve para indicar el código de campo (o más aún un campo indirecto como campo.campo) de los bins, que se usará para definir qué consideramos ESPACIOS la hora de agrupar y jerarquizar los bins (y por tanto sus tareas) en el calendario.

Programación en el tiempo

La primera consideración a tener en cuenta es que sábados y domingos no se tienen en cuenta cuando se considera una programación temporal (D)iara, en este caso nos referimos sólo a días de L-V. Además, no hay ningún calendario de festivos locales, nacionales, por convenios, etc.

La programación se hace como si todos los días fuesen laborables (con la periodicidad (T)odos, también se incluyen sábados y domingos), y cuando el trabajo cae en un día que realmente no se trabaja, se realizará al día siguiente o cuando se pueda. En ausencias largas como vacaciones, huelgas, etc. se pueden cambiar los grupos de trabajo para que sea otro el personal asignado.

Programación de frecuencias

Formato del campo: [Frecuencia] Periodo (SMADT) | Repetición (nº) | Estacionalidad

El Periodo es la unidad de tiempo entre cada repetición de la tarea (Semanal, Mensual, Anual), pudiendo utilizar también Diario (equivalente a S|L-V) y Todos (equivalente a S|L-D: semanal de lunes a domingo).

Si programo de forma semanal, puedo especificar qué día de la semana caerá siempre, si programo por meses o años, puedo especificar el nº de día (casi siempre: por ejemplo el día 31 de cada mes, algunos meses caerá el 1 del siguiente.

La Frecuencia (opcional) es el nº de Periodos entre cada ejecución (por defecto, 1).

Desde el punto de vista del tiempo, la Frecuencia DIVIDE, y la Repetición (los bloques en cada Periodo), MULTIPLICA.
Ejemplo:
S es una vez por semana (4 veces al mes)
2S es cada dos semanas
S|MJ es 2 veces a la semana.

Repeticiones: cada frecuencia admite un conjunto distinto:  T=S (los 7 días) | L-D,   D=S | L-V,   S:[LMXJVSD-],   M:dia ..., A:[día/]mes ...

Estacionalidad: [día/]mes(incluido) - [día/]mes(excluido)

 

Duración estimada, nos sirve en caso de querer controlar la diferencia entre duración estimada de los trabajos y su consumo de horas (duración real). En cada operación debemos indicar en horas la duración del trabajo POR CADA BIN, de forma que haciendo un complejo cálculo, la aplicación pone en cada preventivo creado, en el campo dur, la duración real acumulada que puede variar mucho en los casos más complejos. Por ejemplo:

  • Si es una tarea contra un sólo bin, la duración de ese trabajo.
  • Si es una ruta, la duración de todas las ejecuciones sobre todos los bins (cada ruta variará en la cantidad de elementos).
  • Si el bin tiene descomposición de mantenimiento (sub-bins) el tiempo de trabajo de esa operación ligada se acumula con la de los bins principales (uno o varios).
  • Si hay operaciones ligadas, en cada una tendremos la duración estimada por cada uno de sus bins y La operación principal creará las tareas con la acumulación de la duración de todas sus ligadas.

En el campo Repeticiones anuales, se muestra calculado el nº de tareas estimado que se crearán por año (en el caso de programación semanal o diaria, la estimación puede variar algún día en años bisiestos, por ejemplo).

Resumiendo el formato:

[Frecuencia] Periodo | Repeticiones | Estacionalidad
Frecuencia: número
Periodo: T(odos los días)  | D(ías laborables) | S(emana) | M(es) | A(ño)
Repeticiones: T=S|L-D, D=S|L-V, S:[LMMJVSD-], M:dia ..., A:[dia/]mes ...
Estacionalidad: [dia/]mes(incluido)-[dia/]mes(excluido)

 

Ejemplos de programación Programación Cant. anual
Cada mes

M 12
Cada 6 meses (divide el numero de veces, es decir, multiplica el tiempo transcurrido entre una ejecución y la siguiente)

6M 2
Cada 6 meses, el día 7 (mueve la Fecha programada al día MÁS CERCANO que cumpla la repetición)

6M|7 2
Cada 25 semanas. Casi equivalente a semestral
25S 2,09
Cada 10 días (laborables). Equivalente a 2S, pero la de días se debe evitar, porque se tarda más en calcular al evitar los fines de semana

2S 26,09
Con una estacionalidad complicada:
Cada mes, los días 15, 20 y 25, en el periodo del 1 de julio al 1 de octubre (último no incluido), y cada 2 meses el día 15, en el periodo del 1 de noviembre al 1 de febrero del año siguiente (último no incluido) y cada 2 meses los días 15 y 20 el resto de meses del año
M|15 20 25|7-10; 2M|15|11-2; 2M|15 20| 22,5

 

Para entender mejor la estructura de datos almacenada en cada tarea al generarse desde la programación de una operación, vea este cuadro

Prog. en el tiempo de la operación:
[Frecuencia] Periodo | Repeticiones | Estacionalidad ; ...  > {fre,per,repl,ini,fin}

per: Periodo T D S M A
fre: Frecuencia - - número número número (los indicadores de periodo D y T no soportan frecuencia
repl: Repeticiones =S|L-D =S|L-V [LMXJVSD-] dia ... [dia/]mes ...
ini: Estacionalidad [dia/]mes(inclusive)-[dia/]mes(exclusive)
fin: Idem
tarant, tarsig:campos de enlace a las que la rodean

Medidas, definición

La lista de Medidas definen las acciones a realizar en el trabajo de la operación actual. Estas medidas pueden ser la realización de una acción como: "Inspeccionar estado del cuadro" que en las tareas se marcará con un valor "Bien " / "Mal", o bien "Sí" / "No", o cualquiera que convenga, o también se puede recoger una medida de un contador (tensión, impedancia, horas de trabajo, calorías, kms. recorridos...)

En la lista se definen con un código cualquiera (no son conceptos), y un rango de valores en el campo Opciones. ATENCIÓN a que los códigos no se pueden repetir en la misma operación, ya que sería la misma medida, aunque en dos líneas tuviera distintos la descripción, tipo, rango...

si son del tipo Selección, por ejemplo, o bien en los campos Mínimo-Defecto-Máximo si son numéricos. Los valores permitidos son casi todos los tipos de campos de Ingrid. Puede ver ejemplos de definición en la base test-tareas.

El campo Requerida marcado en una Medida, obliga a rellenarla en todas las Tareas, sino no se puede cerrar.

Los campos Mínimo y Máximo definen el rango fuera del cual los valores tomados generan una marca en el campo Incidencia de esa medida en la Tarea.

En los campos de tipo selección, los valores de la lista a partir del máximo (incluido) serían incorrectos y anteriores al indicado en el mínimo (incluido) también.

En campos con valor numérico incorrecto serían, naturalmente, los valores que superen el máximo indicado o no lleguen al mínimo.

Programación en el espacio

1. Ordenar la secuencia de tareas que vamos a realizar cada día

En las páginas de una operación, nuestro grupo de trabajo, un espacio o un bin, se puede ver el panel con las órdenes y tareas pendientes (el panel de órdenes es la agrupación de todas las que tenemos en la misma fecha, para el mismo grupo de trabajo y agrupadas en el mismo espacio, y en él podemos editar en conjunto la fecha de programación y el grupo de trabajo asignado).

El orden de las tareas de esta lista es importante, porque nos muestra primero todo lo pendiente que tenemos atrasado (anterior a Fecha programada de hoy) y en un orden determinado todas las que tenemos para hoy y para los próximos días.

Este orden, por defecto es agrupando por:   Fecha Programada - Espacio - Bin - Operación. Como ejemplo, si tuviéramos esta lista de tareas:

01    3/5/22    Planta -1, bombas             Bomba 11   Revisión semestral
02   11/5/22    Planta -1, bombas             Bomba 1     Revisión semestral
03   11/5/22    Planta -1, bombas             Bomba 1    Revisión anual
04   11/5/22    Planta -1, bombas             Bomba 2    Revisión semestral
05   11/5/22    Planta -1, bombas             Bomba 2    Revisión anual
06   11/5/22    Planta -1, bombas             Bomba 3    Inspección mensual
07   11/5/22    Planta -2, electrógenos       Grupo 1    Revisión semestral
08   11/5/22    Planta -2, electrógenos       Grupo 2    Revisión semestral
09   11/5/22    Planta -2, electrógenos       Grupo 3    Revisión semestral
10   12/5/22    Planta -1, bombas             Bomba 7    Revisión semestral
11   12/5/22    Planta -1, bombas             Bomba 8    Revisión semestral

donde la primera sería una tarea que nos quedó pendiente hace una semana. La 2ª y 3ª provienen de dos operaciones ligadas que se realizan sobre los bin Bomba a la vez siempre en la misma fecha: cuando nos acercamos a un bin, una revisión semestral y otra anual. La 4ª tarea ya se refiere a otro bin distinto del mismo espacio (planta 1).

Hay que destacar que este orden de trabajos puede ser automático, facilitando crear nuestro plan de mantenimiento: primero la ordenación por fechas nos agrupa el trabajo de todo el día y el de espacios, en principio es el primer campo de referencia a un concepto de clase Espacio que tanga cualquier otro concepto de BD (los bins pueden ser de decenas de clases, por ejemplo). Es decir, sin especificar nada, me agrupa lo que hay en la misma sala o zona y dentro de ella, todas las operaciones o sub-bins de un bin.

 

2. Distribuir la carga de trabajo

Por otro lado, tenemos una herramienta para realizar una distribución automática a partir de una fecha y un patrón. Por ejemplo, al crear una operación semestral de revisión de cuadros eléctricos, sobre 20 cuadros, si pulsamos Chequea tareas de la operación, se crearán 20 tareas con la fecha de hoy.

Si queremos planificar el mantenimiento a partir del día 15 del mes que viene, y queremos realizar 3 tareas diarias, iremos a la lista de Tareas pendientes, que es donde podemos modificar en columna las Fechas programadas de la próxima ejecución en todos los bins de la operación.

- Multi-seleccionamos las líneas que queremos distribuir (inicialmente están todas le mismo día), o con el menú contextual de cabecera, seleccionamos todas.

- En menú contextual > Cambia fecha programadas de la selección, y en el diálogo pondremos:  "15/3/17 D 3"

OJO! esta distribución no tiene en cuenta en estacionalidad e la programación en el tiempo, sólo es una herramienta para copiar fechas con un patrón, sin más condiciones. Por ejemplo, si en nuestra programación en el tiempo tenemos "que se realice mensualmente excepto en enero, agosto y diciembre", y nuestro patrón de distribución cae en esos meses, tendremos que ajustarlo por bloques manualmente.

Formas de programar operaciones

Hay tres formas de usar las operaciones para que se generen tareas preventivas, dependiendo del objeto contra el que se dirige este programador:

1. Programación simple contra un bin.

Creando una operación, poniendo en el campo Clase de objetos a los que se aplica, una clase o búsqueda de bins, y en PProgramación de frecuencias un patrón (semanal, mensual, semestral o cualquiera complejo). Los demás campos son opcionales: Grupo de trabajo, Duración, Descripción, Medidas -aunque debería tener-. Se crea una tarea por cada bin, inicialmente todas con la Fecha programada, la de hoy y en cada una se presentan las Medidas de la operación.

 

2. Programación contra un concepto de clase ruta, que incluye una lista de bins ordenados.

Se crea un concepto de clase 'rut' y en su lista de Componentes de la ruta se incluyen los deseados, en el orden preferido de recorrido. En la operación, la clase sobre la que se a aplica son las rutas o una selección de ellas o una única. Se crean tantas tareas como rutas y en cada una, las medidas se presentan para cada bin de cada ruta

 

3. Tarea de varias operaciones Ligadas: Programación contra un bin que se descompone en sub-bins.

Primero, se crea la operación principal, dirigiendo Bins a los que se aplica,  a los bins principales, por ejemplo: seguidor fotovoltaico.

Luego, en una o varias operaciones ligadas a esa (a través del campo Esta operación está ligada a), y sin especificar nada en el campo Bins a los que se aplica, se pueden detallar los Subbins donde se toman las medidas, relacionados con cada bin de la operación principal. Por ejemplo: inversores que en su campo 'seg' tienen el seguidor al que pertenecen (o sea, inv.seg), módulos fotovoltaicos que apuntan al seguidor con el campo mod.seg, etc.

Con esto se crea una sola tarea para cada bin principal, y en ella están lasmedidas de cada operación ligada aplicadas a todos los componentes del seguidor, además de las medidas de la operación principal, contra el bin principal (seguidor), claro.

OJO! Las operaciones ligadas sólo pueden tener EL MISMO patrón de programación temporal que la principal, por eso este campo no es editable. Si lo que se quiere es una operación que esté RELACIONADA O ASOCIADA en el tiempo a otra como múltiplo de su programación (por ejemplo las inspecciones anuales sobre las semestrales para cada bin), no hay ningún dato que las ligue realmente: creamos 2 operaciones independientes que comiencen el mismo día con un patrón diario o mensual compatible para que vayan coincidiendo en el tiempo.

Otras aplicaciones de estas herramientas

Puede haber casos más complejos, que se gestionan con estas tres formas de manejar la operaciones:

Problema a resolver: tenemos unas zonas áreas infantiles que son bienes de inventario y se componen de otros bins: equipamiento o mobiliario de juegos infantiles, y queremos aplicar una operación, con sus medidas al equipamiento, pero realizando la inspección por una lista ordenada de zonas en una ruta.

Solución: Simulamos el orden de rutas creando un campo de posición en las áreas infantiles, y ordenando en el campo Clase de objetos a los que se le aplica de la Operación, por ese campo posición. Así nos saldrá el trabajo ordenado por ese "orden de ruta". Las operaciones se aplicarán directamente a zonas y mediante una operación ligada, a sus sub-bins.

Resumen de condiciones

- Todas las tareas generadas por las operaciones van siempre contra un bin, aunque el generador (operación) puede tener diversos elementos en el campo Clase de objetos a los que se aplica.

- La definición de Medidas de una operación no se puede modificar nunca, una vez usadas en alguna tarea. Ni el código, descripción, rango de valores... tampoco añadir nuevas medidas o eliminar alguna (el orden de las líneas sí podría cambiarse). Todas las tareas se refieren a cada medida sólo por el código, y si se modifica la definición, las tareas cerradas tendrán datos falsos.

Persiana Consumos

Se muestra cuando en la definición de la tarea, bajo al sección de Programación en el tiempo, tenemos marcados los conmutadores de Consumos Equipos y/o Recursos, para poder especificar una plantilla de los que puede requerir cada ejecución de una tarea sobre uno de los bins.

Bajo esta persiana se tienen otras dos listas para poner ambas clases de recursos SIN la cantidad, la estimación de personal proviene de los recursos de clase Persona, asociados al grupo de trabajo mediante al campo Grupo de trabajo (en caso de que lo tenga, claro).

En caso de estar marcada la casilla Defecto, además, en cada tarea pendiente que se cree, se ponen los recursos de las clases marcadas para considerar en la operación. Esta plantilla, facilita el introducir sólo la cantidad en cada tarea, y no tener que poner los recursos en cada una. En caso de que sobren, se puede eliminar la línea, claro.

Botones de herramientas

Siguientes programaciones, nos da una lista de fechas en las que se va a ejecutar según el patrón de Programación en el tiempo, de esta forma podemos comprobar que se ajusta a lo deseado.

Bins en niveles, muestra un estructura en árbol por niveles si tenemos definidos subbins, rutas, etc., con los códigos de todos los bins a los que se va a aplicar (por tanto una tarea para cada uno excepto en el caso de rutas).

Espacios, lo mismo que el anterior, pero con los espacios relacionados según la programación en el espacio, indica el nº de tareas que se van a crear y los espacios que se van a considerar.

Duraciones, recopilación de duraciones estimadas por cada tareas, esto incluye un calculo acumulado en las que tienen ligadas o con subbins o de ruta, en las cuales se acumulan los campos Duración.

Medidas, da el desglose de todos los datos de medidas definidas para chequear las de cada bin, esto es más útil en las que tiene subbins y muestran las medidas de otras operaciones/tareas.

Chequea tareas de la operación, es imprescindible ejecutar la cuando hemos modificado algún parámetro de la programación, para que las tareas existentes se adapten a ella, puede ser creando nuevas tareas, cambiando las fechas por el patrón temporal o eliminando sobrantes. Además, se comprueba que la última tarea de una serie de ejecuciones esté abierta (sino, la abre), que todas las anteriores estén cerradas, que los códigos de tareas coincidan con la operación y bin (si se han recodificado). Pulsando el botón con la tecla Control, se resetea la Fecha programada a la actual (luego se puede desplazar con las herramientas de Calendario), y el grupo de trabajo al de la operación.

En el chequeo se comprueba que la operación esté activa, es decir, que al menos tenga Bins a los que se aplica y Programación de frecuencias, si falta alguno de los dos datos, se muestra un diálogo de error que impide corregir y generar tareas (no así con el siguiente botón que es para TODAS las operaciones). RECUERDE que para desprogramar una operación que ya tiene tareas generadas, basta con poner en bins a los que se aplica, una búsqueda que no devuelva bins (de cla=bin por ejemplo, a cla=bin cod="xxx") o reducir los que queremos aplicar (cla=bin cod>"B76").

 

El chequeo de tareas sigue este algoritmo:

- Si se está chequeando una tarea ligada, no se hace nada (las ligadas no tiene programación, la tiene su principal)

- Si no existe frecuencia (programación en el tiempo) o no hay bins sobre los que aplicar, se da un error y no se hace nada

- Si la programación no ofrece una fecha programada, se da error

- Se calcula la duración de las tareas, se leen todos los espacios y bins

- Se seleccionan sólo tareas preventivas de la operación actual, ordenadas primero por bin y luego por fecpro (fecha programada)

- Comprobación de tareas:
· de la lista ordenada, se va comparando cada tarea con la anterior, si la anterior no tiene fecha de cierre, se pone la fecha actual
· si no tiene bin y no tiene fecha de cierre, se elimina
· en el recorrido se almacena al última tarea de cada bin

- Comprobación de bins:
· para cada serie de tareas de cada bin, si no tiene última tarea, se crea la primera 'tarpre.'+bin._id+'.'+ope._id+'.0001' y se rellenan sus campos con los de la operación
· sino, si la última tarea de la serie del bin está cerrada, crea la tarea siguiente (la abierta que debe existir) con los datos de la tarea anterior y la operación
· en caso de haber pulsado con opción de resetear, se reescriben la fecha programada y grupo de trabajo con datos de la operación

 

Chequea tareas de TODAS, realiza el mismo chequeo que el botón anterior, pero sobre TODAS las operaciones de la BD. ATENCIÓN a que sólo se realiza sobre las operaciones con una programación activa, es decir, se realiza la búsqueda:  cla==ope ope! clabin!! profre!! , o sea, operaciones principales (que no son ligadas por el campo ope), y que tienen programación de frecuencia y bins a los que se aplica. ATENCIÓN a que si se pulsa el botón con CONTROL, se resetean las Fechas programadas y Grupos de Trabajo aunque SÓLO de las tareas pendientes.

Persiana Tareas y Calendario

Tiene los controles para la realización del trabajo mediante tareas y para su planificación. Véalo en el tema Calendario.

Grupos de Trabajo

Son el nexo de unión de los conceptos de tipo Persona, que intervienen en las Tareas para especificar los consumos de recursos horarios, y a la vez, en el campo Grupo de trabajo de la Tarea, permiten que el jefe de mantenimiento asigne el trabajo tanto en preventivas como en correctivas.

IMPORTANTE: Cada grupo de trabajo sólo tiene acceso a sus propias tareas, por lo que el usuario que hace login en la base tiene que tener en la tabla de definición de usuarios el grupo de trabajo al que pertenece, en el campo gTRA. Para ver las condiciones en que las tareas se pueden completar según el grupo, vea la página de Tareas.

Administrador

La clase tiene unos campos particulares busbin, busrec, busope que sólo se utilizan para Ingrid con movilidad offline.

Persiana Tareas de... Clase

El control para planificación y realización del trabajo mediante tareas. Véalo en el tema Calendario.

Persiana referencias

Muestra la relaciones, habitualmente con las Personas que componen el grupo (y tienen el campo Grupo de trabajo apuntando al que vemos), y con las Tareas correctivas en las que interviene el grupo. Puede haber más subpersianas de relaciones.

Personas

Representa cada trabajador individual (con nombre y apellidos, no la categoría profesional), relacionado en la base como un recurso de consumo de horas particular, que puede intervenir como consumos de recursos horarios en las Tareas.

Tienen un campo que apunta al Grupo de trabajo al que pertenece (sólo se soporta la pertenencia a uno durante toda la jornada, en cada momento) y que permite opcionalmente que las Tareas asignadas a su grupo de trabajo, puedan rellenar de forma automática la tabla de consumos con las personas de su grupo, teniendo que poner sólo la cantidad real consumida.

Equipos

Representa cada elemento de maquinaria particular (con matrícula, marca y modelo, no la clase de maquinaria), relacionado en la base como un recurso de consumo de horas, kms... particular, que puede intervenir como consumos de recursos de las Tareas. Tienen un campo que apunta a la especialidad, lo que permite agrupar el inventario de maquinaria por categorías utilizables para el mismo propósito.

En las Tareas no está explícitamente gestionada la lista de equipos, y por tanto no hay ninguna funcionalidad que haga que asignándole un Grupo de trabajo, haga que al entrar en una tarea asignada a ese grupo, se rellenen los equipos del grupo, por ejemplo (para tener que completar sólo el consumo), pero esta personalización se puede implementar con eventos en la clase Tarea.