Les libellés courts peuvent laisser supposer que le même motif se trouve à des niveaux différents. En réalité, si on "dépile" l'arborescence, on découvre que :
1.1.1.1.2.2.2 Heure d’arrivée horodatée tardivement du fait d'un problème technique (problème de badge)
1.2.1.1.2.2.2 Heure d’arrivée manquante du fait d'un problème technique (problème de badge)

Le problème de badge est alors une précision de l'information principale POUR LE MESSAGE : l'heure d'arrivée est considérée comme devant être corrigée ou bien est déclarée manquante.

L'avantage de conserver l'arbre dans ce sens, c'est que donneur d'ordre et prestataire peuvent se mettre d'accord sur la finesse d'explication et tronquer la partie droite de l'arbre (par exemple en signalant juste que l'heure d'arrivée a été corrigée à cause d'un problème technique du système d'horodatage - sans se préoccuper de transmettre si c'est un problème de badge ou de recharge de smartphone, etc).

Telle que je vois la liste actuelle, sa "partie initiale" (à gauche, près du tronc) doit véhiculer l'essentiel (typiquement est-ce un forçage ou une correction) et le feuillage, peut permettre, pour ceux qui le souhaitent, d'analyser la fiabilité de leur solution d'horodatage ou de télégestion (taux d'indisponibilité et causes les plus fréquentes).

Mais... rien n'empêche de construire l'interface homme-machine sur le terrain dans l'autre sens pour outiller des intentions spécifiques. On peut tout à fait, pour une technologie donnée, fixer le niveau de précision souhaitée et, ayant ainsi sélectionné une sous-partie de l'arbre, construire une IHM "de gauche à droite"... par contre, il faudra rendre obligatoire la profondeur de description qui permet de coder ; en l'occurrence, si on démarre du problème de badge, il sera nécessaire de savoir si elle a entrainé une absence ou un besoin de correction de l'heure d'arrivée.

Dans ce modèle, on retrouve plusieurs fois le même motif de forçage à des niveaux différents, via un cheminement par typologie d'origine. Par exemple :
1.1.1.1.2.2.2. Problème de badge
1.2.1.1.2.2.2. Problème de badge

Ce qui est important c'est le motif de forçage, il doit donc être l'élément principal et à la racine du modèle, avec ensuite pour un motif donné, pouvoir détailler l'origine du forçage, de ce fait nous aurions, par exemple :

1 Problème de badge
1.1 Information liée à la temporalité
1.1.1 Information de forçage
1.1.1.1 Heure d'arrivée
.......

1.1.2 Information technique
1.1.2.1 Heure d'arrivée

De ce fait le motif de correction est unique, accessible dès le départ, et ensuite pour un motif on sélectionne dans l'arborescence la typologie.

Confronté à la fois à :
- la difficulté d'aligner les listes de motifs déjà utilisées par les uns et les autres,
- l'intérêt exprimé par les départements de distinguer clairement les problèmes techniques des forçages,
- le fait que le code concerné traite également d'autre cas que ces deux catégories.

J'ai tenté de construire une représentation arborescente au lieu d'une liste "à plat". Cette décision ne doit pas être compris comme un tropisme personnel (j'ai tenté de résister), mais comme la possibilité d'organiser l'information "du général au particulier" afin de permettre à chacun de définir sa propre granularité descriptive, tout en bénéficiant du chainage global.

Le fichier joint est un "document martyr" (certains éléments ne sont peut être pas à leur place... et la logique globale induite par les premiers niveaux de l'arborescence peut être discutée).

Vous trouverez ci-joint un tableau récapitulatif des motifs de correction d'ESPPADOM ainsi que des acteurs qui m'ont transmis leurs codes internes (dans l'ordre de réception, ADMR, Hippocad, Edenred).

La tentative d'alignement n'est pas très concluante... il y a donc matière à échanges.

Le message Delivery permet de corriger les données d'horodatage, en précisant le motif de correction. .
Ceci est décrit au chapitre 4.6.3 "Délivrance retenue" du Guide d'implémentation ESPPADOM; le bloc qui permet de décrire ces données corrigées est de la forme :

<xsd:complexType name="CISupplyChainEventType">
<xsd:sequence>
<xsd:element name="TypeCode" type="CodeQualifiedType" minOccurs="0"/>
<xsd:element name="OccurrenceCISpecifiedPeriod" type="CISpecifiedPeriodType"/>
</xsd:sequence>
</xsd:complexType>

Le bloc "OccurrenceCISpecifiedPeriod" contient les moments de début et de fin retenus, tandis que, comme le précise le guide :

"La balise TypeCode, unique et optionnelle, contient le motif de correction de l’événement original au cas où la période retenue diffèrerait de la période horodatée. Le code doit être choisi au sein de la liste ESPPADOM_EFFECTIVITY_AJUST."

Par ailleurs, toujours selon le guide :

"On notera le cas particulier pour lequel le message Delivery est utilisé pour véhiculer des données de pointage et/ou d’horodatage. Dans ce cas, on signalera par le code HOR que la période retenue n’a pas de validité. Même si sa présence reste obligatoire, elle pourra contenir des valeurs à la convenance du service de télégestion (par exemple, « zéro » ou un rappel des données d’horodatage)."

Dans l'état actuel du standard, la table ESPPADOM_EFFECTIVITY_AJUST contient les codes suivants :

CRE : Création d’une intervention non horodatée
MDT : Modification d’une intervention hors données horaires
SUP : Suppression d’une intervention
COA : Correction du fait d’une absence d’arrivée horodatée
COD : Correction du fait d’une absence de départ horodaté
CO2 : Correction du fait d’une absence d’arrivée et de départ horodatés
HOR : Message Delivery incomplet car utilisé pour véhiculer des informations de pointage/horodatage. La période retenue ne doit donc pas être prise en compte.