Donc ESPPADOM_SERVICE est dédié au qualitatif et ESPPADOM_PREST n'existe pas. Je me replonge dans le guide d'implémentation ...
Il me semble que le concept essentiel et obligatoire est SpecifiedCITradeProduct qui dans EDIFACT précise le produit commandé / délivré / facturé.

Au passage, dans Esppadom on ne parle pas de produit mais on utilise à la fois les termes prestation ou service => il faudrait au moins se limiter à utiliser prestation



SpecifiedCITradeProduct est décrit par un ID dans une liste qui n'est pas formalisée par EDESS et va donc être une liste locale (par exemple celle du donneur d'ordre ou une liste sur laquelle donneur d'ordres et prestataires se sont mis d'accord)et par un texte libre. Esppadom permet de mentionner à quelle liste l'ID (code) fait référence.

Dans la logique des 3 messages, on doit retrouver les mêmes ID (codes) dans order, delivery et invoice pour une description unique des prestations au niveau local.

Quelques exemples pour en tirer des règles à appliquer :

<ns3:ID listID="ESPPADOM_TYPE_AIDE" listAgencyName="EDESS">APA</ns3:ID> => ici on fait référence à la liste ESPPADOM_TYPE_AIDE, maintenue par EDESS (listAgencyName) et dans laquelle figure bien la valeur APA => OK

<ns3:ID listID="ESPPADOM_CADRE" listAgencyName="EDESS">FE1</ns3:ID> => comme ci-dessus, liste maintenue par EDESS sauf que la valeur FE1 n'y figure pas => NOK

<UNECE_QDT_8p0:ID listID="ESPPADOM_PREST" listAgencyName="EDESS">APA-HRJO</UNECE_QDT_8p0:ID> => ne pas utiliser ESPPADOM dans le nom d'une liste qui n'existe pas officiellement, ni indiquer qu'elle est maintenue par EDESS (listAgencyName)

Pour finir, les exemples figurant dans le guide d'implémentation seront modifiés car repris "tels quels" ils peuvent être source de confusion :

dans ORDER au 3.3


dans DELIVERY au 4.4


dans INVOICE au 5.4

ESPPADOM_SERVICE est dédié au volet qualitatif, qui n'est manifestement pas encore dans les usages.

Les messages qui mentionnent ESPPADOM_PREST avec des codes "propriétaires" ne sont pas correctement formés car la balise qui permet de préciser la valeur de l'ID permet également de préciser de quelle liste il est tiré. Il serait donc plus logique, si, localement, les identifiants sont à valeur dans une liste locale (par exemple celle du donneur d'ordre), que cette liste soit précisée (à la place de ESPPADOM_PREST qui n'existe pas).

Bref, la logique, quand on précise un code, c'est de stipuler à quelle liste il appartient, et Esppadom le permet.

Philippe AMELINE écrit:
Dans les messages traités par le Thagomizer - 87 flux à ce jour - la référence à ESPPADOM_SERVICE ne figure jamais et ESPPADOM_PREST est présent dans 14 flux avec des valeurs d'ID spécifiques comme APA-HRJO, AMPH, un code numérique ou alphanumérique

Il ne s'agit pas de la liste ESPPADOM_SERVICE car cette liste est spécifique du volet "qualitatif", porté par la balise CITradeDetailType dans Order, qui permet de détailler, par exemple que "les 2 heures d'aide allouée doivent contenir (au moins) une aide au lever et une aide à la toilette".

Dans l'exemple où apparait cette liste fantôme, il s'agit du "niveau du dessus" (balise CITradeProductType dans Order), où est indiqué le service au sens "quantitatif" (par exemple des heures d'aide). Ce bloc "description du service" contient une zone de texte, et un identifiant.

J'avoue que j'ignore si quelqu'un utilise l'identifiant et ce qu'il est censé contenir. Compte tenu de la relation 1-n entre le donneur d'ordre et les services d'aide, on peut supposer qu'il est à valeur dans une liste fournie par le donneur d'ordre.

Le guide d'implémentation v1.4.2 mentionne une liste ESPPADOM_PREST :

dans ORDER au 3.3



dans INVOICE au 5.4



Cette liste n'est pas définie dans la section 7 du guide. S'agit-il en fait de la liste ESPPADOM_SERVICE ? (coquille à corriger dans le guide)