Clase Tareas para Mantenimiento

Introducción

Con los objetos de mantenimiento se persigue controlar con distintos grados de intensidad, según necesitemos, la gestión de trabajos preventivos (programado) y/o correctivos (manual) sobre los activos de inventario deseados.

Las Tareas de ambas clases, excepto en casos especiales más complejos, representan la información documental de un trabajo a realizar sobre un bien de inventario (bin) en una fecha concreta. Tiene la información de QUÉ tipo de trabajo se realiza (operación) en el caso de tareas preventivas, y una descripción en el caso de la correctivas, SOBRE QUÉ OBJETO se realiza (bin), y CUÁNDO (Fecha programada).

Casi siempre es imprescindible asignar QUIÉN la realiza (grupo de trabajo) y en el caso de las preventivas, el detalle dentro del trabajo a realizar, de QUÉ labores o medidas concretas hay que tomar (que provienen de la operación) y se reflejan en una lista de Medidas cuyos valores hay que completar al realizar el trabajo.

Bases de ejemplo: test-tareas y demo-fotovoltaico.

Restricciones

Con el login de usuario en la aplicación nos validamos con un usuario de la clase Usuarios de BD que tenga ese código (cod de usuario=usu.cod y contraseña=usu.pwd. Con esto, tenemos el grupo de trabajo del usuario (usu.tra) y su carpeta raíz de datos al navegar por la BD (usu.raiz). Si está definido el grupo, al hacer cualquier búsqueda de tareas (de cualquier clase) se nos presentan sólo las que tengan tar.tra=usu.tra o bien las que no tengan definido grupo.

Además, en cada tarea, y al margen del filtro por usuario, sólo podremos poner en las Persianas de consumos de personas y equipos (tar*.perl y tar*.equl) los que pertenezcan al grupo de trabajo (si la tarea tiene) o los que no estén asignados a ningún grupo. Recuerde que la relación con el grupo se establece en el grupo (tra.perl).

ATENCIÓN a que si el usuarios tiene permisos de edición sobre los conceptos de consumo (Personas, etc), al introducir una máscara como 'carlos', lo entenderá para buscar por Código y si no existe, preguntará para crearlo, pero si no tiene permisos, lo buscará por Resumen y si no coincide con ningún concepto sólo dará un aviso.

Administradores: Gestión de campos

Consideremos una ventana de campos como la de tareas correctivas (tarcor), en la que hay 3 persianas de datos: los campos base generales como código, resumen (de clase CON), los comunes de tareas (TAR) si hay, y los particulares de las correctivas (TARCOR), para personalizar los que van a aparecer y sus premisos tenemos 3 posibilidades:

Todas ellas en modo admin, y con un usuario con permisos de administrador, claro:

1. Ocultar los campos de algún panel, si por ejemplo queremos introducir el texto en un campo particular de la clase en vez de el genérico res o tex. Ocultamos

2. Usar al función de unir todos los paneles (en persiana clase: tareas correctivas > Campos > Presentación, ), para poder gestionarlos todos juntos con los campos traza.

Tareas Preventivas (programadas)

Excepto en casos complejos especiales, representan la información documental de un trabajo a realizar sobre un bien de inventario (bin) en una fecha concreta. Tiene la información de QUÉ trabajo se realiza (operación), SOBRE QUÉ objeto o bien se realiza (bin), QUIÉN la realiza (grupo de trabajo) y CUÁNDO (Fecha programada). El detalle de QUÉ labores concretas hay que realizar o qué medidas hay que anotar, provienen de la operación y se reflejan en un panel llamado Medidas que hay que completar al realizar el trabajo.

IMPORTANTE: En todo momento, para cada par Bin - Operación, existe solamente una tarea creada en la BD. La siguiente ejecución y posteriores, sólo se nos indican como 'calculadas virtualmente' en el calendario de mantenimiento, al que se puede acceder desde las clases de mantenimiento, Espacios, Grupos de trabajo y Operaciones), siguiendo el patrón temporal de la operación, pero se trata de una previsión. Hasta no cerrar la tarea abierta que tenemos pendiente, no se crea en BD el concepto de la tarea siguiente.

