Dans la dizaine de départements qui n'utilisent que le flux Delivery, les messages reçus par le département sont traités par un logiciel doté d'un algorithme précis. Si cet algorithme s'attend à trouver la "référence de commande du CD", alors c'est une bonne idée de lui fournir. S'il s'attend à autre chose (le NIR du bénéficiaire, le numéro de dossier de la prise en charge, l'identifiant base de données de l'enregistrement du plan d'aide, etc), alors il vaut mieux passer un champ vide que de prendre le risque que le Delivery soit mal attribué.

Il me semble difficile de sortir de la logique :
- accord local, alors renseigner IssuerAssignedID,
- pas d'accord local, alors le laisser vide car le logiciel qui traite le message est une boîte noire vis à vis de cette information.

>>> il peut y avoir une convention un accord entre le département et le SAAD pour le remplir avec une information saisie manuellement

C'est en effet hors du périmètre du guide Esppadom en tant que référence de la standardisation des échanges mais on pourrait se pencher sur l'envoi de DELIVERY sans ORDER préalable, ce qui est la situation constatée actuellement sur une dizaine de départements.

Et indiquer la possibilité de mettre dans IssuerAssignedID la référence de commande du CD permet à celui-ci de retrouver ne serait-ce que le bénéficiaire sans passer par une recherche de type nom/prénom

Dans le standard, le champ IssuerAssignedID n'est pas obligatoire.

Localement, faute d'un flux Order susceptible de fournir la donnée attendue en retour par le département, il peut y avoir une convention entre le département et le SAAD pour le remplir avec une information saisie manuellement (ou, au sens large, reçue par un autre canal qu'un message Order).

Ma réponse - purement technique - visait simplement à spécifier que la nature de cette information n'est pas du ressort d'Esppadom. Pour le dire autrement, si elle avait été validée en atelier, donc de portée "globale", elle serait dans le guide d'implémentation.

alors comment fait-on pour remplir un DELIVERY quand on n'a pas reçu de ORDER = est-ce qu'on peut envoyer dans IssuerAssignedID le numéro de commande figurant sur le document papier ? sinon comment le donneur d'ordre va-t-il faire le lien entre une délivrance de services et un bénéficiaire ?

Les messages sont conçus pour fonctionner ensemble, mais également pour pouvoir être opérés de façon autonome, ne serait-ce qu'en cas de mise en œuvre progressive message par message.

Pour cette raison, le champ IssuerAssignedID qui permet de préciser, au sein de Delivery, l'identifiant de la commande (reçu via un message Order) est optionnel.

Compte tenu du fait que les messages Esppadom interconnectent des machines (qui peuvent être réglées pour émettre un identifiant quelconque, par exemple l'identifiant en base de données de la ligne qui contient, entre autres, la référence de commande), il me paraît prudent - si l'identifiant de référence n'a pas été reçu par un message Order, de gérer son éventuel remplacement localement, en cohérence avec le donneur d'ordre.

En tout cas, la consigne officielle "par défaut" est "pas d'identifiant de commande reçue par Order => laisser IssuerAssignedID vide".

En théorie, le point de départ d'une transaction est un message ORDER qui mentionne les références uniques (IDs) utilisées par le logiciel du donneur d'ordres : ID du donneur d'ordre, ID du bénéficiaire, ID du bon de commande, ID du SAAD, etc.

La réponse est un message DELIVERY qui va reprendre tous ces IDs, puis un message INVOICE, idem

Le problème est "comment construire un DELIVERY sans avoir traité de message ORDER mais seulement un document papier reçu du CD ?"

Il semble que l'élément principal est la référence du bon de commande figurant sur le document papier







Cette référence de commande permet au donneur d'ordres de retrouver le bénéficiaire, le SAAD auquel la commande a été passée, etc.