Structure des projets :
Cegid XRP Ultimate | I3 Actualisé le 06/10/2022 |
|||
| Projets | |||
| GPPRO - Projets | |||
| Cette transaction permet de saisir ou de consulter les en-têtes de projets. Structure des projets : |
| Données |
| Projet |
| L'identifiant d'un projet pour un établissement est composé de la classe (GPCPR), du numéro et du sous-numéro. |
| Classe de projet |
| 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). |
| Sous-numéro |
| 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. |
| Mnémonique |
| Références |
| 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. |
| Interne |
| 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. |
| Externe |
| 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). |
| Gestionnaire |
| 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. |
| Segment |
| 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. |
| Dates |
| Théoriques |
| 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. |
| Réelles |
| 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. |
| Date initiale |
| 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. |
| Date de projet |
| 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. |
| Intitulé complet |
| Intitulé réduit |
| Etape |
| 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 |
| 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. |
| Etablissement |
| Numéro interne |
| 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. |
| Autres paramètres |
| Catégorie |
| 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. |
| Paramètres |
| 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). |
| Informations complémentaires |
| Ventes |
| Famille clients/Client principal |
| Numéro |
| 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). |
| Marché |
| 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. |
| Achats |
| Famille fournisseurs/Fournisseur principal |
| Numéro |
| 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). |
| Marché |
| 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. |
| Maintenance |
| 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). |
| Famille équipement |
| 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. |
| Bâtiment |
| 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. |
| N° d'intervention |
| 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). |
| Planning |
| 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. |
| Calcul de l'avancement jusqu'au |
| 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. |
| Comptabilisation |
| Mode de change, date de validité et cours de la devise principale du projet. |
| Changement de gestionnaire |
| Assistant de changement de gestionnaire, au niveau du projet, mais aussi au niveau des phases et des tâches. |
| Paramètres standard |
| Compléments |
| Identifiants |
| 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. |
| Identifiants longs |
| 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. |
| Dates |
| 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. |
| Numériques |
| 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. |
| Libellés |
| 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. |
| Description |
| Zone description sur 1000 caractères laissée libre à l'utilisateur. |
| Tiers et adresses client principal |
| 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. |
| Tiers de facturation |
| 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. |
| Adresse de facturation |
| Il s'agit de l'adresse de facturation associée au tiers de facturation. |
| Tiers de paiement |
| 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. |
| Adresse de paiement |
| Il s'agit de l'adresse de paiement associée au tiers de paiement. |
| Tiers de livraison |
| 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. |
| Adresse de livraison |
| Il s'agit de l'adresse de livraison associée au tiers de livraison. |
| Tiers de confirmation |
| 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. |
| Adresse de confirmation |
| Il s'agit de l'adresse de confirmation associée au tiers de confirmation. |
| Tiers à facturer |
| 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. |
| Boutons poussoirs |
| Traitements |
| 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). |
| Modifications périphériques |
| A la création d'un projet |
| 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. |
| En modification d'un projet |
| 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. |
| En suppression d'un 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). |
| Paramètres associés au mnémonique (voir aussi : Principe de l'association) |
| DAT |
| 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. |
| PCG |
| Transactions associées |
| GPPHP - Phases |
| GPLPP - Tâches |
| GPGPR - Gestionnaires de projets |
| GPCSP - CGR supérieurs des projets |
| GCGR - Centres de gestion et de responsabilité |
| GPLPR - Liens de projets |
| GPTPR - Textes de projets |
| GEDEJ - Enchaînements dynamiques |
| CHEPR - Historique des étapes de projets |
| GPPAV - Pourcentages d'avancements |
| GPPAP - Avancement prévisionnel |
| GPPAR - Avancement réel |
| GPNAT - Numériques associés |
| GPRUP - Rubriques de projets |
| TPBMAA - Génération des marchés d'achats |
| TPBMAV - Génération des marchés de ventes |
| TPBDI - Génération des demandes d'intervention |
| DPPHP - Duplication des phases et tâches associées |
| GPICP - Informations clients/fournisseurs du projet |
| GTMPJ - Saisie des temps de projets |
| GNLIE - Liens des tâches de planning |
| GNTAC - Tâches de planning |
| GNUTR - Utilisation des ressources |
| TPREP - Retour à une étape d'un projet |
| GPPLNG - Planification des projets |
| GPUTR - Utilisation des ressources projets |
| GPASA - Autorisation de saisie des avancements |
| CPHNA - Historique des numériques associés |
| TPBGRP - Génér. des utilisations de ressources de planning |
| TPBNAT - Mise à jour des numériques associés |
| Paramètres |
| CATQPPRO |
| CHMSGHBT |
| AUTQPR - PRODAV |
| AUTQPR - REFUNI |
| AUTODE - ARRDVC |
| Messages |
| QPPRO010 - Suppression du projet impossible : vous n'avez pas accès à toutes ses phases |
| QPPRO011 - Suppression impossible : de l'avancement réel a été saisi pour ce projet |
| QPPRO050 - Le numéro de projet doit être compris entre 0 et 9999999 |
| QPPRO051 - Le sous-numéro de projet doit être compris entre 0 et 999 |
| QPPRO052 - Classe de projets manuelle, veuillez saisir le numéro de projet |
| QPPRO053 - La classe de projets oblige la saisie d'une référence interne |
| QPPRO054 - La classe de projets oblige la saisie d'une référence externe |
| QPPRO055 - La classe de projets oblige la saisie d'un segment |
| QPPRO057 - La classe de projets interdit la saisie d'un segment |
| QPPRO058 - Le segment est déjà utilisé dans un autre projet |
| QPPRO059 - Le segment est déjà utilisé dans une phase |
| QPPRO060 - Le segment est déjà utilisé dans une tâche |
| QPPRO061 - La clé du segment ne doit pas être saisie : le segment n'est pas en création automatique ou le type d'affectation de la clé du modèle de segment ne vaut pas "P" |
| QPPRO062 - La fourchette de dates théoriques est incorrecte |
| QPPRO063 - La durée théorique du projet doit être supérieure à 0 |
| QPPRO064 - Si la durée théorique est renseignée, l'unité de durée doit l'être aussi |
| QPPRO065 - La fourchette de dates réelles est incorrecte |
| QPPRO066 - La durée réelle du projet doit être supérieure à 0 |
| QPPRO067 - Si la durée réelle est renseignée, l'unité de durée doit l'être aussi |
| QPPRO068 - La classe de projets oblige la saisie de la date initiale |
| QPPRO069 - La classe de projets interdit la modification de la date initiale |
| QPPRO070 - La classe de projets oblige la saisie de la date de projet |
| QPPRO071 - La classe de projets interdit la modification de la date de projet |
| QPPRO072 - Modification de l'unité de durée interdite |
| QPPRO073 - Création d'un projet impossible à cette étape |
| QPPRO074 - Modification d'un projet impossible à cette étape |
| QPPRO075 - Suppression d'un projet impossible à cette étape |
| QPPRO076 - Le segment a un numéro de segment différent de celui du modèle de CGR |
| QPPRO077 - Création du segment ($1) impossible : Le segment du modèle ($2) doit être renseigné |
| QPPRO078 - Création du segment ($1) impossible : Le segment du modèle ($2) ne doit pas être renseigné |
| QPPRO079 - La taille du segment à générer ($1) est incorrecte par rapport à la définition du segment ($2) de la clé analytique |
| QPPRO080 - Le gestionnaire à modifier doit être rattaché à un projet |
| QPPRO081 - Le gestionnaire à modifier ne correspond pas au projet |
| QPPRO082 - Le segment proposé pour le projet ($1) existe déjà |
| QPPRO083 - La définition de la classe interdit la modification du segment |
| QPPRO084 - Le segment est déjà utilisé dans un éclatement de tâche |
| QPPRO085 - Cette référence interne est déjà utilisée par un autre projet |
| QPPRO086 - La date d'avancement ne peut pas être inférieure à la date précédemment saisie |
| QPPRO087 - Il existe des dates théoriques dans les phases qui ne sont pas comprises dans cette période |
| QPPRO088 - Il existe des dates théoriques dans les tâches qui ne sont pas comprises dans cette période |
| QPPRO089 - Il existe des dates réelles dans les phases qui ne sont pas comprises dans cette période |
| QPPRO090 - Il existe des dates réelles dans les tâches qui ne sont pas comprises dans cette période |
| QPPRO091 - La saisie des dates réelles du projet est interdite |
| QPPRO097 - Modification du mode de change interdite |
| QPPRO098 - Les informations reporting ne doivent pas être renseignées |
| QPPRO099 - Modification du mode de change de reporting interdite |
| QPPRO103 - La famille de clients et le marché de ventes ne doivent pas être renseignés |
| QPPRO104 - La famille de fournisseurs et le marché d'achats ne doivent pas être renseignés |
| QPPRO105 - La famille de clients ne doit pas être renseignée |
| QPPRO106 - La famille de fournisseurs ne doit pas être renseignée |
| QPPRO115 - La famille d'équipements ne doit pas être renseignée |
| QPPRO116 - La demande d'intervention ne doit pas être renseignée |
| QPPRO123 - La demande d'intervention doit être renseignée |
| QPPRO124 - La demande d'intervention ne doit pas être renseignée |
| QPPRO125 - Les 2 dates de la période théorique doivent être saisies |
| QPPRO126 - Modification d'un marché de ventes généré interdite |
| QPPRO127 - Modification d'un marché d'achats généré interdite |
| QPPRO128 - Modification d'une demande d'intervention générée interdite |
| QPPRO129 - Modification de la clé confidentielle du CGR interdite |
| QPPRO130 - Modification d'un établissement de marché de ventes généré interdite |
| QPPRO131 - Modification d'un établissement de marché d'achats généré interdite |
| QPPRO132 - Modification d'un établissement de demande d'intervention générée interdite |
| QPPRO139 - Vous n'avez pas les privilèges suffisants pour mettre à jour le gestionnaire (transaction : $1) |
| QPPRO158 - Clôture du projet impossible : l'étape ($1) de la demande d'intervention rattachée au projet est inférieure à l'étape minimale ($2) nécessaire pour clôturer |
| QPPRO160 - La date de début réelle du projet n'est pas renseignée |
| QPPRO161 - Clôture du projet impossible : toutes ses phases ne sont pas clôturées |
| QPPRO162 - Clôture du projet impossible : l'étape ($1) du marché d'achats ($2) est inférieure à l'étape minimale ($3) nécessaire pour clôturer |
| QPPRO166 - Edition partielle du projet : l'utilisateur n'a pas les droits suffisants pour traiter l'intégralité des entités |
| QPPRO167 - Duplication du projet impossible : l'utilisateur n'a pas les droits suffisants pour traiter l'intégralité des entités |
| QPPRO168 - Changement du gestionnaire du projet impossible : l'utilisateur n'a pas les droits suffisants pour traiter l'intégralité des entités |
| QPPRO169 - La demande d'intervention n'appartient pas à l'établissement saisi |
| QPPRO170 - Le numéro de projet doit être compris dans la fourchette définie au niveau de la classe de projets |