GPPRO - Projets

   Cette transaction permet de saisir ou de consulter les en-têtes de projets.

   Structure des projets :

   L'identifiant d'un projet pour un établissement est composé de la classe (GPCPR), du numéro et du sous-numéro.

   La classe est une information essentielle d'un projet. Elle doit être définie au niveau de la gestion des classes de projets (GPCPR).
En fonction de celle-ci, des valeurs sont proposées par défaut :
   - l'étape de création de projet est égale à l'étape par défaut associée à la classe dans les étapes par classe (GETCJ) ;
   - les informations concernant la devise et la devise de reporting (mode de change, date de validité du cours) ;
   - les propositions de la date initiale et de la date de projet ;
   - l'unité de durée du projet ;
   - la fonction et le rôle du gestionnaire principal du projet.

   La classe permet de gérer le compteur des numéros de projets et de contrôler la saisie de données sur un projet :
   - la référence interne, la référence externe ;
   - la saisie ou la génération d'un marché de ventes, d'achats ou d'une demande d'intervention ;
   - la saisie ou la génération d'un segment du projet.

   C'est aussi de la classe dont dépend un certain nombre d'autorisations ou de :
   - droits de création, modification et suppression des informations d'un projet en fonction de son étape ;
   - droits de saisie et type de saisie pour les 15 paramètres de projets, des phases ou des tâches via la définition des paramètres des projets (GPDPP).

   En fonction de la classe de projets, ce numéro peut être incrémenté automatiquement de 1 en 1 à chaque nouveau projet (numérotation automatique), ou bien il peut être saisi par l'utilisateur (numérotation manuelle).
Lors de la duplication d'un projet par manipulation dans GPPRO, ce numéro permet la création d'un sous-projet ou d'un nouveau projet : s'il n'est pas modifié, un sous-projet est créé.

   Le sous-numéro n'est pas accessible. Il est égal à 1 pour le premier sous-projet, puis il est incrémenté de 1 en 1 à la création de chaque nouveau sous-projet (le numéro restant inchangé).
