Suite à un échange récent avec la Métropole Grand Lyon, on rappelle que DELIVERY permet de envoyer des données brutes mais aussi des données corrigées, avec indication du motif de correction

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.