1) voici un exemple d’implémentation de l’ID tel qu'Apologic l’a déjà mis en œuvre

<xsd:complexType name="CITradeContactType">
<xsd:sequence>
<xsd:element name="ID" type="UNECE_UDT_9p0:IDQualifiedType" minOccurs="0"/>
<xsd:element name="PersonName" type="UNECE_UDT_9p0:TextType" minOccurs="0"/>
<xsd:element name="TypeCode" type="UNECE_UDT_9p0:CodeQualifiedType" minOccurs="0"/>
<xsd:element name="TelephoneCIUniversalCommunication" type="UNECE_PERSON_1p1:CIUniversalCommunicationNumberType" minOccurs="0"/>
<xsd:element name="MobileTelephoneCIUniversalCommunication" type="UNECE_PERSON_1p1:CIUniversalCommunicationNumberType" minOccurs="0"/>
<xsd:element name="EmailURICIUniversalCommunication" type="UNECE_PERSON_1p1:CIUniversalCommunicationUnqualifiedURIType" minOccurs="0"/>
<xsd:element name="PostalAddress" type="UNECE_PERSON_1p1:CITradeAddressType" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>

Pour la catégorie d’intervenant, prévoir l’ajout de la balise HandlingCode faisant référence à une liste avec les possibilités suivantes :
A => Agent à domicile
B => Employé à domicile
C => Auxiliaire de vie à domicile


2) La délivrance retenue est à rendre optionnelle pour traiter le cas suivant :
- Horodatage de début connu mais pas encore l’horodatage de fin (ou vice-versa)
- il est nécessaire que les horodatages de début et de fin de la délivrance effective soient optionnels

- La délivrance retenue devient obligatoire (par convention, donc règle de gestion) dès lors que l’horodatage et début et de fin sont connus

- On tend vers le scénario C en prévoyant d’ajouter un motif ou à minima un code d’erreur, dans la délivrance effective, qui précise que l’horodatage est incomplet. Ceci est utile si les horodatages sont gérés sur une plateforme et transmis en temps réel aux application métier pour comparaison avec le planning prévisionnel.

3) Nous sommes favorables à une indication de version sur l'enveloppe des messages et non pas sur le message. Cela donne une cohérence sur les messages transmis dans un même lot. Donc solution A préférée.

Plusieurs évolutions ont été proposées lors du dernier atelier. Certaines ne posent pas de problème, tandis que d'autres justifient l'ouverture d'une discussion.

1) Besoin, dans le message Delivery, d'un identifiant et d'un niveau de qualification pour l'intervenant.
Il a été évoqué le fait que ces informations auraient existé et auraient été supprimées ; ce n'est pas le cas.
Une balise "HandlingCode" permet de préciser la qualification requise dans le message Order, mais il n'a pas existé d'équivalent pour Delivery.
Ajouter un ID et une qualification au sein des contacts rendra ces balises disponibles pour toutes les personnes dans tous les messages... je ne pense pas que ça pose de problème.

2) Afin de pouvoir utiliser Delivery comme support du mécanisme de pointage, il a été demandé de rendre la date de fin optionnelle dans le bloc "AdditionalReferencedCIReferencedDocument" qui permet d'inscrire les données d'horodatage.
Pour rappel, Delivery contient un bloc obligatoire "ActualDespatchCISupplyChainEvent" qui permet d'inscrire l'effectivité retenue et un bloc optionnel "AdditionalReferencedCIReferencedDocument" qui accueille les informations d'horodatage.

Si on souhaite utiliser Delivery pour transmettre des informations de pointage, ne faudrait-il pas rendre ActualDespatchCISupplyChainEvent optionnel ?

D'autre part, lors de l'échange d'informations qui permet d'obtenir un horodatage à partir du pointage d'arrivée et du pointage de départ, il existe trois scénarios possible :
A) dissociée : le message d'arrivée et le message de départ sont indépendants. Chacun est expédié en utilisant le bloc "StartDateTime" et l'horodatage est reconstitué par la suite en supposant que l'intervenant est arrivé avant de partir.
B) sémantique : la technologie de pointage spécifie s'il s'agit d'une arrivée ou d'un départ, les messages sont indépendants mais l'un utilise le bloc "StartDateTime" et l'autre le bloc "EndDateTime".
C) cumulatif : le message est initialement vide. Le premier pointage renseigne "StartDateTime" et le second, voyant que ce bloc est déjà occupé, renseigne "EndDateTime".

Ceci pour dire qu'il parait raisonnable de rendre "StartDateTime" optionnel si on veut utiliser le deuxième mode, qui parait pouvoir exister.

3) Ajout d'une information de version du message

Plusieurs options sont ici possibles :

A) Mettre la version du message au sein de la balise "enveloppe" (<Order>, <Delivery> ou <Invoice>) qui contient les messages. L'inconvénient, c'est que, toute enveloppe étant destinée à être déchirée et jetée, les messages porteurs d'informations n'en auront plus trace.
B) Mettre la version comme attribut de la balise "racine" des messages, par exemple : <CrossIndustryOrder version="1.2">
C) Mettre la version au sein du message, typiquement comme balise au sein du bloc "ExchangedDocumentContext" qui existe dans les trois messages. Par exemple :
<CrossIndustryOrder>
<CIOHExchangedDocumentContext>
<version>1.2</version>

La solution C) est probablement la plus "propre"... mais le numéro de version n'y est pas connu au démarrage de l'analyse du message.

Merci de vos retours rapides sur ces points afin que je puisse vous proposer rapidement une version testable.