OJO! Sólo los usuarios de grupos administrador (admin) y experto (g1), pueden Retroceder la Fecha de cierrede un documento, para abrirlo y volver a editar cualquiera de sus datos. Las tareas cerradas se bloquean: no se pueden modificar ni eliminar.

Si eliminamos cualquier tarea abierta, se abre la última tarea cerrada anterior en la serie de ejecuciones.

El proceso de creación de la siguiente tarea para cada bin consiste en copiar la tarea completa (campos particulares incluidos, claro), y:

• Eliminar: medl, recl, perl, equl (medidas y consumos), gral (lista de imágenes asociados). texrea y norea (texto de trabajo realizado y marca de no realizado) campos calculados numreq y numinc (nº de medidas requeridas y de incidencias).
• Actualizar: _id, con el siguiente de la serie, tarant y tarsig (tareas siguiente y anterior), las enlaza con las correspondientes, fecpro (fecha programada), pone la fecha programada que corresponda en el patrón, feccre y fecmod (fechas de modificación y creación), pone las actuales.

Si la Operación tiene activadas las opciones de Consumos activos, se mostrarán las persianas de Personas y/o Equipos y/o Recursos, pero además, si está marcada la opción Defecto, pondrá el defecto de la operación en las persianas activas. Si no está esta opción, aparecerán todos los consumos vacíos.

El campo Duración de la tarea (h) se copia de la tarea anterior e incluye la duración de la tarea principal y de las ligadas, si las tiene.

El objeto tarea, si se quiere ver como un documento, pasa por los siguientes estados:

•  Una Orden de trabajo generada por el programador de Ingrid (Operación) sobre un concepto de mantenimiento, en una fecha, sobre el que hay que realizar una acción o trabajo (Operación), y habitualmente llevado a cabo por un grupo de trabajo de una o varias personas.
•  Un Parte del trabajo realizado siguiendo la orden, (también se puede devolver y cerrar como no realizado) que puede contener los datos de: medidas: acciones realizadas o lecturas tomadas durante el trabajo, consumos de recursos controlados por horario (personas y equipos), y consumo de recursos genéricos (especialidad de mano de obra, maquinaria, materiales y otros gastos).

El paso por estos estados lo marcan los hitos de tener la Fecha Programada (se convierte en orden de trabajo), y Fecha de cierre (se convierte en un parte ya acabado desde el punto de vista técnico, aunque incluya la marca de No realizada).

Definiendo operaciones que estén ligadas a una principal, mediante el campo Operación ligada a, conseguimos meter en una sola tarea, más trabajos (contra otros bins) que no sea el principal. También se pueden empaquetar en una tarea las medidas de una operación contra varios bins (a través de una ruta). Además en vez de agruparlas para su ejecución por los espacios de los bins, se puede utilizar un filtro con cierta ordenación, para establecer el orden de tareas a partir de un campo de los bins. Estas opciones se detallan más adelante.

Persiana Medidas

Contiene uno o varios paneles de lista para almacenar y gestionar la toma de datos al realizar la tarea. En caso de tener operaciones ligadas, aparecerá un panel por cada una de las operaciones y dentro de cada una incluso un paquete de medidas por cada bin (por ejemplo al tratarse de una operación de ruta que incluye varios bins).

Dependiendo de con qué datos se haya construido la tarea preventiva en la Operación, puede presentar 3  aspectos distintos:

