j'essaie d'être plus précis

on prend dans la liste ESPPADOM_EFFECTIVITY_AJUST le motif justifiant la différence entre la période de délivrance retenue (= données corrigées dans le guide métier) et les données brutes transmises par le système de pointage

les éléments de cette liste ESPPADOM_EFFECTIVITY_AJUST évoquent plutôt des motifs de corrections/modifications successives d'un DELIVERY = à mettre dans le contexte du DELIVERY

CRE = ceci est un nouveau DELIVERY dont l'identifiant unique est 324893987 = dans entête DELIVERY
COD = correction de l'intervention décrite dans le DELIVERY d'identifiant 324893987
SUP = le DELIVERY d'identifiant 324893987 doit être supprimé

la liste ESPPADOM_EFFECTIVITY_AJUST sert à justifier l'écart dans un même message entre "délivrance retenue" et "délivrance effective = données brutes du système de pointage" => suite à un arrondi, à l'application d'une durée forfaitaire en cas d'absence du bénéficiaire, etc.

d'où plutôt des codes comme
ARR = la délivrance retenue est un arrondi de la délivrance effective
ABS = en l'absence du bénéficiaire, la délivrance retenue est un forfait (éventuellement complété par une délivrance effective s'il y a pu avoir pointage)

je passe un long moment sur les Guides métier et d'implémentation; en premier lieu il me semble qu'il faudrait bien distinguer :

Corriger ou ajuster ?
corriger = modifier pour faire disparaître une erreur, un défaut
ajuster = modifier pour être en conformité avec des règles

sauf grave contresens de ma part, ESPPADOM est dans une logique "annule et remplace" => s'il y a eu une erreur, elle est corrigée par l'envoi d'un message corrigé, donc on devrait seulement parler d'ajustement quand il s'agit de justifier pourquoi la période de délivrance retenue (= pour la facturation) diffère de la période de délivrance effective (= données brutes issues du système d'horodatage)

Il me semble que la possibilité pour l'émetteur et le récepteur d'adapter les messages est toujours licite puisque Esppadom est un standard et non une norme. Ce que nous proposons est plutôt le "terrain d'échange de base" qui met les divers acteurs sur un pied d'égalité (faute d'accord, l'arbitrage se fait sur le respect strict du standard).

Sur le sujet de l'arrondi, je peux juste dire que nous ne l'avons, bien entendu, pas oublié. S'il n'est pas dans la liste, c'est qu'il n'a pas été considéré comme un motif d'ajustement... ou plutôt qu'il a été considéré, par défaut, qu'un ajustement sans motif est un arrondi.

De mémoire, les discussions autour de l'arrondi ont toujours été trop compliquées pour que nous puissions voir les choses autrement... mais le temps a passé, et il est peut-être temps de reprendre l'ouvrage.

Par ailleurs, si, en dehors de l'arrondi, il manquait de "vrais motifs", il serait important de les ajouter - ne serait-ce que pour conserver à l'arrondi son réel statut de "motif par défaut" ;)

Les items de la liste en vigueur ne sont pas des motifs de correction (plutôt des constats)
Compléter (ou remplacer ?) la liste en vigueur de motifs métiers ?
Et/ou permettre d’utiliser des motifs hors liste, qui pourront être utilisés dès lors que l’émetteur et le récepteur se sont accordés sur ceux-ci

A minima, ajouter le motif « Arrondi »

pour mémoire : la liste ESPPADOM_EFFECTIVITY_AJUST décrit les motifs d’adaptation de la période d’effectivité par rapport aux données d’horodatage

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.