Les sous-projets peuvent être générés par des traitements (par exemple, lors d'une duplication de projets par le traitement TPDPR), mais peuvent également être saisis dans le cas d'un complément de projet.
Pour créer un sous-projet, la démarche à suivre est la suivante :
- rechercher le projet modèle ;
- dupliquer le projet ;
- modifier éventuellement des informations ;
- valider.

   Ces informations influencent la génération des paniers des tâches. Au niveau des nomenclatures, il est possible d'initialiser certaines informations du panier avec les références. Si une référence doit suivre, celle de la tâche (si elle est renseignée) est affectée prioritairement à celle du projet.

   Elles peuvent être ensuite propagées sur les commandes issues des projets.

   Zone alphanumérique libre, elle représente une référence interne du projet.
Elle peut être rendue obligatoire selon le paramétrage de la classe de projets (GPCPR).
Il est possible de contrôler l'unicité de la référence interne suivant l'occurrence REFUNI du paramètre AUTQPR.

   Zone alphanumérique libre, elle représente une référence externe du projet.
Elle peut être rendue obligatoire selon le paramétrage de la classe de projets (GPCPR).

   Il s'agit du gestionnaire dit "principal" du projet.
Lors de la création du projet, il est automatiquement créé dans la gestion des gestionnaires de projets (GPGPR) avec la fonction et le rôle définis au niveau de la classe de projets. D'autres gestionnaires peuvent être associés manuellement au projet via cette gestion.

   Il s'agit du segment associé au projet. Suivant la classe de projets, il peut être :
- obligatoire, facultatif ou interdit ;
- modifiable ou non ;
- saisi ou généré.

   La génération automatique du segment est décrite dans le principe de génération automatique d'un segment.
Ce segment devient le segment supérieur, suivant le chemin défini dans la classe de projets, des segments des phases et des tâches s'ils existent. Ainsi une hiérarchie de segments est créée suivant une structure identique à celle d'un projet.

   Exemple :

   Le segment peut notamment être utilisé au niveau des budgets ou pour la création du CGR composé des tâches via le paramétrage de la clé analytique (GPCLJ). Il peut être ensuite propagé sur les commandes d'achats (GCDA), les commandes de ventes (GCDV), les mouvements de stocks (GMVS) ou les bons de travail (GORM) issus des projets.
La hiérarchie issue du projet peut être également rattachée à un éventuel CGR supérieur défini dans la gestion des CGR supérieurs (GPCSP).
Ces CGR peuvent être générés selon le paramétrage saisi au niveau de la définition des chemins de composition (GPDCC).
A noter que si plusieurs pères sont définis pour le projet, ceci se fera via différents chemins. La hiérarchie de CGR issue du projet sera alors dupliquée sur ces différents chemins.

   Permet d'affecter une fourchette de dates théoriques au projet.
Toutes les phases associées à un projet doivent avoir leurs dates de début et de fin théoriques comprises dans la fourchette de dates théoriques du projet.

   Il est possible d'affecter également une durée théorique dont l'unité peut être proposée par rapport à la classe de projets.

   Ces informations peuvent être notamment utilisées dans le cadre d'une planification de projets.

   La fourchette de dates de début et de fin réelles du projet n'est pas accessible.

   Affectation possible de ces dates :

   1) La date de début réelle peut être affectée automatiquement lors de la saisie des temps (GTMPJ) suivant le paramétrage de l'association classe de temps/classe de projets (GPATP). Elle est alors égale à la plus petite date saisie au niveau des temps pour le projet, les phases ou les tâches. Ceci est calculé lors du passage de l'étape définie dans le paramétrage GPATP (saisie, validation, transfert en comptabilité, etc.).

   2) Le traitement de clôture (TPCLO) peut également contrôler que les deux dates réelles soient renseignées, suivant le paramétrage des règles de clôture des projets (GPRCL).
Pour cette raison, il est possible de paramétrer l'affectation des dates de début et de fin réelles.
Si c'est le cas, la date de début réelle affectée est la plus petite date parmi :
   - la date de début réelle du projet, si elle est renseignée ;
   - la date de début théorique du projet ;
   - la date du projet ;
   - la date initiale du projet ;
   - la plus petite date de début réelle des phases ;
   - la date du jour.

   La date de fin réelle affectée est la plus grande date parmi :
   - la date de clôture ;
   - la plus grande date de fin réelle des phases ;
   - la date du jour.

   3) Il est également possible de saisir les informations réelles du projet (à ne faire que dans certains cas particuliers comme une reprise par exemple). Pour cela, il faut définir le paramètre DAT associé au mnémonique.

   Ces informations peuvent être notamment utilisées dans le cadre d'une planification de projets.

   Selon le paramétrage défini au niveau de la classe de projets, cette date peut être :
   - obligatoire ;
   - modifiable ;
   - proposée à la création du projet : les valeurs possibles sont les occurrences du paramètre DI1QPCPR.

   La date de projet est obligatoire.

   Selon le paramétrage défini au niveau de la classe de projets, cette date peut être :
   - modifiable ;
   - proposée à la création du projet : les valeurs possibles sont les occurrences du paramètre DP1QPCPR.

   Lors de la création d'un projet, l'étape est proposée par défaut à partir de l'étape par défaut de la classe de projets définie dans GETCJ.
