Rappel de relevé de feuille de temps

Notifie les employés lorsqu’un relevé de feuille de temps atteint son échéance de soumission, puis continue de les relancer — uniquement leurs jours travaillés — tant qu’il reste en retard.

Fonctionnement

La tâche parcourt chaque relevé en attente, prêt ou en retard de l’espace de travail et le fait avancer d’une étape dans son cycle de vie :

1. En attente → Prêt — lorsque la date du jour est égale ou postérieure au dernier jour ouvré de la période, le relevé est marqué prêt et l’employé est notifié que l’échéance est arrivée. Ce seuil suit le calendrier propre à l’employé : une absence approuvée en journées entières en fin de période avance donc l’échéance — l’employé est prévenu avant son départ, et non pendant son absence
2. Prêt → En retard — le jour calendaire suivant la fin de la période, quel que soit le calendrier de l’employé. Une absence juste après la fin de la période ne repousse pas ce passage : l’entrée « soumission manquante » du manager en dépend et doit apparaître un jour prévisible
3. En retard → relancé chaque jour travaillé — tant que le relevé reste en retard, le rappel de l’employé remonte en haut de ses notifications et un e-mail est envoyé chacun de ses jours travaillés. Week-ends, jours fériés et absences approuvées en journées entières sont ignorés, pour que personne ne soit relancé pendant son absence. Le premier rappel utilise la formulation générale « votre feuille de temps est en retard » ; tous les suivants nomment le manager qui l’attend

Les rappels s’arrêtent dès que l’employé soumet : le rappel récurrent est retiré et l’entrée du manager devient une approbation ordinaire.

Une absence en cours sans date de fin — une période de maladie ouverte, par exemple — ne déplace pas l’échéance. Une telle absence n’est connue que jusqu’à aujourd’hui : les jours suivants restent des jours travaillés et l’échéance reste au véritable dernier jour ouvré de la période.

La tâche utilise « >= » plutôt que « == » sur chaque seuil, ainsi un relevé qui aurait raté son jour exact (panne, période antérieure à la fonctionnalité) rattrape son retard à l’exécution suivante. Les événements ont des IDs déterministes, donc les relances ne produisent pas de doublons.

Exemple : absence à cheval sur la fin de période

Une période mensuelle du 1er au 31 août, avec une absence approuvée du 24 août au 7 septembre :

Quand elle s’exécute

La tâche s’exécute automatiquement et ne se déclenche que lorsqu’il existe au moins un relevé en attente, prêt ou en retard pour l’espace de travail.

Paramètres

Cette tâche n’a pas de paramètres.

Résultats de la tâche

Qui est notifié

• L’employé reçoit la notification d’échéance quand la période passe à « prêt », puis un rappel de retard par jour travaillé jusqu’à la soumission. Il n’est jamais relancé un jour non travaillé.
• Le manager voit la soumission manquante dans Approbations dès le lendemain de la fin de période, ainsi que dans son Récapitulatif manager quotidien. Cela ne dépend pas du calendrier des personnes concernées : un manager verra (et recevra par e-mail) une feuille de temps manquante pour un employé encore en congé, et continuera de la voir jusqu’à son retour et sa soumission.
• Un manager absent devrait mettre en place une délégation d’approbation : son récapitulatif est retenu tant que la délégation est active, ses délégués le reçoivent à sa place, et un récapitulatif de rattrapage lui parvient à son premier jour travaillé de retour.

Les événements de cycle de vie portent également le manager direct de l’employé comme cible — c’est ainsi que la boîte de réception du manager se remplit lors d’une reconstruction.

Dépannage