•  Una simple lista de Medidas que están definidas en la operación. Por tanto, la descripción de la lista no es modificable de ningún modo en la tarea. Sólo podemos rellenar los valores que corresponda, en el campo Valor, según los datos que tengamos en la columna Unidades (Ud.), completar Observaciones de texto en cada medida y/o marcar en la columna (Inc.) una Incidencia manual pulsando [Control+clic] sobre la línea en esa columna. Si la Medida consiste en una lista de valores o un rango de números, por ejemplo, puede tener un límite mínimo y máximo que marcarán la medida como con incidencias si se sale del rango
  

  Condiciones para definir la operación: El el campo Bins donde se aplica la operación, el nombre de una clase, o una búsqueda reducida, y una lista de medidas en la persiana de Medidas. El Espacio de agrupación es automático, sino se pone.

  Vea más sobre las medidas en su definición en las Operaciones.

•  Varias secciones con un par Bin / Operación, aplicando en la misma tarea, las medidas de una operación a un bin, y las de otra a otro bin relacionado con el principal.

  
  Condiciones para definir la operación: Operaciones con medidas que tengan en el campo Operación ligada a, el identificador (clase.código) de la operación principal, y una condición en el campo Subbins, que relacione los conceptos de esa operación con los de la principal. En el ejemplo, en la carpeta car.OPE, la operación ope.inv-6M está ligada a ope.seg-6M y en el campo Subbins tiene el filtro: cla=inv seg=bin$ -cod, que selecciona los inversores cuyo campo seg (seguidor) es cada uno los de la operación principal y los ordena por código de forma descendente.

•  Varias secciones con las mismas medidas aplicadas a una serie de Bins, que compondrán en esa tarea una ruta de trabajo.
  
  Condiciones para definir la operación: un concepto de cualquier clase que represente una ruta y en el campo Subbins, una relación a un campo, que indique dónde encontrar los elementos de la ruta. En el ejemplo, .desl._id (comenzando el campo con punto), indica que es el identificador de cada elemento de la lista desl de los conceptos seleccionados como ruta.
  
  En este caso, en la esquina superior derecha de la persiana hay un conmutador para poner la vista de Bins en columnas de modo que se compactan las casillas para recogida de datos, con el inconveniente de que no se pueden mostrar ni introducir observaciones para cada línea de medida-concepto. Pero podemos alternar la vista si puntualmente hace falta. Lo que sí que se muestra en color rojo a la derecha de cada campo es la información de si tiene incidencias , si falta algún campo requerido , o tiene una incidencia manual .

Volcado a hoja de cálculo En cu

Pone medidas por defecto En cualquiera de los 3 casos se puede utilizar este botón (cuando las medidas se puedan editar), que pone en todas las líneas de medidas los valores por defecto definidos en la Operación para cada una. Si hay algún dato ya introducido, pide confirmación, ya que sobreescribe todas.

Muestra/Oculta imágenes de bins Este conmutador es otra funcionalidad que permite mostrar/ocultar la primera imagen de los bins dentro del bloque de medidas. Esto facilita su identificación y se puede combinar con el conmutador de datos verticales/horizontales ya que se muestran en los dos modos.

Bins en Filas/Columnas Alterna entre ambas visualizaciones, la vista de columnas puede ser más compacta y cómoda para no desplazarse por una página larga, pero tiene el inconveniente de que no s emuestran las Observaciones ni la informaciín de la columna Incidencias

Persianas de Consumos (Horas de personal, Recursos u otras personalizadas)

Incluye una lista para recursos horarios (Horas de personal) en una persiana, y Recursos genéricos en otra, con las horas y unidades consumidas en cada tarea. El uso se puede ampliar poniendo hora y fecha de inicio de fin de trabajo en las horas de personal, u otra persiana más con equipos para anotar los kms, recorridos u horas de uso de maquinaria, otra lista con gastos diversos...

El modelo incluido en la plantilla común es el más habitual: horas de trabajo por cada persona y recursos materiales genéricos de especialidad de mano de obra, maquinaria y/o materiales.

La lista de personas disponibles está filtrada mediante eventos de la clase, por el Grupo de trabajo de la tarea, y sólo se pueden introducir las personas que en su campo Grupo de trabajo tengan ese grupo, o los que no tengan grupo asignado.

La lista de equipos concretos, funciona de la misma forma, para la clase Equipo.