Ensuite, l'étape évoluera au fur et à mesure des traitements et éditions réalisés.

   Contrôle des droits de création, modification et suppression des informations d'un projet en fonction du paramétrage de la classe du projet et de son étape. Au niveau des classes dans GPCPR, indication des étapes maximales de création, modification et suppression. Pour que la création soit possible, l'étape du projet doit être inférieure ou égale à l'étape maximale de création paramétrée pour la classe (même principe pour modification et suppression).

   Affichage de la date de passage de l'étape, il s'agit de la date correspondant au dernier traitement (ou édition) effectué pour le projet.

   Devise qui est proposée par défaut au niveau des tâches liées aux phases de projets. Elle peut être modifiée sur les tâches.

   Information présente uniquement dans la grille. Il s'agit d'un numéro identifiant un projet. Un projet a un numéro unique. Ce numéro interne est géré automatiquement par l'intermédiaire d'un compteur défini dans la transaction GNUI pour la table QPPRO.

   Les valeurs de la catégorie sont les occurrences du paramètre CATQPPRO.
Elles permettent d'identifier des critères de regroupement ou d'extraction supplémentaires pour des projets.

   La saisie, le contrôle et le format des 20 paramètres sont définis dans la gestion de définition des paramètres (GPDPP).
Ils peuvent, selon le paramétrage du modèle de création de CGR (GPMCC), suivre sur les paramètres des CGR segments créés depuis l'Application Projets.
Ils peuvent également être propagés sur les commandes (achats ou ventes), les mouvements de stocks ou les bons de travail issus de projets, suivant le paramétrage des articles des nomenclatures (GPPAC, GPPVT, GPPSK, GPPMA).

   Cette information permet de saisir une famille de clients ou un client principal au projet utilisé pour la génération des marchés de ventes (TPBMAV) ou pour proposer un client au niveau des informations contrat des tâches (GPLPP).

   L'accessibilité du champ est liée au paramétrage de la classe de projets (GPCPR).
Si la classe indique que le marché est interdit, l'information est grisée.
Si le marché est obligatoire ou facultatif, l'information est accessible.
Si le marché doit être généré automatiquement, le champ "Marché" est grisé et ne sera renseigné qu'après avoir lancé le traitement de génération (TPBMAV). Différentes informations du projet sont nécessaires pour la création du marché (les intitulés, les dates, les paramètres, etc.). Un modèle de création de marchés (GPMMA), associé à la classe de projets, définit les règles de création.

   Cette information permet de saisir une famille de fournisseurs ou un fournisseur principal au projet utilisé pour la génération des marchés d'achats (TPBMAA) ou pour proposer un fournisseur au niveau des informations contrat des tâches (GPLPP).

   L'accessibilité du champ est liée au paramétrage de la classe de projets (GPCPR).
Si la classe indique que le marché est interdit, l'information est grisée.
Si le marché est obligatoire ou facultatif, l'information est accessible.
Si le marché doit être généré automatiquement, le champ "Marché" est grisé et ne sera renseigné qu'après avoir lancé le traitement de génération (TPBMAA). Différentes informations du projet sont nécessaires pour la création du marché (les intitulés, les dates, les paramètres, etc.). Un modèle de création de marchés (GPMMA), associé à la classe de projets, définit les règles de création.

   L'accessibilité des champs est liée au paramétrage de la classe de projets (GPCPR).
Si la classe indique que la demande d'intervention est interdite, les informations sont grisées.
Si la demande d'intervention est obligatoire ou facultative, les informations sont accessibles.
Une DI pourra être éventuellement générée depuis l'en-tête de projet, suivant un modèle préalablement défini dans les modèles de marchés/DI (GPMMA) et associé au niveau de la classe de projets, par le traitement de génération des demandes d'intervention (TPBDI).

   La famille d'équipements et le chemin sont proposés depuis le modèle de création de marchés/DI (GPMMA) associé à la classe de projets. Ces informations sont facultatives.

   Le bâtiment et le chemin sont proposés depuis le modèle de création de marchés/DI (GPMMA) associé à la classe de projets. Ces informations sont facultatives.

   La gestion des champs "Etablissement", "Classe d'intervention" et "Numéro d'intervention" peut varier selon le paramétrage de la classe de projets :
