Cegid XRP Ultimate  |  I3   Actualisé le 06/10/2022
	Maintenance
TGPP - Actions réalisées par le traitement de génération du planning préventif

Contrôles et paramétrages

Conditions qui doivent être valides pour qu'une demande d'intervention soit traitée :       - sa classe (GNDI) doit être préventive et avoir un calendrier défini ;       - elle ne doit pas être suspendue ;       - elle doit être associée à une règle de préventif (GRPE). Cette dernière peut être définie pour l'équipement ou une famille supérieure suivant le chemin de proposition de la classe (GNDI) ;       - elle doit posséder un plan d'opérations (QMIPOP).    Conditions vérifiées pour l'équipement de la demande d'intervention :       - sa date de début de préventif doit être comprise dans la période de génération du traitement ;       - son statut (GSETN) doit être autorisé ;       - il doit être autorisé pour la maintenance préventive.    Paramètres qui doivent être définis pour le traitement :       - AUTQAM / UNIHRE : la chaîne 1 correspond à l'unité de référence des heures ;       - AUTQAM / TYPRGP : la chaîne 1 comporte la liste des données prises en compte pour le regroupement des sous-tâches ([C]lasse, [O]pération, [T]ype intervenant) ;       - AUTQAM / CRIRPE : la chaîne 1 comporte éventuellement le critère complémentaire permettant d'affiner le choix de la règle de préventif (GRPE).

Choix de la date de départ

S'il existe déjà des interventions planifiées pour la DI, on se base sur la dernière : la règle de préventif de la DI (GRPE) permet de déterminer la date qui servira de point de départ (théorique/réelle/initiale et début/fin). Si la date de demande d'intervention (GINT) est supérieure à la date issue de la règle, c'est elle qui sera prise en compte.    S'il s'agit de la première génération de la DI, on prend la date de demande d'intervention (GINT), si elle n'est pas renseignée, on prend la date de début de préventif de l'équipement (GEQT), sinon on prend la date de début de génération.    Dans tous les cas, la prochaine intervention sera planifiée pour la date de départ + la durée du cycle de la DI, sauf si c'est la date de demande d'intervention qui est prise en compte, à ce moment, on repart directement de celle-ci.    Dans le cas où le déclenchement de la DI est associé à un compteur sans historique, la date de début théorique est initialisée à nul, et c'est au moment de la mise à jour du compteur de l'équipement (GNUMM) que l'intervention sera réellement initialisée.

Génération des tâches supérieures

L'essentiel de la génération du planning préventif dépend de la périodicité de la demande d'intervention :    - Compteur non "historisable" ou avec remise à zéro : création d'un enregistrement avec la date de début théorique nulle ;    - Compteur "historisable" sans remise à zéro : calcul de l'intervalle moyen entre deux interventions à partir de l'historique du compteur de l'équipement ; déduction de la date de départ en fonction de la valeur courante du compteur et planification des prochaines interventions en fonction cet intervalle (exemple 1) ;    - Si "périodique" ou "les deux" : création d'autant d'enregistrements qu'il faut pour atteindre la date limite de planning saisie à la soumission :       · Si "n" jours : calcul des dates de début théoriques en fonction du calendrier, du délai ("n" jours) et de la date de départ du calcul du planning de la de règle du préventif (GRPE) :                      . date de début (exemple 2),                      . date de fin (exemple 3),       · Si "n" semaines : on ajoute n x 7 jours à la date de départ, sans prendre en compte le calendrier.       · Si "n" mois : dans ce cas, on ne prend pas en compte le calendrier pour calculer la date de fin, on se contente d'incrémenter la date de départ de "n" mois. Le paramètre HEDQMINT / M permet, au travers de sa valeur testée 1, de savoir si la fin de mois est gérée ou non. Exemple : pour une date de départ au 28/02/2002 avec une périodicité de un mois, on obtient le 31/03/2002 si la fin de mois est gérée (valeur testée 1 vaut "FM") sinon, on obtient le 28/03/2002. Ensuite, la date de début théorique correspondra au prochain jour ouvert supérieur ou égal à la date calculée.       · Si "n" années : même principe que pour les mois, sauf que c'est le nombre d'années qui est incrémenté.       · Sinon : les dates de début théoriques seront déduites à partir de jours fixes paramétrés dans GINT (exemple 4). Il est possible de définir des fourchettes inversées de façon à obtenir, par exemple, une génération de novembre à février (mois "11" à "02"), du vendredi au lundi (jours "6" à "2") et du 20 au 10 du mois.    - Si "dates fixes" : création d'une ligne de données par date fixe, définie dans la gestion des dates fixes d'intervention (GMDFI), comprise dans la période saisie à la soumission.    Si la règle du préventif le permet, la création de liens se fait entre chaque intervention d'une même DI, suivant l'ordre dans lequel elles sont générées.

