Calcul des Jours Ouvrables dans le Logiciel de Traitement des Demandes

Calcul des délais en jours ouvrables pour les systèmes de traitement de demandes

Les systèmes de traitement de demandes nécessitent de suivre les jours ouvrables plutôt que les jours calendaires pour des calculs de délais précis. Le décompte commence le jour de la publication pendant les heures de bureau, ou le jour ouvrable suivant si la publication a lieu en dehors des horaires. Le calendrier est automatiquement chargé depuis un service externe au démarrage et vérifié quotidiennement pour les données de l'année en cours et de l'année suivante. Sans calendrier, le système revient aux jours calendaires.

L'enregistrement se produit instantanément à la publication, sans attendre un jour ouvrable. Par exemple : une publication à 23h00 un jour ouvrable décale le début au jour ouvrable suivant ; une publication à 6h00 le même jour reste le jour en cours si l'horaire commence plus tard.

Règles d'affichage du compteur

Le compteur indique le nombre de jours ouvrables complets écoulés. Quel que soit l'heure de publication, le jour de début du délai, il affiche 0/N.

• Jour de publication pendant les heures de bureau : 0/N jusqu'à 00h00 le lendemain.
• Publication en dehors des horaires : 0/N jusqu'à 00h00 du premier jour ouvrable.

Le compteur s'incrémente à 00h00 après qu'une journée ouvrable complète s'est terminée. Un délai est considéré comme dépassé lorsque la valeur est ≥ N (par exemple, 5/5).

Alternatives rejetées lors de la discussion

• Compteur commençant à 1/N dès la publication — complique la perception des jours complets.
• Incrémentation à la fin de la journée de travail — ignore les retards des employés.
• Marquage comme en retard à la fin de la journée de travail — peu intuitif pour 17h59 vs 18h01.

Exemples de calcul

Exemple 1 : Publication le 1er janvier (un jour férié), premier jour ouvrable le 12 janvier, délai le 16 janvier (5 jours). Traitement le 13 janvier — compteur 1/5 (jour complet : seulement le 12 janvier).

Exemple 2 : 2 jours pour le traitement, publication un jour ouvrable à 9h00 (lundi). Lundi : 0/2 ; mardi : 1/2 ; minuit mardi : 2/2 (dépassé).

Exemple 3 : Même tâche, publication à 20h00 lundi. Lundi : 0/2 ; mardi : 0/2 ; mercredi : 1/2 ; minuit mercredi : 2/2.

Les fuseaux horaires sont unifiés à l'heure du serveur pour simplifier.

Nuances d'implémentation dans le backend

• Mettre en cache le calendrier en mémoire : année en cours + année suivante (avec nettoyage des anciennes données).
• Enregistrer les valeurs du compteur et les délais d'origine dans la base de données pour chaque demande — minimise les recalculs.
• Stocker l'historique des délais : une table séparée pour les configurations par type/période ou une colonne sur l'entité.

Mise à jour du calendrier : requêtes API au démarrage, quotidiennement à 00h00.

Tests des scénarios clés

Tester le comportement en temps réel ou simuler via base de données/API :

• Jour ouvrable normal.
• Jour férié.
• Soirée d'un jour ouvrable (après les horaires).
• Absence de calendrier — repli et mise à jour automatique.
• Délais dépassés et normaux.
• Charge : plusieurs calendriers sur plusieurs années.
• Services API inactifs.

Points clés

• Le décompte commence le jour de la publication dans les horaires ou le jour ouvrable suivant.
• Compteur : jours complets écoulés, commençant à 0/N.
• Dépassé : ≥ N à 00h00 après le délai.
• La mise en cache et l'enregistrement en base de données réduisent la charge.
• Tester les cas limites : jours fériés, soirées, données manquantes.

— Editorial Team