La lista de recursos genéricos disponibles para consumos, son los que tengan en el campo Clase de bin del recurso, la del bin que tiene la tarea, preventiva o correctiva.

En el ejemplo se incluye también en cada línea de consumo una referencia a un almacén, con lo que es muy fácil gestionar entradas y salidas de stock hacia las tareas, si cada vez que imputamos un material de un almacén, un evento resta esa cantidad.

Persiana Tareas del grupo de trabajo y Calendario

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

Esta persiana sólo aparece si la tarea tiene Grupo de trabajo.

Botones

Al pie no aparecen los botones Nuevo ni Copia, aunque se esté en edición y se tenga permiso para modificar tareas. Tampoco en el menú contextual de la esquina inferior derecha de la página. No se permiten esas acciones, ya que la creación y eliminación de preventivas es automática por su Operación.

En las tareas abiertas, los administradores tienen el botón Elimina, para volver a abrir la anterior tarea cerrada eliminando la actual. 

El botón Nueva correctiva permite crear una, que queda asociada a la preventiva actual mediante el campo Tarea que generó esta. Se crea con un código que representa con milisegundos la fecha y hora de creación en formato AAAAMMDD.HHMMSS.mmm. En la persiana de lista de referencias aparecen todas las correctivas que apuntan a la preventiva actual.

Tareas Correctivas (manuales)

Son documentos que reflejan el trabajo a realizar sobre un bien de inventario en una determinada Fecha, y el parte sobre eses trabajo. Habitualmente indican el Grupo de trabajo que lo va a realizar, asignado por el jefe de mantenimiento, igual que la fecha.

El objeto tarea, visto como un documento, pasa por estos estados:

1. Un Aviso de una incidencia o trabajo a realizar. Se puede haber creado:
- a partir de una tarea Preventiva, en ese caso, se muestra un campo con la referencia a la Tarea que generó esta correctiva.
- mediante un botón contextual en algún elemento de inventario, que crea un aviso sobre el elemento, tomando ese elemento como BIN.
- manualmente como creación de concepto
En todos los casos tendrá rellena la Fecha de Aviso, manual o automáticamente con la fecha actual.

2. Orden de trabajo, si el jefe de mantenimiento considera que debe realizarse, introduce la Fecha Programada y el Grupo de trabajo que lo va a realizar según la urgencia, la ubicación geográfica, el gremio necesario, etc.

Cada Grupo de trabajo, habitualmente desde dispositivos móviles, tiene acceso a las órdenes asignadas a su grupo, y a las que no tienen ninguna asignación, a través del usuario de acceso a la BD.

Información OPCIONAL:

•  Puede indicarse la Operación, para clasificar los tipos de Correctivos. Si no se usan operaciones, las persianas de Medidas y Consumos descritas más adelante, se configuran en una operación de defecto con código ope.. . Si esta operación no existe, no sale ninguna persiana ni de Medidas, ni de Consumos. ATENCIÓN: Para que se muestre el panel de medidas también tiene que haber un bin en la tarea, ya que el panel de medidas es por cada bin (por ejemplo en rutas).
•  Si se quiere tener un control de carga de trabajo pendiente, se debe rellenar la Duración de la tarea (en horas). Este dato se completa automáticamente con la duración definida en la Operación del campo anterior, si es que la utilizamos y tiene duración definida.

3. Parte de trabajo, lo debe rellenar el operario que la realiza (o el jefe de grupo en grupos con varias personas). A partir de la Descripción del trabajo a realizar y del bin indicado, se realiza la tarea -habitualmente correctiva-, y a diferencia de las Preventivas (que suelen tener una relación de medidas a completar mientras se realiza el trabajo), aquí se puede indicar un texto con descripción de incidencias o notas del trabajo realizado.

En caso de que la operación tenga definidas Medidas, se pueden rellenar sus valores como en las Preventivas, aunque no es habitual.

También se puede descartar el aviso por diversos motivos, cerrándolo con la marca de NO ejecutado.