- Si la classe est génératrice de DI, la classe et le numéro ne seront pas accessibles et seront renseignés automatiquement après l'appel du traitement de génération de DI (TPBDI).
- Si la classe n'est pas génératrice de DI, ces informations seront accessibles : pour associer une demande d'intervention, il faudra aller préalablement la saisir via les transactions de l'Application Maintenance et les renseigner ensuite manuellement.
- Si la classe de projets indique que ces champs sont obligatoires, ils devront être renseignés pour que le projet soit validé par le traitement de validation (TPVAL).
- Si la classe de projets indique que ces champs sont interdits, ils ne seront pas accessibles.
- Si la classe de projet indique que ces champs sont facultatifs, aucun contrôle ne sera effectué par le traitement de validation des projets (TPVAL).

   Ces champs ne sont pas accessibles. Ils permettent d'afficher certaines informations des tâches de planning (classe, numéro, date de début, heure de début, date de fin, heure de fin théoriques, durée et unité) lorsque le projet a généré une tâche.

   La date de génération d'avancement sert à générer les périodes sur lesquelles seront saisis les pourcentages d'avancements (GPPAV).
Cette date peut être soit saisie, soit calculée selon les valeurs du paramètre AUTQPR, occurrence PRODAV.

   Si elle est modifiée, les avancements à saisir sont recalculés. La nouvelle date ne peut pas être inférieure à la date d'origine.

   Mode de change, date de validité et cours de la devise principale du projet.

   Assistant de changement de gestionnaire, au niveau du projet, mais aussi au niveau des phases et des tâches.

   Zones identifiants sur 10 caractères : 5 champs laissés libres à l'utilisateur.
Ils peuvent, selon le paramétrage du modèle de création de CGR (GPMCC), suivre sur les identifiants des CGR segments créés depuis l'Application Projets.

   Zones identifiants sur 20 caractères : 5 champs laissés libres à l'utilisateur.
Ils peuvent, selon le paramétrage du modèle de création de CGR (GPMCC), suivre sur les identifiants longs des CGR segments créés depuis l'Application Projets.

   Zones dates : 5 champs laissés libres à l'utilisateur.
Elles peuvent, selon le paramétrage du modèle de création de CGR (GPMCC), suivre sur les dates des CGR segments créés depuis l'Application Projets.

   Zones numériques : 5 champs laissés libres à l'utilisateur.
Ils peuvent, selon le paramétrage du modèle de création de CGR (GPMCC), suivre sur les numériques des CGR segments créés depuis l'Application Projets.

   Zones libellés sur 240 caractères : 2 champs laissés libres à l'utilisateur.
Ils peuvent, selon le paramétrage du modèle de création de CGR (GPMCC), suivre sur les libellés des CGR segments créés depuis l'Application Projets.

   Zone description sur 1000 caractères laissée libre à l'utilisateur.

   Les informations tiers et adresses sont proposées à partir des informations du client principal du projet.
Ils peuvent, selon le paramétrage du modèle de création de CGR (GPMCC), suivre sur les paramètres des CGR segments créés depuis l'Application Projets.

   Il s'agit du tiers auquel la commande est facturée.
Il peut, selon le paramétrage du modèle de création de CGR (GPMCC), suivre sur le tiers des CGR segments créés depuis l'Application Projets.

   Il s'agit de l'adresse de facturation associée au tiers de facturation.

    Il s'agit du tiers auquel le paiement est adressé.
Il peut, selon le paramétrage du modèle de création de CGR (GPMCC), suivre sur le tiers des CGR segments créés depuis l'Application Projets.

   Il s'agit de l'adresse de paiement associée au tiers de paiement.

   Il s'agit du tiers auquel les marchandises sont livrées.
Il peut, selon le paramétrage du modèle de création de CGR (GPMCC), suivre sur le tiers des CGR segments créés depuis l'Application Projets.

   Il s'agit de l'adresse de livraison associée au tiers de livraison.

   Il s'agit du tiers auquel la confirmation de la vente est adressée.
