Vérifier les périodes de relevé
Vérifie que les périodes soumises et approuvées donnent toujours le résultat avec lequel elles ont été soldées, et liste chaque écart dans un rapport à télécharger.
Vue d’ensemble
Lorsqu’une période est soumise, mTIME fige ses résultats sur le relevé : temps travaillé et temps attendu, totaux des primes, et pour chaque compte de temps le solde initial, les mouvements et le solde final. Rien ne les recalcule ensuite.
Cette tâche recalcule ces périodes et compare le résultat avec ce qui a été figé. Utilisez-la pour vérifier que la configuration et les données se comportent comme le disent les périodes enregistrées, par exemple :
- Après une migration depuis mTIME 5. Chaque période migrée porte ses chiffres mTIME 5, et la tâche montre où mTIME X aurait calculé autre chose.
- Après une modification des politiques ou des conditions d’emploi. Une modification qui s’applique rétroactivement apparaît dans les périodes qu’elle touche.
La tâche ne fait que lire. Elle ne modifie jamais un relevé, un solde, un enregistrement ou une ligne de paie : vous pouvez donc la lancer sans risque sur un espace de travail en production.
Qui peut la lancer
Seul le propriétaire de l’espace de travail peut lancer cette tâche et télécharger son rapport. Le rapport contient les soldes et les versements de tous les employés, ce qu’aucune permission ne couvre à elle seule : un administrateur sans le rôle de propriétaire ne voit donc pas la tâche.
Fonctionnement
La tâche vérifie chaque période soumise ou approuvée qui chevauche les dates choisies. Les périodes encore ouvertes n’ont encore rien de figé et sont ignorées.
Pour chaque période, la tâche :
- Part des soldes initiaux enregistrés. Chaque période est vérifiée séparément : un écart apparaît dans la période qui le cause, et non dans toutes les suivantes.
- Recalcule les jours. Le temps de travail, les politiques de primes et les compteurs sont recalculés à partir des enregistrements, des pointages et des absences de la période.
- Recalcule les soldes. Les absences sont consommées, les acquisitions des politiques d’absence sont attribuées, les soldes d’absence qui arrivent à expiration dans la période expirent, et les politiques de solde (crédits, plafonds, versements) s’exécutent, comme lors de la soumission de la période.
- Compare le résultat avec les chiffres figés, exactement, à la minute près.
Les politiques sont appliquées telles qu’elles sont enregistrées aujourd’hui, dans la version valable pour la période. Une modification qui ne s’applique qu’à partir d’aujourd’hui n’affecte pas les périodes passées ; une modification rétroactive, si. Pour chaque politique, le rapport indique si elle a été modifiée après le solde de la période, ce qui permet de distinguer un changement de configuration d’une erreur.
Ce qui est comparé
| Niveau | Comparé |
|---|---|
| Comptes de temps | Pour chaque compte : solde initial, acquisitions, consommation, expiration, versement, ajustements, transferts et solde final |
| Totaux de la période | Temps travaillé, temps attendu et leur différence, ainsi que le total de chaque activité de prime |
| Jours | Temps travaillé par jour, et chaque activité enregistrée automatiquement par jour |
La tâche vérifie aussi que le solde initial de chaque période correspond au solde final de la période précédente. Un écart à ce niveau désigne les données enregistrées plutôt qu’une règle.
Ce qui n’est pas vérifié
Le rapport indique ce qu’il n’a pas pu vérifier, pour qu’un manque ne soit jamais pris pour une concordance :
- Non comparé : la période enregistrée ne contient pas le chiffre. Par exemple, une période migrée qui ne porte que les soldes initial et final n’est comparée que sur ces deux valeurs.
- Non simulé : la tâche ne peut pas recalculer le chiffre de façon fiable. C’est le cas des soldes d’absence qui expirent dans des périodes antérieures au début de l’historique du compte dans mTIME X (avant la date de migration), et lorsqu’un versement ou une correction ultérieure rend le solde antérieur impossible à reconstituer. C’est aussi le cas d’un jour dont les enregistrements n’ont pas pu être évalués.
Lancer la tâche
- Allez dans .
- Cliquez sur Exécuter la tâche et choisissez verify-statement-periods.
- Indiquez les dates et, si vous le souhaitez, les employés à vérifier, puis lancez-la.
Paramètres
| Paramètre | Par défaut | Description |
|---|---|---|
| From | Le 1er janvier de l’année de la date d’exécution | Premier jour de la fenêtre. Chaque période soumise ou approuvée qui chevauche la fenêtre est vérifiée |
| To | La date d’exécution | Dernier jour de la fenêtre |
| Employee IDs | Tout le monde | Identifiants d’employés séparés par des virgules, pour vérifier rapidement quelques employés |
La tâche ne s’exécute pas d’elle-même ; elle ne s’exécute que lorsque vous la lancez. Sur un grand espace de travail, une année complète peut prendre du temps : commencez par quelques employés pour vérifier une correction.
Le rapport
Une fois l’exécution terminée, ouvrez-la dans et cliquez sur Télécharger le rapport . Vous obtenez un fichier zip contenant deux fichiers :
| Fichier | Contenu |
|---|---|
summary.md | Une vue d’ensemble lisible : combien de périodes ont été vérifiées, combien présentent des écarts, les écarts regroupés par type avec des exemples, et ce qui n’a pas été vérifié |
report.ndjson | Chaque période vérifiée et chaque écart, un par ligne. Chaque écart indique l’employé, la période, le compte ou le jour, le chiffre, la valeur enregistrée, la valeur recalculée et la politique à l’origine. Une période avec des écarts porte aussi ses jours et les politiques qui s’appliquaient |
report.ndjson contient un objet JSON par ligne : il peut être filtré avec des outils standard ou confié à un assistant IA pour analyse.
Chaque téléchargement est consigné dans le journal de sécurité.
Les rapports sont conservés 30 jours. Ensuite, la tâche nocturne verify-statement-periods-cleanup supprime le fichier. L’exécution elle-même reste dans la liste avec ses totaux, mais ne peut plus être téléchargée.
Résultats de la tâche
| Mesure | Description |
|---|---|
from, to | La fenêtre vérifiée |
employees | Employés ayant au moins une période vérifiée |
periods | Périodes vérifiées |
deviating_periods | Périodes avec au moins un écart |
deviations | Écarts trouvés |
deviations_by_kind | Écarts par type : movement, summary, allowance, day, chain |
error_periods | Périodes qui n’ont pas pu être recalculées (l’erreur figure dans le rapport) |
failed_employees | Employés dont les périodes n’ont pas pu être chargées du tout |
not_compared, not_simulated | Ce qui n’a pas pu être vérifié, et dans combien de périodes |
Dépannage
| Problème | Solution |
|---|---|
| La tâche n’apparaît pas dans la liste | Seul le propriétaire de l’espace de travail la voit |
| De nombreux écarts sur le même compte et le même champ | Vérifiez si la politique à l’origine a été modifiée après le solde des périodes (changed_since_period dans le rapport). Sinon, l’écart mérite d’être examiné |
| Un écart dans chaque période d’un compte migré | Regardez d’abord la vérification des soldes initiaux : un écart entre le solde initial d’une période et le solde final de la précédente désigne les données migrées |
| Les expirations sont signalées comme non simulées | Normal pour les périodes antérieures au début de l’historique du compte dans mTIME X, et pour les comptes ayant un versement ou une correction ultérieure |
| Le bouton de téléchargement est absent | Le rapport a plus de 30 jours et a été supprimé. Relancez la tâche |