La question QG04 posait le problème général de la cardinalité des messages et des informations au sein des messages.

Q.G 04 A la lecture du format des flux, une crainte est de devoir générer autant de fichiers que d’enregistrements. Pour chaque flux, des itérations de mêmes balises sont-elles autorisées pour véhiculer dans un même fichier
Q.G 04.1 Plusieurs bénéficiaires et/ou plans d’aide (flux order) ?
Q.G 04.2 Plusieurs lignes de facture (flux invoice) ?
Q.G 04.3 Plusieurs interventions (flux delivery) ?

A la lecture du document "Guide d'implémentation V 1.0 – décembre 2014", il apparaît que :

"2.5 Commande et lots de commandes
Conformément à la norme européenne, il n’y a qu’un seul fichier par commande donc autant de
fichiers XML."

Le principe est donc bien d'un fichier XML par "enregistrement".

Par contre, le standard prend en compte la notion de transaction, en tant qu'enveloppe virtuelle "tracée" contenant un ensemble de fichiers XML

"2.6 Commande et transaction – Quelle différence à faire entre le numéro de transaction et le numéro
de commande ?

Le numéro de transaction est unique et correspond à l’envoi d’un lot de commandes (l’enveloppe
de transmission). La transaction est l'équivalent du cachet de la poste.

Le n° de transaction est porté par tous les messages qui ont été envoyés au cours de la session
correspondante. C'est important pour tracer les messages.

Chaque commande porte son propre numéro de commande. Le numéro de commande correspond à
une commande à une date et heure données. Si l’on constate une erreur dans le corps de la
commande, on crée un nouveau numéro de commande qui se trouvera dans un envoi suivant donc
avec un nouveau numéro de transaction. Seul, celui qui émet le message peut faire référence du n°
de transaction dans la suite du processus pour la traçabilité."

Par ailleurs, la cardinalité des informations est bien décrite au sein du ppt "Livrable modélisation" livré par Philoé et Logica :

1 Plan d’aide est géré par 1 Ordonnateur / Financeur, et concerne 1 Bénéficiaire
1 Plan d’aide donne droit à 1 à n prestation
1 Prestation est réalisée par 1 Prestataire
1 Prestataire possède 1 Adresse et 1 Responsable
1 Ordonnateur-Financeur possède 1 Adresse et 1 Responsable
1 Bénéficiaire possède 1 Adresse

Le message ORDER étant réputé correspondre au plan d'aide, sa cardinalité est ainsi clairement définie... mais, le Guide d'implémentation V 1.0 précise :

"2.10 Quelle différence à faire entre le ‘plan d’aide’ et la ‘prise en charge’

Le plan d’aide, c’est la définition de ce que l’on va apporter au bénéficiaire. La prise en charge,
c’est ce que l’on demande à un prestataire en particulier de faire (pour tout ou partie du plan
d’aide).

Un plan d’aide pour un unique bénéficiaire peut donc correspondre à plusieurs prises en charge,
l’une d’un mandataire et l’autre d’un prestataire par exemple ; il est donc nécessaire de séparer les
deux bons de commande."

On peut donc supposer qu'un message ORDER correspond à une prise en charge, c'est à dire éventuellement à une partie des "1 à n prestation" citées ci-dessus.

Toujours dans le Guide d'implémentation V 1.0, on lit :

"2.12 Gestion des factures
Une facture pour chaque prise en charge : c'est la norme européenne."

Donc cardinalité 1 à 1 entre un fichier XML ORDER et un fichier XML INVOICE

Toujours dans le chapitre 2.12, est traité le cas des "récaps" :

"faut distinguer les récap. En général, le prestataire envoie une récap. des factures, alors que le
message Invoice envoie une facture par bénéficiaire.

En fait, toutes les factures vont être envoyées dans une transaction. La récap c'est la liste des
factures de la transaction. C'est aux SI de le faire pour ceux qui le veulent. C'est inévitable en
pratique car le volume de factures, (et en particulier si on doit avoir du papier), serait trop grand.
Donc, ce qu'ESPPADOM appelle "Facture" est une ligne dans ce que les acteurs actuels papier
appellent "Facture".

Récap = transaction, Ligne = numéro de facture

Il n’y a pas de problème d’intégration des factures une à une dans un logiciel métier du CG, pas
plus qu’un fichier récapitulatif des factures. Le logiciel métier doit pouvoir faire le nécessaire pour
reconstituer un ordre de paiement « proforma » correspondant au prestataire (avec le code « N° de
transaction » regroupement de factures du prestataire).

Le principe retenu par Esppadom est de dissocier d’une part l’émission d’une facture (le document
d’échange) dans laquelle, il doit y avoir la granularité la plus grande des informations et d’autre
part, le traitement des données et la forme de la restitution de l’information qui interviennent
ensuite dans le logiciel médico-social du CG. La dématérialisation électronique permet cela sans
les inconvénients de recevoir tous les mois au Conseil général une pile de factures papier.

La fonction « vérification du service fait » par rapprochement de la facture du plan d’aide est en
aval de la transmission.

Le repérage dans le SI peut être la concaténation numéro de Transaction - numéro de facture
Lorsqu’il y a une anomalie sur une facture dans une transaction (groupe de factures), seule la
facture incriminée est rejetée et renvoyée au prestataire. Il n’y a pas de réémission de la même
facture (même numéro de facture) mais la production d’une nouvelle facture avec un nouveau
numéro de facture."

Tout ceci, avec une complexité sur les récaps qui fait le sel du métier de comptable, établit clairement les règles de cardinalité :

1 message XML par enregistrement, correspondant à 1 prise en charge, tant pour ORDER que pour INVOICE
Plusieurs messages peuvent être inclus dans une transaction qui en assure la traçabilité.