Les rôles
[les différents acteurs et leurs périmètres][agrandir l'image]
Administrateur
Le rôle Administrateur est défini via le fichier d’import des utilisateurs de l’application.
Il permet l’administration propre à Heures de délégation, qui comprend le paramétrage nécessaire de la plateforme vu dans ce manuel, ainsi que le suivi des heures sur l’ensemble de la population.
L’administrateur a accès à toutes les fonctionnalités de tous les profils, et sur toute la population.
Eléments nécessaires pour un administrateur :
- UUID : Identifiant unique. /!\ Ne pas modifier sur une ligne existante et ne rien mettre sur une nouvelle ligne, le système se charge d’en affecter un nouveau.
- NOM : Obligatoire.
- PRENOM : Obligatoire.
- EMAIL : Obligatoire. Il s’agit également de l’identifiant de connexion (sauf si le client est en SSO).
Règles :
- Pour désactiver un administrateur, il faut supprimer la ligne du fichier.
- Seuls les administrateurs actifs sont exportés, mais les inactifs sont bien entendus conservés en base pour l’historique et les actions précédemment effectuées.
Superviseur
Le rôle de Superviseur est défini via le fichier d’import des utilisateurs de l’application.
Il a accès à la fois à des fonctions de pilotage et à la fois à des fonctions d’administration mais sur les RP de son périmètre uniquement (cf. détail dans "Accès aux fonctionnalités").
Le superviseur a accès à une population de RP déterminée selon plusieurs critères :
- 0 ou n Unité(s) Organisationnelle(s)
- 0 ou n Type(s) de mandat
Il peut donc croiser ou non les critères, ce qui permet une grande souplesse.
Un superviseur peut par exemple être défini sur un périmètre organisationnel uniquement (ex. UO x), ou au contraire sur un périmètre transverse (ex. tous les mandats de type Délégué syndical), ou encore croiser les 2 (ex. tous les mandats de type CSE, sur l’UO x uniquement).
Eléments nécessaires pour un superviseur :
UUID : Identifiant unique.
👆 Attention : Ne pas modifier sur une ligne existante et ne rien mettre sur une nouvelle ligne, le système se charge d’en affecter un nouveau.
- NOM : Obligatoire.
- PRENOM : Obligatoire.
- EMAIL : Obligatoire. Il s’agit également de l’identifiant de connexion (sauf si le client est en SSO).
- UO x : Optionnel.
o Choisir 1 UO depuis la liste proposée (import configuration préalable pour avoir la liste).
o Répéter la colonne autant que nécessaire.
o Laisser la cellule vide pour avoir toutes les UO dans le périmètre.
- TYPE DE MANDAT x : Optionnel.
o Choisir 1 type de mandat depuis la liste proposée (import configuration préalable pour avoir la liste).
o Répéter la colonne autant que nécessaire.
o Laisser la cellule vide pour avoir tous les types de mandat dans le périmètre.
Pour avoir un superviseur sur le périmètre complet mais sans les fonctions d’administration de la plateforme, il suffit de ne pas renseigner les blocs UO et Type de mandat.
Règles :
- 1 seule ligne par superviseur.
- Pour désactiver un superviseur, il faut supprimer la ligne du fichier.
- Seuls les superviseurs actifs sont exportés, mais les inactifs sont bien entendus conservés en base pour l’historique et les actions précédemment effectuées.
Responsable
Ce que nous nommons « Responsable » dans l’application est en réalité toute personne qui doit être informée de la pose d’un bon de délégation d’un RP, d’où l’utilisation d’un terme générique.
Il peut y en avoir 1 ou plusieurs par représentant.
En général il s’agit au minimum du manager hiérarchique du représentant, pour des questions d’organisation opérationnelle, mais pourquoi pas aussi d’un directeur de commission, d’un RRS etc.
Ce(s) responsable(s) est ou sont défini(s) manuellement ou par import de fichier des utilisateurs, rattaché(s) directement à un RP.
Le responsable n’a pas de rôle dans l’application, ce qui signifie qu’il ne peut pas se connecter. Il reçoit une notification par e-mail à chaque fois qu’un RP auquel il est rattaché pose un bon de délégation, le modifie, ou le supprime.
Représentant du personnel (RP) et affectation des mandats
Un représentant du personnel peut être créé, modifié, ou désactivé :
- Par l’interface de façon unitaire par l’administrateur ou un superviseur sur son périmètre uniquement.
- Via le fichier d’import des utilisateurs de l’application (administrateur uniquement).
On va aussi pouvoir attacher au RP tous les éléments dont il aura besoin pour démarrer :
- Le(s) responsable(s) : vu dans la section précédente.
- Le(s) mandat(s), avec ou sans « Régularisation »
Mandats, compteurs et régularisations
L’affectation de mandat est quant à elle essentielle : en rattachant le RP à 1 ou plusieurs « types de mandat » (détenant les caractéristiques), et en démarrant chacun à une date (souvent la même mais pas forcément), le RP aura alors ses propres « mandats », avec chacun leur propre compteur.
Chaque compteur est calculé dynamiquement en comptant toutes les opérations (crédits/débits) depuis le début du mandat, et ce jusqu’à la fin du mandat.
Par conséquent, lors du projet, il peut être nécessaire d’effectuer des « régularisations » pour compenser (débiter) le crédit reporté depuis le début du mandat à la date du go live. C’est au choix du client et selon ses accords. Si les mandats sont démarrés à date du go live, il n’est pas nécessaire de faire de régularisations. A l’inverse, si les mandats ont des dates de début réelles, il faudra alors passer des régularisations, en théorie sur tous les mandats pour que ce soit plus « propre » sur la vue mensuelle du RP, mais dans la pratique, elles ne sont essentielles que lorsqu’il y a du report cumulé.
Exemples :
1. Sur un mandat avec report de 10h crédité par mois qui a démarré en février et un go live en mai : sans régularisation le compteur affiche 40h. Pour qu’il affiche uniquement les 10h du mois de mai, il faut faire une régularisation de février à avril de 30h, le système se charge de répartir les heures sur la période.
2. Sur un mandat sans report de 10h crédité par mois qui a démarré en février et un go live en mai : sans régularisation le compteur affiche 10h (puisqu’en fin de mois les heures non utilisées sont perdues). En passant une régularisation de février à avril de 30h, il affichera également 10h. La différence sera juste notable sur la vue mensuelle du RP.
Eléments nécessaires dans le fichier :
- UUID : Identifiant unique. /!\ Ne pas modifier sur une ligne existante et ne rien mettre sur une nouvelle ligne, le système se charge d’en affecter un nouveau.
- GENRE : Optionnel. « Femme » ou « Homme ».
- NOM : Obligatoire.
- PRENOM : Obligatoire.
- EMAIL : Obligatoire. Il s’agit également de l’identifiant de connexion (sauf si le client est en SSO).
- MATRICULE : Obligatoire.
- ACCES : Obligatoire. « Oui » ou « Non ».
- UO : Obligatoire. Choisir 1 UO depuis la liste proposée (import configuration préalable pour avoir la liste).
RESPONSABLE A NOTIFIER x : Optionnel.
- NOM : Obligatoire sur le bloc.
- PRENOM : Obligatoire sur le bloc.
- EMAIL : Obligatoire sur le bloc.
- Renseigner l’ensemble du bloc ou rien.
- Répéter le bloc autant que nécessaire.
- Peut être supprimé en enlevant toutes les infos du mandat.
MANDAT x : Optionnel.
- UUID : Identifiant unique du mandat. /!\ Ne pas modifier sur une ligne existante et ne rien mettre pour un nouveau mandat.
- MANDAT : Obligatoire sur le bloc. Choisir 1 type de mandat depuis la liste proposée (import configuration préalable pour avoir la liste).
- DEBUT MANDAT : Obligatoire sur le bloc. Format jj/mm/aaaa.
- FIN MANDAT : Optionnel. Format jj/mm/aaaa. Si non renseigné, le mandat sera crédité le cas échéant jusqu’à nouvel ordre.
- DEBUT REGULARISATION : Début de la période sur laquelle la régularisation doit être appliquée (en général début du mandat). Format mois année ou 01/mm/aaaa.
- FIN REGULARISATION : Fin de la période sur laquelle la régularisation doit être appliquée (en général, mois précédant le projet). Format mois année ou 01/mm/aaaa.
- NOMBRE D’HEURES : Nombre d'heures à régulariser sur l'ensemble de la période.
- Répéter le bloc autant que nécessaire.
- Peut être supprimé seulement si non grisé (dans ce cas, supprimer toutes les infos du mandat).
Règles valables pour l’ensemble de l’onglet RP :
- 1 seule ligne par RP.
- Pour désactiver un RP, il ne faut pas supprimer la ligne du fichier. Il faut mettre à « Non » la colonne « Accès ».
👆 A noter : la désactivation d’un RP supprime ses droits d’accès au module HDD, il ne peut donc plus se connecter. En revanche, le système ne met pas fin automatiquement à ses mandats (il continue donc de recevoir du crédit d’heures). Cela n’a pas d’impact en soi mais il est plus propre de mettre fin à ses mandats (possible uniquement individuellement et manuellement aujourd’hui). Cela fera peut-être l’objet d’une évolution dans le futur.
- Un RP peut être réactivé en remettant la colonne « Accès » à Oui.
- Les cellules grisées ne sont pas modifiables par import, mais uniquement individuellement et manuellement. Cela concerne les cellules d’identité du RP, et les cellules des mandats dès lors qu’il existe un bon ou une régularisation sur le mandat.