Il peut, selon le paramétrage du modèle de création de CGR (GPMCC), suivre sur le tiers des CGR segments créés depuis l'Application Projets.

    Il s'agit de l'adresse de confirmation associée au tiers de confirmation.

   Proposition par défaut du tiers et de l'adresse associés à l'établissement du projet. Il s'agit donc du tiers demandeur.
Il peut, selon le paramétrage du modèle de création de CGR (GPMCC), suivre sur le tiers des CGR segments créés depuis l'Application Projets.

   Pour le projet sélectionné, ce bouton permet de réaliser le lancement d'un ensemble de traitements et/ou éditions correspondant à des étapes définies pour la classe du projet dans GETCJ.

   Il est possible de réaliser les traitements via une barre d'avancement. Il s'agit d'un récapitulatif interactif des étapes de projets permettant de voir l'état d'avancement du projet et d'exécuter les étapes.
Pour visualiser et utiliser cette barre, il faut que le champ de type "STEPVIEW" figure sur le formulaire de saisie. Si besoin, effectuer une personnalisation pour ajouter ce champ.
Il est également nécessaire de paramétrer les groupes d'étapes des projets (GGETPJ).

   
Génération automatique d'un segment

   Il est possible lors de la création des projets, des phases ou des tâches de créer automatiquement un segment.
Il est créé d'après le modèle de création de CGR (GPMCC) associé à la classe de projets (GPCPR), au type de phase (GPTPH) ou au type de tâche (GPTAC) lorsque la création du segment est définie en automatique. Ce modèle permet de détailler les informations nécessaires pour créer les CGR segment (code, numéro de segment, intitulé, etc.).

   Deux types de création de CGR segment sont possibles :
- La saisie d'un nouveau segment pour le projet, la phase ou la tâche. Il sera automatiquement créé. Dans ce cas, le modèle de création de CGR doit être défini à codification manuelle. On parle alors de génération "semi-automatique" du segment.
- Le code peut être calculé automatiquement suivant les règles définies pour le modèle de création. Dans ce cas, le modèle de création de CGR doit être défini à codification automatique. On parle alors de génération "automatique" du segment.

   Dans le cas d'une génération "automatique" la codification est découpée selon au maximum 6 composantes dont les natures et les positions sont définies pour le modèle :