Génération des sous-tâches

Chaque tâche planifiée peut donner lieu à la création de 1 à "n" sous-tâches, que l'on pourra rechercher en activant la case à cocher "Détail" dans la gestion du planning préventif (GPLP). Le nombre de sous-tâches dépendra essentiellement du plan d'opérations (QMIPOP) et du type de regroupement (voir paramètre AUTQAM / TYPRGP).    Si toutes les lignes d'opérations du regroupement possèdent le même délai, la date de début théorique de la sous-tâche sera décalée suivant ce dernier. Comme la durée du planning est toujours exprimée en heure, le délai sera toujours converti de son unité vers l'unité de référence des heures (voir paramètre AUTQAM / UNIHRE).    Le numéro d'ordre, des lignes d'opérations permet de positionner les sous-tâches dans le temps les unes par rapport aux autres.    Au final, les liens entre les sous-tâches sont générés en fonction de la définition des liens des lignes du plan d'opérations (QMILTAN).    Exemple :    L'exemple ci-dessous se focalise uniquement sur la décomposition de la tâche supérieure en différentes sous-tâches, on prendra le type de regroupement maximum (classe + opération + type intervenant).    Définition du plan d'opérations (QMIPOP) :    Définition des liens entre les lignes (QMILTAN) :    Résultat de la génération :

Ombrage des plannings

L'ombrage permet de désactiver une tâche de planning si une autre tâche regroupe l'intervention sur la même période. Cela permet d'éviter la génération de bons de travail inutiles.    Cet ombrage se base sur les hiérarchies (GMHIE). Il est géré pour les hiérarchies de demandes d'interventions et de gammes sur un chemin de type ombrage (CHMQMHIE).    Le paramétrage du chemin (valeur testée 2) donne l'horizon de l'ombrage. En effet, une tâche peut être ombrée par une autre même si ses dates ne sont pas comprises dans la tâche qui ombre. Un horizon permet de gérer ce cas, à la journée, semaine, mois ou année. Les bornes de la tâche qui ombre seront définies suivant cet horizon.    Exemple avec un horizon à la semaine :        Si on ne prend pas en compte l'horizon, la tâche 2 n'est pas ombrée par la tâche 1. Avec un horizon à la semaine (représenté en vert), la tâche 2 est ombrée.    Dans le cas de l'ombrage, la référence du planning de regroupement de GPLP sera renseignée sur la tâche ombrée avec le numéro de planning. Cet ombrage est effectué dès qu'une tâche de planning est créée, modifiée ou supprimée et qu'une hiérarchie liée existe dans GMHIE.

Différents cas de figures possibles

Exemple 1

Configuration :    - planification sur l'année 2000 (avec calendrier réel) ;    - déclenchement à seuil ;    - compteur "historisable" sans remise à zéro ;    - seuil du compteur défini au niveau de la DI = 100.    Historique du compteur de l'équipement de la DI (GNUMM) :    Différence de jours entre les bornes de l'historique :       01/08/2000 - 01/02/2000 = 182 jours.    Différence entre les valeurs des bornes de l'historique :       459 - 75 = 384 (unité du compteur).    Calcul de l'équivalence du seuil en nombre de jours :       Intervalle moyen = (100 * 182) / 384 = 47 jours (en vert).    Déduction de la date de la prochaine intervention :       Valeur courante du dernier relevé = 459.       Prochain seuil = 500.       -> différence : 500-459 = 41 <=> (41*47)/100 = 19 jours (en gris foncé).    Résultat :        Avec utilisation de période glissante (1 mois) :       01/08/2000 - 01/07/2000 = 31 jours.    Différence entre les valeurs des bornes de l'historique :       459 - 389 = 70 (unité du compteur).    Calcul de l'équivalence du seuil en nombre de jours :       Intervalle moyen = (100 * 31) / 70 = 44 jours.    Déduction de la date de la prochaine intervention :       Valeur courante du dernier relevé = 459.       Prochain seuil = 500.       -> différence : 500-459 = 41 <=> (41*44)/100 = 18 jours.

Exemple 2

Configuration :    - période du 01/01/2003 au 28/02/2003 ;    - intervalle de 10 jours ;    - calcul partir de la date de début théorique.    Résultat :

Exemple 3

Configuration :    - période du 01/01/2003 au 28/02/2003 ;    - intervalle de 10 jours ;    - calcul partir de la date de fin théorique (durée de l'intervention = 5 jours).    Résultat :

Exemple 4

Configuration :    - période du 01/01/2003 au 31/12/2003 ;    - mois de janvier à février ;    - du 15 au 31 du mois ;    - du lundi au mardi.    Résultat :