TPCLO - Actions réalisées par le traitement de clôture

   Un projet ne peut être clôturé que si toutes ses phases le sont.
Une phase ne peut être clôturée que si toutes ses tâches le sont.
Une tâche ne peut être clôturée que si toutes ses sous-tâches le sont.

   Pour les projets, les phases et les tâches, réalisation des contrôles paramétrés au niveau des règles de clôture (GPRCL).
Pour les tâches, en plus de ces contrôles, une vérification sera effectuée sur le solde des lignes de panier.

   Lorsque la clôture se termine sans erreur, le projet et les phases passent l'étape associée au traitement de clôture.
Cette étape doit être définie au niveau de la transaction des étapes par classe (GETCJ).

   Deux cas sont possibles :
- L'étape de clôture du projet est la même que celle des phases. Elle doit être définie pour l'entité "Tous" au niveau du complément d'étape (GCECJ). Si la remontée automatique est active, le projet est clôturé après le traitement de la dernière phase.
- L'étape de clôture du projet est différente de celle des phases. Dans ce cas, celle des phases doit être une étape définie pour l'entité "Phase" et celle du projet pour l'entité "Projet" (GCECJ). De plus, l'étape de clôture des phases doit être inférieure à celle des projets. La remontée automatique n'est pas possible dans ce cas-là.

   Lorsque la clôture d'une tâche s'effectue sans erreur, le traitement positionne le statut de la tâche à "T" (valeur imposée).
Il est possible de référencer ce statut au niveau de la transaction GPNST et ainsi de définir des règles de passage du statut.
Le statut "T" ne peut être associé qu'à un traitement de clôture dans les associations des statuts aux transactions (GPAST).

   Si aucune règle particulière concernant les statuts ne doit s'appliquer à la clôture, il n'est pas nécessaire de définir le statut "T", il est automatiquement affecté à la tâche par le traitement.

   
Restrictions des segments de CGR (validité des structures à date)

   Fermeture des hiérarchies de segments des CGR associées au projet à la date de clôture
Cette fonctionnalité permet de fermer les hiérarchies des segments de CGR associées au projet en renseignant la date de fin de validité de la composition (GCCG) avec la date de clôture et ceci pour tous les établissements utilisés lors du multi-établissements (GPMET).
Cette fonctionnalité est disponible seulement lors de la clôture des projets et lorsque la datation des compositions de CGR est active (occurrence DATECCG du paramètre AUTODE).

   Selon le paramétrage défini au niveau des règles de clôture des projets (GPRCL), le traitement contrôle que les dates réelles de chaque entité soient renseignées.
La date de début réelle a pu être affectée par la saisie de temps (GTMP) ou par la saisie de tâches de planning (GNTAC). Elle peut être également affectée lors du traitement de clôture si le paramétrage le permet (option "Affectation des dates de début réelles non renseignées" active pour la règle de clôture (GPRCL)).
La date de fin réelle a pu être renseignée par la saisie de tâches de planning ou par le traitement de clôture lui-même si elle ne l'était pas avant le traitement.
Il est donc possible, suivant le paramétrage de la clôture, que la date de fin réelle soit renseignée sans que celle de début ne le soit. Le contrôle des dates réelles permet d'éviter ce cas.

   Affectation des dates de début réelles non renseignées
La date de début réelle de chaque entité (projet, phase ou tâche) est renseignée lors du traitement si les conditions suivantes sont vérifiées :
- L'option "Affectation de la date de début réelle non renseignée" de l'entité est active au niveau des règles de clôture de projets (GPRCL).
- La date de début réelle de l'entité est non renseignée.

   La date de début réelle du projet est équivalente à la plus petite date entre :
- la date de début théorique ;
- la date initiale du projet ;
- la date de projet ;
- la plus petite des dates de début réelles des phases du projet.

   La date de début réelle de la phase est équivalente à la plus petite date entre :
- la date de début théorique ;
- la date initiale de la phase ;
- la date de phase ;
- la plus petite des dates de début réelles des tâches de la phase.

   La date de début réelle de la tâche est équivalente à la plus petite date entre :
- la date de début théorique ;
- la date initiale de la tâche ;
- la date de tâche ;
- la plus petite des dates de début réelles de ses sous-tâches.

   Lorsque la clôture se fait sur une phase, une tâche ou une sous-tâche, que la date de début réelle de l'élément supérieur (projet, phase ou tâche suivant le niveau) est renseignée et qu'elle est supérieure à celle qui est proposée, alors cette nouvelle date est également affectée aux éléments supérieurs correspondants. Ainsi, lorsque la clôture se fait sur une phase, sa date de début réelle peut remonter sur son projet. Lorsque la clôture se fait sur une tâche (de niveau 0), sa date de début réelle peut remonter sur la phase dont elle dépend et sur son projet. Lorsque la clôture se fait sur une sous-tâche, sa date de début réelle peut remonter sur les tâches supérieures, sur la phase dont elle dépend et sur son projet.

   Affectation des dates de fin réelles
