Cycle de vie d’un shift — du brouillon à l’approbation#
Pour : Manager | Administrateur Il te faut : rien.
Un shift passe par plusieurs statuts sur le chemin qui va de « premier croquis sur le calendrier » à « approuvé par un manager ». Cet article parcourt chaque statut, ce qui déclenche une transition et ce qui se verrouille en chemin. La paie s’exécute sur les entrées de temps approuvées — le paiement lui-même n’est pas un statut que le planning suit.
Statuts d’un shift#
Un shift se trouve dans l’un de trois statuts, affiché sous forme de badge sur chaque bloc de shift et chaque ligne de liste.
Brouillon — tout juste créé. Visible par les planificateurs et les managers ; pas visible par les collaborateurs en shifts. Libre d’être modifié, déplacé, redimensionné et supprimé.
Publié — diffusé à l’équipe. Les collaborateurs le voient sur leur planning et dans les notifications. Toujours modifiable par les managers, mais les modifications et suppressions sont contraintes par l’état en aval (voir « Verrous », ci-dessous).
Annulé — le shift n’aura pas lieu. Il reste au calendrier à titre de trace, pour que les rapports puissent en tenir compte.
Les brouillons sont publiés en masse depuis l’horizon de publication. Dépublier ramène un shift publié au brouillon tant qu’il n’est encore que partagé — une fois qu’un collaborateur a timbré son arrivée, que le shift a commencé ou que ses heures sont approuvées, la dépublication est bloquée et tu annules le shift à la place.
Les événements généraux se publient de la même façon. Une réunion d’entreprise, une journée de formation ou une fête est un brouillon jusqu’à ce que tu la publies, et ce n’est qu’alors qu’elle apparaît sur le planning de l’équipe. Mets-la au brouillon, peaufine les détails, publie quand c’est confirmé — et l’encadré de RSVP (“J’y serai” / “Peut-être”) apparaît pour les personnes concernées.
Ce que porte une attribution#
Une attribution (une personne × un shift) n’a pas de statut brouillon/publié propre — sa visibilité suit simplement celle du shift. Ce qu’elle porte en revanche, ce sont deux réponses indépendantes :
Acceptation — si ton entreprise active l’acceptation de shift, c’est la réponse du collaborateur à un shift publié : “En attente”, “Accepté” ou “Refusé”. Une attribution refusée sort des décomptes de couverture. C’est facultatif, et désactivé par défaut.
Heures travaillées — le statut du rapport d’heures une fois le shift terminé : “Publié” → “Confirmé” → “Approuvé” (traité juste après).
Publier un shift ne bascule pas un statut d’attribution distinct — cela rend simplement le shift, et toutes les personnes qui y figurent, visibles pour l’équipe. Une attribution verrouillée (dont les heures sont approuvées) empêche tout le shift d’être dépublié ou modifié.
Les statuts d’entrée de temps vivent sur l’attribution#
Une fois qu’un shift publié commence, son attribution devient le foyer des heures de timbrage arrivée / départ. Le cycle de vie :
Publié — aucune heure travaillée confirmée pour l’instant.
Confirmé — les heures ont été enregistrées et validées comme correctes (timbrage arrivée/départ, ou report depuis le planning). La confirmation déclenche les acquisitions d’absence et de bonification en temps le cas échéant. Selon le mode de ton entreprise, c’est l’employé qui confirme d’abord ses propres heures, ou un manager — voir Comment fonctionnent la confirmation et l’approbation.
Approuvé — un manager a validé. L’approbation verrouille aussi le shift sous-jacent.
Deux flèches inverses annulent chaque étape. Annuler la confirmation efface les données de timbrage et contre-passe les acquisitions d’absence / de bonification en temps ; retirer l’approbation efface l’horodatage d’audit et permet de modifier à nouveau l’entrée. Voir Rapport d’heures.
Cycle de vie d’une demande d’absence#
Les demandes d’absence ont leur propre machine à états, reliée au calendrier via un bloc d’événement créé automatiquement.
En attente — créée par le collaborateur (ou par un manager en son nom). En attente d’examen.
Confirmée — approuvée. Déduit les heures du solde d’absence et engendre l’événement de calendrier.
Refusée — rejetée à l’examen. L’événement de calendrier est retiré s’il avait été créé automatiquement.
Retirée — était confirmée, puis annulée. Contre-passe la transaction de solde d’absence et retire l’événement de calendrier.
Les demandes en attente et refusées peuvent être supprimées ; les confirmées et les retirées restent pour l’audit. Voir Demandes d’absence.
L’approbation verrouille le shift#
L’approbation est le seul verrou. Quand un manager approuve une entrée de temps, le shift sous-jacent, son attribution et l’entrée elle-même ne peuvent plus être modifiés, supprimés, ni voir leur confirmation annulée — Shiftavo affiche une bannière “verrouillé” (indiquant qui a approuvé et quand) et refuse la modification. Voir Pourquoi un shift ne peut pas être modifié ou supprimé.
Pour lever le verrou, retire l’approbation de l’entrée de temps. Il n’y a pas de période à clôturer ou à rouvrir.
Série de shifts récurrents#
Un shift récurrent est une règle parent plus des shifts enfants générés. Modifier ou supprimer un enfant ouvre un sélecteur de portée :
Celle-ci — n’affecte que cette occurrence ; la règle parent demeure.
Suivantes — scinde la série à cette date.
Toutes — régénère toute la série à partir de la nouvelle règle parent (préserve les exceptions par occurrence).
Voir Comment modifier un shift récurrent et Comment supprimer un shift récurrent.
Quand quelque chose semble verrouillé#
Si un enregistrement ou une suppression est refusé, la cause est presque toujours l’une de celles-ci :
L’entrée de temps sous-jacente a été approuvée → retire d’abord l’approbation.
Le shift est annulé et tu essaies d’y timbrer.