Por último, también opcionalmente, en la persiana de Consumos (Horas de de Personal, Equipos y/o Recursos de cualquier clase), los técnicos pueden completar los recursos que han sido necesarios en la ejecución de la tarea.

Al final, se pulsa el botón Cerrar tarea, con lo que se rellena la fecha y hora de cierre.

4. (OPCIONAL) Conformidad a la tarea. En la plantilla para tareas correctivas propuesta por defecto en Ingrid, se contempla este "visto bueno" al trabajo, que realiza un inspector (en caso de que lo haya), y que puede indicar observaciones en caso de estar disconforme, y firmar el cierre administrativo completo de la tarea. Si no existe este perfil o esta necesidad, pueden quitarse estos campos de la ficha de la tarea, como cualquier otro.

Cierre técnico y administrativo de cada tarea

Muchas veces, en el caso de tareas correctivas, se quiere considerar el cierre habitual, guardado en al Fecha de cierre, como que la tarea está acabada (fin técnico), pero luego se quiere un cierre posterior (fin administrativo), para considerarla cerrada documentalmente, por ejemplo si hay que imputar gastos posteriores a la realización del trabajo, valorar los consumos de materiales, esperar la aprobación o inspección del cliente, etc.

Para implementar esta forma de trabajo, la plantilla de defecto de Ingrid para correctivas, incluye un campo de tipo traza Cierre administrativo, posterior al campo feccer.

El estado de una tarea dependiendo de estos dos campos sería:

Modificar el modelo de datos

Además de los hitos mencionadas, que son el flujo normal de una tareas correctiva como se entiende en Ingrid, se puede ampliar con otros campos y/o listas de relaciones (a rótulos, u otros conceptos, diccionarios...)

Botones

Al pie sólo aparecen los botones Nuevo, Copia, Elimina, (si se está en edición y se tiene permiso para ello) cuando la tarea está abierta. Las cerradas no se pueden manipular.

Persiana Tareas del grupo de trabajo y Calendario

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

Esta persiana sólo aparece si la tarea tiene Grupo de trabajo.

Eventos en las tareas

Cada una de las dos clases de tareas predefinidas en Ingrid (preventivos y correctivos) tiene sus propios eventos que forman parte de la funcionalidad en la aplicación. Por ejemplo en preventivos, cuando se pone fecha de cierre a una orden de trabajo, se convierte de facto en un parte al bloquearlo sin permitir más edición (excepto a administradores), además se crea la tarea siguiente los los datos de ese parte cerrado y el patrón temporal de la operación, etc.

Además el propio usuario administrador puede definir eventos personalizados tanto en tarpre, como tarcor y en tar; es decir comunes a todas las clases de tareas: las 2 clases predefinidas y cualquier otra que definamos nosotros, por ejemplo para mantenimiento conductivo, con tareas conductivas.

Estos eventos personalizados se juntan con los fijos de la aplicación y hay que tener cuidado la programarlos para no reescribir de forma no deseada un evento 'fijo'. Los predefinidos son:

Eventos comunes a todas las subclases de tareas (en .tar):
 - perlGraba, equlGraba, reclGraba - calculan la cantidad en los consumos al cambiar los kms u horas consumidos.
 - perl_imp$Lee - propone el personal con la máscara, en función del grupo de trabajo de la operación de la tarea.
En correctivas (.tarcor):
 - binGraba - pone como espacio el del bin,. si lo tiene.
 - fecaviGraba - al poner fecha de aviso, da error si no hay bin.
En preventivas (.tarpre):
 - texpro$Lee - lee y rotula en la tarea la descripción del trabajo a realizar de la operación (texpro).
 - fecproGrabado - refresca ventana para que cambien los campos según el hito de 'parte programado'.
 - feccerGraba - comprueba que no haya valores requeridos sin tomar en medidas y que no esté marcada como no realizada pero tenga valores en medidas, y sino, la cierra y refresca ventana con el hito de 'orden cerrada'.
 - elimina - impide la eliminación manual de  preventivos. La gestión es automática al