Si la date de fin réelle du projet n'est pas renseignée avant la clôture du projet, elle est affectée lors de la clôture.
La date de fin réelle est équivalente à la plus grande date entre :
- la date de clôture si elle est renseignée lorsque le traitement est lancé, si ce n'est pas le cas, c'est la date logique qui est prise en compte ;
- la plus grande des dates de fin réelles des phases du projet, si elle est supérieure à la date de clôture.

   Si la date de fin réelle de la phase n'est pas renseignée avant la clôture de la phase, elle est affectée lors de la clôture.
La date de fin réelle est équivalente à la plus grande date entre :
- la date de clôture si elle est renseignée lorsque le traitement est lancé, si ce n'est pas le cas, c'est la date logique qui est prise en compte ;
- la plus grande des dates de fin réelles des tâches de la phase, si elle est supérieure à la date de clôture.

   Si la date de fin réelle de la tâche n'est pas renseignée avant la clôture de la tâche, elle est affectée lors de la clôture.
La date de fin réelle est équivalente à la plus grande date entre :
- la date de clôture si elle est renseignée lorsque le traitement est lancé, si ce n'est pas le cas, c'est la date logique qui est prise en compte ;
- la plus grande des dates de fin réelles des sous-tâches de la phase, si elle est supérieure à la date de clôture.

   L'avancement réel (GPPAR) étant saisi au niveau des tâches, ce contrôle ne se fait que pour cette entité.
Lorsque le paramétrage des règles de clôture indique que le contrôle de l'avancement réel à 100% est actif et que de l'avancement réel est saisi pour la tâche à clôturer, il est vérifié que le total saisi soit effectivement à 100%.

   Attention : si de l'avancement réel a été saisi et que le type d'avancement a été supprimé au niveau du type de tâche (GPTAC), ce contrôle n'est plus réalisé et cela même si le contrôle "Avancement réel à 100%" est actif.

   Il est possible que des contrôles sur des éléments générés dans l'Application Achats soient effectués.

   L'étape des demandes d'achats générées depuis les paniers d'achats (GPWGEA, TPBGVTA, TPBVTPA), doit être supérieure ou égale à l'étape minimale des demandes paramétrée pour la règle de clôture (GPRCL).

   L'étape des commandes d'achats générées depuis les paniers d'achats, doit être supérieure ou égale à l'étape minimale des commandes paramétrée pour la règle de clôture.

   L'étape des marchés d'achats générés depuis un projet ou une tâche (TPBMAA), doit être supérieure ou égale à l'étape minimale de marché définie pour la règle de clôture.

   Il est possible que des contrôles sur des éléments générés dans l'Application Maintenance soient effectués.

   L'étape des demandes d'intervention générées depuis les projets (TPBDI), doit être supérieure ou égale à l'étape minimale des DI paramétrée pour la règle de clôture (GPRCL).

   L'étape minimale des bons de travail générés depuis les tâches (GPWGEM, TPBGVTM, TPBVTPM), doit être supérieure ou égale à l'étape minimale des BT paramétrée pour la règle de clôture.

   Il est possible que des contrôles sur les éléments générés dans l'Application Ventes soient effectués.

   L'étape des commandes de ventes générées depuis les paniers de ventes (GPWGEV, TPBGVTV, TPBVTPV), doit être supérieure ou égale à l'étape minimale des commandes de ventes paramétrée pour la règle de clôture (GPRCL).

   Il est possible que sur les lignes de temps (GTMPJ) associées aux projets, aux phases et aux tâches des contrôles soient effectués.

   L'étape minimale des lignes de temps (GTMP) associées aux entités des projets, doit être supérieure ou égale à l'étape minimale des temps paramétrée pour la règle de clôture (GPRCL).

   Il est possible de mettre en place des contrôles sur les mouvements de stock générés depuis les paniers de stocks.

   Lorsque l'option "Mouvements traités" est active pour la règle de clôture (GPRCL) et qu'il existe des mouvements de stock générés depuis les projets (GPWGES, TPBGVTS, TPBVTPS), ces mouvements doivent être à l'état "Traité".

   Ce contrôle ne se fait que lors de la clôture des tâches.
Pour chacune des lignes de panier, quelle que soit leur destination (achats, ventes, stock et maintenance), le pourcentage "déjà traité" doit être supérieur ou égal au pourcentage "initial".
Si la tâche doit être clôturée malgré tout, il faut nécessairement activer l'option "Abandon du solde des lignes de panier" au niveau des critères de la soumission.
Attention : l'abandon du solde des lignes de panier concerne tous les paniers de la tâche (achats, ventes, stock et maintenance), donc il faut être prudent avec les tâches multi-domaines.