- constante (valeur alphanumérique qui est toujours identique) ;
- symbole (symbole comme $USER, $ETS, etc.) ;
- entité (préfixe du segment de la phase ou de la tâche égal au segment de l'entité directement supérieure) ;
- compteur numérique (compteur incrémenté de 1 en 1 indépendant du numéro de projet) ;
- équivalence au projet (codification équivalente au numéro de projet).
Cette dernière composante nécessite l'existence du paramétrage pour la classe de la taille entité projet (GPTEP). Elle peut être intéressante dans le cas où les informations du projet doivent apparaître au niveau des segments.

   Exemple :
Codification des segments d'un projet, phases et tâches obtenue par création automatique avec un composant équivalent au projet.

   Le paramétrage dans GPTEP a permis de retrouver au niveau de la codification du segment la classe, le numéro, le sous-numéro du projet, le type et le numéro de phase, le type et le numéro de tâche, et le tout séparé par des ".".

   Outre la codification, les autres champs nécessaires à la création d'un CGR sont paramétrés :
   - intitulé complet, intitulé réduit ;
   - type de CGR ("A" analytique, "B" budgétaire) ;
   - le numéro segment (axe analytique) ;
   - le code confidentiel ;
   - l'état du contrôle budgétaire ;
   - tous les autres paramètres d'un CGR (famille, groupe, ensemble, paramètres de 1 à 20) permettant d'identifier des critères de regroupement ou d'extraction supplémentaires pour une donnée.

   Une fois créé, le CGR segment est lié à l'entité qui l'a générée.
S'il est créé depuis un projet, il est lié au projet : l'établissement, la classe, le numéro et le sous-numéro de projet sont identifiés.
S'il est créé depuis une phase, il est lié à la phase : mêmes informations du projet auxquelles sont ajoutés le type et le numéro de phase.
S'il est créé depuis une tâche, il est lié à la tâche : mêmes informations du projet et de la phase auxquelles sont ajoutés le type et le numéro de tâche.
Cela implique qu'une modification d'une donnée (intitulé, paramètres, etc.) sur un projet ayant servi à la création du segment entraîne également la modification de cette donnée sur le segment.
La modification du CGR segment ou sa suppression au niveau du projet, de la phase ou de la tâche entraîne la mise à l'état inactif de la ligne de données dans la table des CGR et des compositions de CGR.

   Remarque : la génération automatique d'un CGR segment pour une sous-tâche créée par un éclatement (GPMEC, GPWET) suit les règles du paramétrage du modèle d'éclatement (GPECC) lié au modèle de création (GPMCC) de la tâche origine. Le principe de codification reste quasiment identique.

   Le projet, la phase ou la tâche sont générés pour un établissement, mais il peut être nécessaire de gérer des budgets pour ce projet sur d'autres établissements. Pour cela, il est nécessaire que les segments soient générés automatiquement sur les autres établissements concernés. Le paramétrage est défini au niveau de la gestion du multi-établissement des projets (GPMET) pour la classe de projets. Les CGR segment sont créés à l'identique sur tous les établissements paramétrés et sont tous liés à l'entité de projet de l'établissement d'origine.

   Création automatique des phases

   Lorsque la classe de projets est associée à des types de phase dans la gestion des créations automatiques (GPCAU), les phases du projet sont automatiquement créées lors de la validation de la création.

   Création automatique des numériques associés

   S'il existe des règles d'association des numériques (GPRAN) pour la classe de projets, suivant le paramétrage, des numériques associés (GPNAT) au projet sont automatiquement générés lors de la validation.
Ces numériques associés peuvent notamment être utilisés pour renseigner les quantités ou les montants ou encore les montants ou taux des conditions de facturation des lignes de paniers générés depuis les tâches ou pour affecter un montant lors de la génération d'un marché de ventes ou d'achats (TPBMAA, TPBMAV).

   Création automatique des autorisations de saisie des avancements (GPASA)

   Lorsque le paramétrage le permet, occurrence AUTASA du paramètre AUTQPR, des autorisations de saisie des avancements (GPASA) sont créées avec :
- comme utilisateurs : les utilisateurs associés au gestionnaire principal du projet (GUSI) ;
- comme dates de début et de fin de période : les dates de début et de fin théoriques du projet.

   Calcul des périodes des avancements

   S'il existe un type d'avancement (GPTAV) défini pour la classe de projets, les périodes de saisie des avancements sont calculées en fonction de la périodicité et du calendrier du type d'avancement, des dates de début et fin théoriques du projet et de la date de "calcul d'avancement jusqu'au" du projet. Il sera ensuite possible de saisir les pourcentages d'avancement prévus puis réels du projet pour chaque période dans une des gestions de saisie des avancements (GPPAV, GPPAP, GPPAR).

   Confidentialité sur les projets

   Création automatique d'une tâche de planning (GNTAC)

   Lorsqu'il existe une association entre la classe de projets et une classe de tâches de planning (GNACL), une tâche de planning est générée automatiquement suivant les informations du projet.
Les informations transmises sont :
   - la date de début théorique. Elle initialise la date de début théorique et spécifie la date de début au plus tôt de la tâche de planning ;
   - la date de fin théorique. Elle spécifie la date à ne pas dépasser de la tâche de planning ;
   - la durée théorique. Elle initialise la durée théorique et permet également le calcul de la date de fin théorique de la tâche de planning ;
   - l'unité de durée. Elle initialise l'unité de durée de la tâche de planning ;
   - les intitulés long et réduit du projet. Ils spécifient les intitulés long et réduit de la tâche de planning.

   Les dates de début et de fin théoriques du projet permettent de fixer des bornes à la tâche de planning : date de début au plus tôt et date à ne pas dépasser.

   La génération des tâches de planning rend possible la planification d'un projet, l'application de contraintes ou de liens.

   Certaines informations concernant la tâche de planning liée au projet sont visibles via le détail "Complément".

   Le traitement TPQPN permet de générer les tâches de planning depuis un projet si cela n'a pas été fait en interactif.

   
Modification du CGR segment
Lorsque le numéro de segment est modifié sur le projet, les règles de génération automatique suivant le modèle de création de CGR (GPMCC) sont appliquées.

   Modification d'une information ayant influence sur le CGR
Si l'intitulé complet, l'intitulé réduit ou un des 15 paramètres sont modifiés et qu'ils ont été utilisés pour la création automatique d'un CGR segment (GPMCC), la modification est propagée sur ce segment.

   Modification de la date de début ou de la date de fin théorique
Si la date de début ou de fin théorique est modifiée, mise à jour :
- des dates d'autorisation de saisie des avancements (GPASA) ;
- des périodes des avancements (GPPAV), celles-ci sont recalculées ;
- des dates du marché d'achats lié au projet ;
- des dates du marché de ventes lié au projet ;
- des dates au plus tôt et à ne pas dépasser des tâches de planning.

   Modification de la durée théorique ou de son unité
Si la durée théorique d'un projet ou son unité sont modifiées, cela entraîne un recalcul de la date de fin théorique de la tâche de planning, s'il en existe une pour le projet, suivant les contraintes et les liaisons définies dans l'Application Planification.

   Modification de la date de début, de la date de fin ou de la durée réelle
Si la date de début, la date de fin ou la durée réelle d'un projet sont modifiées, via une saisie des temps (GTMPJ) ou une clôture (TPCLO), les dates de début, de fin ou l'unité réelles de la tâche de planning sont modifiées, s'il en existe une.

   Modification de la date de calcul de l'avancement
La date de calcul de l'avancement ne peut pas être antérieure à celle déjà saisie, il est seulement possible de la repousser. La saisie de cette date peut générer des périodes d'avancement à condition que les dates théoriques du projet, de la phase ou de la tâche soient saisies. Il faut également qu'il existe des périodes de planification (GCAP) jusqu'à la date de calcul de l'avancement saisie pour le type de périodicité du type d'avancement (GPTAV) de la classe de projets ou du type de tâche (GPTAC) des tâches du projet.

   Lors de la suppression d'un projet :
- mise à l'état supprimé du CGR segment du projet ;
- suppression des hiérarchies de CGR créées depuis le CGR segment du projet ;
- suppression des CGR supérieurs (GPCSP) ;
- suppression des textes (GPTPR) associés au projet ;
- suppression des numériques associés (GPNAT) ;
- suppression des rubriques associées (GPRUP) ;
- suppression des informations clients/fournisseurs (GPICP)   ;
- suppression des liens créés manuellement (GPLPR) ;
- suppression des gestionnaires associés (GPGPR) ;
- suppression des phases (GPPHP) et des tâches (GPLPP) ;
- suppression de la tâche de planning associée (GNTAC), des hiérarchies de tâches de planning (GNHIE) et des liens entre tâches de planning (GNLIE) si le projet a généré des informations dans l'Application Planification ;
- suppression des autorisations de saisie des avancements (GPASA) ;
- suppression de l'avancement (GPPAV).

   La valeur "O" de ce paramètre autorise la saisie des dates réelles du projet.
Il est conseillé de dupliquer le mnémonique GPPRO et d'activer cette fonctionnalité sur ce nouveau mnémonique.