ESPPADOM

Echanges financeurs – prestataires pour les services à domicile auprès
des personnes en perte d'autonomie

 

 

Programme soutenu par
la Caisse nationale de solidarité pour l’autonomie

 

 

 

GUIDE D’IMPLÉMENTATION
DES MESSAGES
ORDER, DELIVERY ET INVOICE

                                                                          

 

 

 

 

Résumé : Ce document détaille comment implémenter les messages ORDER, DELIVERY et INVOICE qui décrivent respectivement une commande de prestations, une télé-déclaration d’intervention et une facturation de prestations. Il est basé sur les précédents travaux menés par le groupe technique Esppadom de l’association EDISanté – devenue EDESS – et les complète par des précisions portant sur des cas d’utilisation, des nomenclatures, etc.

                                                          

 

 

 

 

 

 

 

 

 

 

Statut

document conforme à la version 1.3 des messages

Version

1.4.1

Date

22/09/2017

Auteurs

EDESS – Philippe AMELINE, François ROUGERIE

 

Evolutions

 

V 0.0

08/03/2016

Version initiale, issue de la fusion des guides spécifiques à chaque message

V 0.1

02/05/2016

Evolution suite aux remarques et évolutions de l’atelier du 15/04/2016

V 1.2

20/06/2016

Version 1.2 des messages suite aux ateliers du 17/06/2016 et du 07/07/2016

V 1.3

21/11/2016

Version 1.3 des messages suite à l’atelier du 17/11/2016

V 1.4

22/09/2017

Évolutions :

Précision du volet qualitatif et version initiale de la liste ESPPADOM_SERVICE

Explicitaton du fait qu’une facture peut concerner plusieurs commandes.

Corrections :

Correction du message d’exemple de Delivery qui représentait incorrectement le contenu de la balise BuyerOrderReferencedCIReferencedDocument.

Reste en chantier :

Remplacement de la liste ESPPADOM_EFFECTIVITY_AJUST des motifs de forçage au sein de Delivery par une liste plus complète ou une classification arborescente.

Prise en compte, au sein de Order de la Majoration pour Tierce Personne comme avance de paiement.

La liste ESPPADOM_PROFIL des profils d’intervenants reste vide.

Table des matières

 

1 Présentation  6

1.1 Esppadom...................................................................................................................................... 6

1.2 Filiation des messages.................................................................................................................... 6

1.3 Vocabulaire..................................................................................................................................... 6

1.4 Cas d’usage.................................................................................................................................... 6

1.5 Enveloppe des messages................................................................................................................ 7

1.6 Règles de gestion des messages..................................................................................................... 8

1.7 Indications de cardinalité.................................................................................................................. 8

1.8 Balises complexes........................................................................................................................... 8

1.8.1 Balise de type IDQualifiedType................................................................................................... 8

1.8.2 Balise de type CodeQualifiedType.............................................................................................. 9

2 Description des personnes morales ou physiques       10

2.1 Bloc générique.............................................................................................................................. 10

2.2 Liste de contacts............................................................................................................................ 11

2.3 Gestion des adresses.................................................................................................................... 12

2.4 Contexte de délivrance.................................................................................................................. 12

3 Message ORDER       14

3.1 Structure du message.................................................................................................................... 14

3.2 Architecture................................................................................................................................... 14

3.3 Message minimal........................................................................................................................... 16

3.4 Contexte : transaction et identification de la commande................................................................... 18

3.4.1 Transaction............................................................................................................................. 18

3.4.2 Commande............................................................................................................................. 18

3.5 Prestataire et donneur d’ordre........................................................................................................ 19

3.5.1 Prestataire.............................................................................................................................. 19

3.5.2 Donneur d’ordre et contrat........................................................................................................ 20

3.6 Bénéficiaire................................................................................................................................... 20

3.7 Conditions financières.................................................................................................................... 20

3.7.1 Description du payeur.............................................................................................................. 21

3.7.2 Montant et imputation.............................................................................................................. 21

3.8 Liste des prestations à réaliser....................................................................................................... 21

3.8.1 Identification............................................................................................................................ 22

3.8.2 Agrément financier................................................................................................................... 23

3.8.3 Informations de mise en œuvre................................................................................................ 23

3.8.4 Conditions financières.............................................................................................................. 24

3.8.5 Description du service.............................................................................................................. 25

3.8.6 Actes qui constituent des consignes au sein de la prestation...................................................... 25

3.8.7 Modifications de la prestation................................................................................................... 26

4 Message DELIVERY  27

4.1 Structure du message.................................................................................................................... 27

4.2 Architecture................................................................................................................................... 27

4.3 Message minimal........................................................................................................................... 28

4.4 Contexte : transaction et identification de la commande................................................................... 29

4.4.1 Transaction............................................................................................................................. 30

4.4.2 Télégestion............................................................................................................................. 30

4.5 Prestataire et donneur d’ordre........................................................................................................ 31

4.5.1 Donneur d’ordre et identifiant de commande.............................................................................. 31

4.5.2 Type de contrat........................................................................................................................ 32

4.6 Délivrance des prestations............................................................................................................. 32

4.6.1 Bénéficiaire............................................................................................................................. 32

4.6.2 Prestataire.............................................................................................................................. 32

4.6.3 Délivrance retenue................................................................................................................... 33

4.6.4 Délivrance effective.................................................................................................................. 33

4.7 Imputation comptable..................................................................................................................... 34

4.8 Liste des prestations réalisées........................................................................................................ 35

4.8.1 Identification............................................................................................................................ 35

4.8.2 Quantité théorique à facturer.................................................................................................... 36

4.8.3 Informations de traitement financier.......................................................................................... 37

4.8.4 Description du service.............................................................................................................. 37

4.8.5 Liste des actes........................................................................................................................ 37

5 Message INVOICE     39

5.1 Structure du message.................................................................................................................... 39

5.2 Architecture................................................................................................................................... 39

5.3 Règles européennes...................................................................................................................... 41

5.4 Message minimal........................................................................................................................... 41

5.5 Contexte : transaction et identification de la facture.......................................................................... 43

5.5.1 Transaction............................................................................................................................. 43

5.5.2 Facture................................................................................................................................... 43

5.6 Prestataire et donneur d’ordre........................................................................................................ 44

5.6.1 Prestataire.............................................................................................................................. 44

5.6.2 Donneur d’ordre...................................................................................................................... 45

5.6.3 Identifiant de commande.......................................................................................................... 45

5.7 Bénéficiaire................................................................................................................................... 46

5.8 Conditions financières.................................................................................................................... 46

5.8.1 Gestion des décimales............................................................................................................. 47

5.8.2 Montant total dû....................................................................................................................... 47

5.8.3 Devise.................................................................................................................................... 48

5.8.4 Informations bancaires du prestataire....................................................................................... 48

5.8.5 Taux de TVA............................................................................................................................ 49

5.8.6 Période facturée...................................................................................................................... 50

5.8.7 Remises et frais....................................................................................................................... 50

5.8.8 Echéance de paiement............................................................................................................ 51

5.8.9 Détails de calcul du montant total dû......................................................................................... 51

5.8.10 Référence d’imputation comptable.......................................................................................... 54

5.9 Liste des prestations facturées....................................................................................................... 54

5.9.1 Identification............................................................................................................................ 54

5.9.2 Agrément financier................................................................................................................... 56

5.9.3 Informations de mise en œuvre................................................................................................ 57

5.9.4 Conditions financières.............................................................................................................. 57

5.9.5 Montant net HT........................................................................................................................ 58

5.9.6 Description de la prestation...................................................................................................... 58

6 Dictionnaire des termes utilisés          60

6.1 APA.............................................................................................................................................. 60

6.2 GIR............................................................................................................................................... 60

6.3 ISO 3166...................................................................................................................................... 60

6.4 ISO 4217...................................................................................................................................... 61

6.5 PCH.............................................................................................................................................. 61

6.6 SIRET........................................................................................................................................... 61

7 Identifiants ESPPADOM         62

7.1 Liste ESPPADOM_ADDITIONAL_INFORMATION........................................................................... 62

7.2 Liste ESPPADOM_CADRE............................................................................................................ 62

7.3 Liste ESPPADOM_CHANGE_REASON.......................................................................................... 62

7.4 Liste ESPPADOM_CHANGE_TYPE............................................................................................... 63

7.5 Liste ESPPADOM_CIVILITY........................................................................................................... 63

7.6 Liste ESPPADOM_CONTACT_BENEFICIAIRE............................................................................... 64

7.7 Liste ESPPADOM_CONTACT_DONNEUR_ORDRE........................................................................ 64

7.8 Liste ESPPADOM_CONTACT_PAYEUR......................................................................................... 64

7.9 Liste ESPPADOM_CONTACT_PRESTATAIRE................................................................................ 65

7.10 Liste ESPPADOM_EFFECTIVITY_AJUST..................................................................................... 65

7.11 Liste ESPPADOM_GIR................................................................................................................. 66

7.12 Liste ESPPADOM_INVOICE_LINE_TYPE..................................................................................... 66

7.13 Liste ESPPADOM_PROFIL.......................................................................................................... 67

7.14 Liste ESPPADOM_SERVICE........................................................................................................ 68

7.15 Liste ESPPADOM_TIMESTAMP_METHOD................................................................................... 69

7.16 Liste ESPPADOM_TYPE_AIDE.................................................................................................... 69

7.17 Liste ESPPADOM_TYPE_BENEFICIAIRE..................................................................................... 70

8 Identifiants EXTERNES          71

8.1 Code MUG-1 (Core Invoice VAT Category Code)............................................................................. 71

8.2 Code MUG-2 (Core Invoice Units of Measure)................................................................................. 71

8.3 Code MUG-4 (Payment means code).............................................................................................. 71

8.4 Code UN/EDIFACT 4465 (Adjustment reason description code)....................................................... 72

8.5 Types xsd de référence.................................................................................................................. 73

8.5.1 xsd:string................................................................................................................................ 73

8.5.2 xsd:token................................................................................................................................ 73

8.5.3 xsd:decimal............................................................................................................................. 73

8.5.4 xsd:date.................................................................................................................................. 73

8.5.5 xsd:dateTime........................................................................................................................... 73

8.6 Types Unece / Esppadom.............................................................................................................. 73

8.6.1 AmountType............................................................................................................................ 73

8.6.2 CodeQualifiedType.................................................................................................................. 74

8.6.3 DateMandatoryDateTimeType.................................................................................................. 74

8.6.4 DateTimeType......................................................................................................................... 74

8.6.5 DateType................................................................................................................................ 74

8.6.6 IDUnqualifiedType................................................................................................................... 74

8.6.7 IDISO3166Type....................................................................................................................... 74

8.6.8 PercentType............................................................................................................................ 75

8.6.9 TextType................................................................................................................................. 75

8.6.10 QuantityType......................................................................................................................... 75

9 Schémas XML           76

9.1 Emplacement................................................................................................................................ 76

9.2 Conventions.................................................................................................................................. 76

9.2.1 Règles de nommage des fichiers.............................................................................................. 76

 

1                      Présentation

1.1                    Esppadom

Esppadom est une démarche de standardisation des échanges d’informations entre les conseils départementaux (CD) et les services d’aide à domicile (SAAD) dans le cadre de l’aide aux personnes en perte d'autonomie comme les personnes âgées ou atteintes de limitations fonctionnelles.

 

Esppadom diffuse à cet effet trois messages, nommés Order, Delivery et Invoice, destinés respectivement à transmettre de façon électronique standardisée la passation de commande, la télétransmission de validation d’intervention et la facturation.

 

Ce guide d’implémentation présente initialement le contexte commun aux trois messages avant de les détailler spécifiquement.

1.2                    Filiation des messages

Les messages Esppadom sont basés sur des messages génériques développés par UN/CEFACT, l’organisme des Nations unies chargé de la Facilitation des Procédures Commerciales et du Commerce Électronique :

 

§  Le message Esppadom Order utilise la structure du message CEFACT CrossIndustryOrder, qui décrit les lignes de commande de produits (ou services) qui doivent être livrées à un destinataire dans le cadre d’une transaction financière entre un vendeur et un acheteur.

§  Le message Esppadom Delivery s’inspire de CrossIndustryDespatchAdvice, qui relate l’acheminement d’un bien d’un site à un autre dans le cadre d’un contrat entre un vendeur et un acheteur.

§  Le message Esppadom Invoice est basé sur le message CrossIndustryInvoice, qui permet à un fournisseur de réclamer un paiement pour des produits et services livrés.

1.3                    Vocabulaire

Le vocabulaire utilisé dans ce guide d’implémentation se veut volontairement proche des termes métiers du domaine social et détaché des termes génériques commerciaux qui apparaissent dans les balises UN/CEFACT. Les termes suivants seront ainsi systématiquement utilisés :

 

Bénéficiaire

Personne à qui sont accordées les aides

Prestation

Elément atomique de ces aides auquel est attaché un prix unitaire (par exemple « 20 heures d’aide à domicile »)

Acte

Elément atomique précisant le contenu d’une prestation sans indication de prix unitaire (par exemple, « Aide au lever tous les jours de la semaine »)

Plan d’aide

Ensemble des prestations attribuées à un même bénéficiaire

Plan de charge

Ensemble des prestations d’un plan d’aide confiées à un même prestataire

Donneur d’ordre

Personne (morale ou physique) qui pilote l’attribution des aides

Prestataire

Personne (morale ou physique) qui réalise des prestations sur le terrain

Intervention

Partie d’un service, continue, spécifique à un donneur d’ordre

Payeur

Personne (morale ou physique) qui finance les aides accordées par le donneur d’ordre

1.4                    Cas d’usage

Le cas d’usage des messages Esppadom est plus large que celui des messages CEFACT dont ils ont hérité leur nom. Par exemple, le message Order ne se limite pas nécessairement à une simple passation de commande puisqu’il peut permettre de véhiculer un plan d’aide, ou une sous-partie de ce plan d’aide, tout au long du processus qui débute par sa définition à partir des besoins du bénéficiaire et s’achève à la réception par le prestataire d’une commande qui détaille son plan de charge. De la même façon, Delivery peut être utilisé pour véhiculer des éléments d’horodatage bruts en temps réel ou bien, après validation et éventuelle correction, à signaler au donneur d’ordre une intervention qui sera ultérieurement facturée.

 

L’ambition de ces messages est donc de standardiser les échanges entre tous les acteurs de la chaîne, depuis la construction du plan d’aide jusqu’à la facturation des prestations réalisées. L’autre ambition d’Esppadom est de standardiser le vocabulaire afin d’évoluer d’une prise en charge principalement quantitative à une gestion qualitative au travers d’une description fine des prestations.

1.5                    Enveloppe des messages

La norme européenne XML UN/CEFACT spécifie que chaque message doit faire l’objet d’un fichier XML dédié. Les volumétries d’échanges entre les donneurs d’ordre et les prestataires rendent cette contrainte difficile à imposer et, afin de véhiculer un ensemble de messages au sein du même fichier XML, le schéma de description des fichiers XML au format Esppadom contient toujours une balise racine qui encapsule un nombre indéterminé de messages CEFACT.

 

Le message Order contient ainsi un ensemble de blocs au format CEFACT CrossIndustryOrder :

 

<xsd:element name="order">

    <xsd:complexType>

        <xsd:sequence>

           <xsd:element maxOccurs="unbounded" name="CrossIndustryOrder" type="CrossIndustryOrderType"/>

        </xsd:sequence>

        <xsd:attribute name="versionID" type="xsd:token" use="required"/>

    </xsd:complexType>

</xsd:element>

 

De la même façon, le message Delivery contient un ensemble de blocs au format CrossIndustryDespatchAdvice :

 

<xsd:element name="delivery">

    <xsd:complexType>

        <xsd:sequence>

           <xsd:element maxOccurs="unbounded" name="CrossIndustryDespatchAdvice" type="CrossIndustryDespatchAdviceType"/>

        </xsd:sequence>

        <xsd:attribute name="versionID" type="xsd:token" use="required"/>

    </xsd:complexType>

</xsd:element>

 

Et le message Invoice contient un ensemble de blocs CrossIndustryInvoice :

 

<xsd:element name="invoice">

        <xsd:complexType>

           <xsd:sequence>

               <xsd:element  maxOccurs="unbounded" name="CrossIndustryInvoice" type="CrossIndustryInvoiceType"/>

           </xsd:sequence>

        <xsd:attribute name="versionID" type="xsd:token" use="required"/>

        </xsd:complexType>

    </xsd:element>

 

Il est convenu d’appeler transaction l’ensemble des messages CEFACT ainsi regroupés au sein d’un fichier Esppadom. Ce regroupement au sein d’un même fichier XML se fait à la discrétion de l’émetteur ; une même transaction peut, par exemple, rassembler des messages qui concernent plusieurs bénéficiaires.

 

On note que les balises racines (order, invoice et delivery) constituent une enveloppe élémentaire qui ne véhicule pas, par exemple, d’indication sur le nombre de messages qu’elle contient ou d’information de contrôle de cohérence.

 

L’attribut VersionID véhicule le numéro de version de l’enveloppe, qui ne préjuge pas de la version des messages qu’elle contient.

 

On notera qu’un fichier XML ne doit contenir qu’une seule balise racine ; il n’est pas possible de transmettre dans un même envoi des messages CrossIndustryOrder, CrossIndustryDespatchAdvice et CrossIndustryInvoice.

1.6                    Règles de gestion des messages

Ce document décrit le contenu des fichiers XML qui véhiculent les messages Esppadom, mais ne traite pas des règles d’échange (ftp, socket…) ni des processus de validation ou de traitement des erreurs. Nous nous contenterons de rappeler que tout ensemble de moyens destinés à élaborer, traiter, stocker ou transmettre des informations faisant l'objet d'échanges par voie électronique entre autorités administratives et usagers ainsi qu'entre autorités administratives doit être conforme au Référentiel Général d'Interopérabilité (RGI) publié par la Direction Interministérielle des Systèmes d’Information et de Communication (DISIC).

 

On établira par ailleurs comme règle intangible qu’un message qui n’est pas conforme au schéma xsd doit être rejeté.

1.7                    Indications de cardinalité

Le formalisme des indications de cardinalité qui apparaissent dans ce document est décrit par le tableau ci-dessous :

 

1

information (ou bloc d’informations) unique et obligatoire

1…n

information (ou bloc d’informations) obligatoire et éventuellement multiple

0…1

information (ou bloc d’informations) optionnelle et unique

0…n

information (ou bloc d’informations) optionnelle et éventuellement multiple

 

On rappellera que, dans les fichiers de schéma xsd, la cardinalité d’un élément est déterminé par les attributs minOccurs et maxOccurs dont les valeurs par défaut sont 1. Lorsqu’aucun des deux n’est précisé, l’élément est donc unique (maxOccurs="1") et obligatoire (minOccurs="1"). Ces valeurs sont définies par des entiers positifs ou nuls, sauf pour le cas où maxOccurs est indéfini, ce qui se représente sous la forme maxOccurs="unbounded".

 

Il est important de préciser que lorsqu’une balise est spécifiée comme obligatoire, elle doit nécessairement apparaître dans le message, mais peut être vide de tout contenu.

1.8                    Balises complexes

Certaines balises complexes apparaissent régulièrement au sein des messages, typiquement IDQualifiedType et CodeQualifiedType.

1.8.1   Balise de type IDQualifiedType

Le type IDQualifiedType décrit un identifiant :

 

<xsd:complexType name="IDQualifiedType">

    <xsd:simpleContent>

        <xsd:extension base="xsd:token">

           <xsd:attribute name="schemeID" type="xsd:token" use="required"/>

           <xsd:attribute name="schemeAgencyName" type="xsd:string" use="required"/>

        </xsd:extension>

    </xsd:simpleContent>

</xsd:complexType>

 

L’attribut obligatoire schemeID contient l’identifiant de la liste au sein de laquelle a été extrait cet identifiant et l’attribut également obligatoire schemeAgencyName contient le nom de l’organisation qui maintient cette liste. Par exemple :

<ID schemeID="BASE_PATIENTS" schemeAgencyName="CD37">2349564</ID>

1.8.2   Balise de type CodeQualifiedType

Le type CodeQualifiedType décrit un code au sein d’une liste préétablie :

 

<xsd:complexType name="CodeQualifiedType">

    <xsd:simpleContent>

        <xsd:extension base="xsd:token">

           <xsd:attribute name="listID" type="xsd:token" use="required"/>

           <xsd:attribute name="listAgencyName" type="xsd:string" use="required"/>

           <xsd:attribute name="name" type="xsd:string"/>

        </xsd:extension>

    </xsd:simpleContent>

</xsd:complexType>

 

Les attributs schemeID et schemeAgencyName sont identiques à celles du type IDQualifiedType, mais s’y ajoute l’attribut optionnel name qui contient le libellé correspondant au code. Par exemple :

<TypeCode schemeID="ESPPADOM_CONTACT_BENEFICIAIRE" schemeAgencyName="EDESS" name="Proche aidant">DPA</TypeCode>

 

2                      Description des personnes morales ou physiques

Les personnes morales ou physiques décrites au sein des messages Esppadom sont le prestataire, le donneur d’ordre, le bénéficiaire et le payeur. Ils sont tous décrits au sein d’Esppadom par le même le type XSD CITradePartyType et même si certains messages ne les font pas tous apparaitre, c’est un bloc récurrent qui mérite d’être décrit préalablement afin d’éviter de le détailler à l’identique pour chaque message.

2.1                    Bloc générique

Le fichier AUX_UNECE_RAM_v_ESPPADOM_PERSON_V.xsd (ou v et V représentent des numéros de versions susceptibles d’évoluer) est dédié à la spécification des données de description des personnes. On y trouve la définition du type CITradePartyType :

 

<xsd:complexType name="CITradePartyType">

    <xsd:sequence>

        <xsd:element name="ID" type="IDQualifiedType"/>

        <xsd:element name="Name" type="TextType"/>

        <xsd:element name="SIRET" type="TextType" minOccurs="0"/>

        <xsd:element name="Civility" type="CodeQualifiedType" minOccurs="0"/>

        <xsd:element name="FirstName" type="TextType" minOccurs="0"/>

        <xsd:element name="LastName" type="TextType" minOccurs="0"/>

        <xsd:element name="BirthDate" type="DateMandatoryDateTimeType" minOccurs="0"/>

        <xsd:element name="DefinedCITradeContact" type="CITradeContactType" minOccurs="0" maxOccurs="unbounded"/>

        <xsd:element name="PostalCITradeAddress" type="CITradeAddressType" minOccurs="0"/>

        <xsd:element name="ContextShipTo" type="ContextShipToType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

Soit, sous forme plus lisible :

 

 

Balise

Type

Cardinalité

Identifiant

ID

IDQualifiedType

1

SIRET

SIRET

TextType

0..1

Dénomination

Name

TextType

1

Civilité

Civility

CodeQualifiedType

0..1

Prénom

FirstName

TextType

0..1

Nom

LastName

TextType

0..1

Date de naissance

BirthDate

DateMandatoryDateTimeType

0..1

Liste de contacts

DefinedCITradeContact

CITradeContactType

0..n

Adresse postale

PostalCITradeAddress

CITradeAddressType

0..1

Contexte de délivrance

ContextShipTo

ContextShipToType

0..1

 

Les seules données obligatoires sont donc l’identifiant et la dénomination. Par ailleurs, certaines informations ne sont pertinentes que pour une personne physique (nom, prénom, date de naissance) et le contexte de délivrance, qui contient des données spécifiques au bénéficiaire comme le code GIR ou le type d’aide, n’a pas vocation à apparaitre dans la description du prestataire, du donneur d’ordre ou du payeur.

 

La civilité est à prendre dans la liste ESPPADOM_CIVILITY.

 

Par convention, lorsque la personne décrite est le bénéficiaire, on stipule que l’adresse postale représente l’adresse d’intervention. S’il était utile de distinguer une adresse de correspondance, il faudrait la déclarer au sein des contacts.

 

Par convention également, et sauf cas particulier exceptionnel, on utilisera l’intégralité du bloc pour le bénéficiaire, mais on limitera les informations de description des autres personnes (généralement morales) à la liste suivante :

 

 

Balise

Type

Cardinalité

Identifiant

ID

IDQualifiedType

1

SIRET

SIRET

TextType

0..1

Dénomination

Name

TextType

1

Liste de contacts

DefinedCITradeContact

CITradeContactType

0..n

Adresse postale

PostalCITradeAddress

CITradeAddressType

0..1

2.2                    Liste de contacts

La liste de contacts permet de préciser les personnes ressources qui, dans l’entourage d’une personne physique ou au sein d’une personne morale, ont un rôle qu’il est utile de préciser. Chaque contact est spécifié par le type CITradeContactType :

 

<xsd:complexType name="CITradeContactType">

    <xsd:sequence>

        <xsd:element name="ID" type="IDQualifiedType" minOccurs="0"/>

        <xsd:element name="PersonName" type="TextType" minOccurs="0"/>

        <xsd:element name="TypeCode" type="CodeQualifiedType" minOccurs="0"/>

        <xsd:element name="TelephoneCIUniversalCommunication" type="CIUniversalCommunicationNumberType" minOccurs="0"/>

        <xsd:element name="MobileTelephoneCIUniversalCommunication" type="CIUniversalCommunicationNumberType" minOccurs="0"/>

        <xsd:element name="EmailURICIUniversalCommunication" type="CIUniversalCommunicationUnqualifiedURIType" minOccurs="0"/>

        <xsd:element name="PostalAddress" type="CITradeAddressType" minOccurs="0"/>

        <xsd:element name="HandlingCode" type="CodeQualifiedType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

Soit :

 

 

Balise

Type

Cardinalité

Identifiant

ID

IDQualifiedType

0..1

Nom de la personne

PersonName

TextType

0..1

Rôle

TypeCode

CodeQualifiedType

0..1

Téléphone fixe

TelephoneCIUniversalCommunication

CIUniversalCommunicationNumberType

0..1

Téléphone mobile

MobileTelephoneCIUniversalCommunication

CIUniversalCommunicationNumberType

0..1

Adresse électronique

EmailURICIUniversalCommunication

CIUniversalCommunicationUnqualifiedURIType

0..1

Adresse postale

PostalAddress

CITradeAddressType

0..1

Profil

HandlingCode

CodeQualifiedType

0..1

 

On remarque qu’aucune des informations n’est obligatoire ; en effet, un contact peut représenter une personne à part entière, avec sa dénomination et son adresse, ou bien simplement un complément d’information de la personne physique ou morale, par exemple son numéro de téléphone ou son adresse électronique.

 

Le rôle du contact peut être spécifié en sélectionnant un code au sein de listes préétablies qui sont spécifiques du type de personne à laquelle ce contact est attaché :

 

ESPPADOM_CONTACT_BENEFICIAIRE pour les contacts du bénéficiaire

ESPPADOM_CONTACT_DONNEUR_ORDRE pour les contacts du donneur d’ordre

ESPPADOM_CONTACT_PAYEUR pour les contacts du payeur

ESPPADOM_CONTACT_PRESTATAIRE pour les contacts du prestataire

 

La notion de profil est surtout destinée à permettre, au sein du message Delivery, la comparaison entre la qualification de l’intervenant et celle qui avait été spécifiée au sein du message Order au sein de la balise :

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / SpecifiedCIOLSupplyChainTradeDelivery / DeliveryCIDeliveryInstructions / HandlingCode

2.3                    Gestion des adresses

Les adresses (physiques ou « postales ») sont décrites par le type CITradeAddressType :

 

<xsd:complexType name="CITradeAddressType">

    <xsd:sequence>

        <xsd:element name="LineOne" type="TextType"/>

        <xsd:element name="LineTwo" type="TextType" minOccurs="0"/>

        <xsd:element name="PostcodeCode" type="CodePostCodeType" minOccurs="0"/>

        <xsd:element name="CityName" type="TextType"/>

        <xsd:element name="CountryID" type="IDISO3166Type"/>

    </xsd:sequence>

</xsd:complexType>

 

Soit :

 

 

Balise

Type

Cardinalité

Première ligne d’adresse

LineOne

TextType

1

Seconde ligne d’adresse

LineTwo

TextType

0..1

Code postal

PostcodeCode

CodePostCodeType

0..1

Ville

CityName

TextType

1

Pays

CountryID

IDISO3166Type

1

 

Cette description ne contient pas de nom de destinataire postal, et on conviendra d’utiliser à cette fin l’information « Name » pour les personnes ou l’information « PersonName » pour les contacts.

 

Le code ISO 3166 pour la France est "FR".

2.4                    Contexte de délivrance

Le contexte de délivrance ne doit apparaitre qu’au sein de la description du bénéficiaire.

 

<xsd:complexType name="ContextShipToType">

    <xsd:sequence>

        <xsd:element name="GIR" type="CodeQualifiedType" minOccurs="0"/>

        <xsd:element name="TypeBeneficiaire" type="CodeQualifiedType" minOccurs="0"/>

        <xsd:element name="GeographicSector" type="IDQualifiedType" minOccurs="0"/>

        <xsd:element name="AdditionnalInformation" type="CIAdditionalInformationType" minOccurs="0" maxOccurs="unbounded"/>

    </xsd:sequence>

</xsd:complexType>

 

 

Balise

Type

Cardinalité

Score GIR

GIR

CodeQualifiedType

0..1

Type de bénéficiaire

TypeBeneficiaire

CodeQualifiedType

0..1

Secteur géographique

GeographicSector

IDQualifiedType

0..1

Information additionnelle

AdditionnalInformation

CIAdditionalInformationType

0..n

 

Le GIR et le type de bénéficiaire sont à prendre respectivement au sein des listes ESPADDOM_GIR et ESPPADOM_TYPE_BENEFICIAIRE.

 

De nombreux départements mettent en place un découpage géographique qui permet d’attribuer des prestataires particuliers en fonction de l’adresse du bénéficiaire. La variable secteur géographique permet d’indiquer l’identifiant du secteur auquel le bénéficiaire appartient.

 

Le découpage géographique est suffisamment généralisé pour justifier une balise spécifique. On peut imaginer que certains donneurs d’ordre trouveraient utile de préciser d’autres identifiants plus spécifiques. Par exemple un « numéro de dossier papier ». Le bloc AdditionnalInformation a été créé afin de gérer ce type de cas sans qu’il soit nécessaire de faire évoluer le schéma du message.

 

Le type CIAdditionalInformationType permet de décrire trois types d’informations : deux balises obligatoires, Type et Content, qui contiennent respectivement le type d’information à décrire, à prendre dans ESPPADOM_ADDITIONNAL_INFORMATION, et l’identifiant ou le code attribué à ce bénéficiaire et une balise facultative, Label, qui permet de préciser le libellé qui correspond à ce code.

 

<xsd:complexType name="CIAdditionalInformationType">

    <xsd:sequence>

        <xsd:element name="Type" type="CodeQualifiedType"/>

        <xsd:element name="Label" type="TextType" minOccurs="0"/>

        <xsd:element name="Content" type="TextType"/>

    </xsd:sequence>

</xsd:complexType>

 

3                      Message ORDER

3.1                    Structure du message

Le message Order, qui décrit un bon de commande ou, plus génériquement, tout ou partie d’un plan d’aide, a été développé dans le contexte « de cardinalité » suivant :

 

§  1 plan d’aide est géré par 1 donneur d’ordre et concerne 1 bénéficiaire.

§  1 plan d’aide donne droit à 1 à n prestation(s)

§  1 prestation est réalisée par 1 Prestataire

§  1 prestataire possède 1 Adresse et 1 Responsable

§  1 donneur d’ordre possède 1 Adresse et 1 Responsable

§  1 Bénéficiaire possède 1 Adresse

 

Les informations correspondantes sont détaillées dans le schéma historique ci-dessous :

 

 

 

 

Un message ORDER contient six blocs d’informations qui décrivent respectivement la commande (identifiant, date…), le prestataire, le donneur d’ordre, le bénéficiaire, les conditions financières et, finalement, la liste des prestations à réaliser. Nous allons les détailler en précisant leur place dans le message et en donnant des exemples d’implémentations.

3.2                    Architecture

Nous avons déjà précisé que le message Esppadom ORDER est basé sur le message UN/CEFACT CrossIndustryOrder, auquel il ajoute quelques éléments spécifiques au contexte d’utilisation.

 

La description XSD Esppadom de la balise CrossIndustryOrder est la suivante :

 

<xsd:complexType name="CrossIndustryOrderType">

    <xsd:sequence>

        <xsd:element name=" CIOHExchangedDocumentContext " type=" CIOHExchangedDocumentContextType "/>

        <xsd:element name="CIOHExchangedDocument" type="CIOHExchangedDocumentType"/>

        <xsd:element name="CIOHSupplyChainTradeTransaction" type="CIOHSupplyChainTradeTransactionType"/>

    </xsd:sequence>

</xsd:complexType>

 

Soit deux balises de gestion documentaire, CIExchangedDocumentContext et CIOHExchangedDocument, suivies du contenu du document : CIOHSupplyChainTradeTransaction :

 

Balise

Type

Cardinalité

CIOHExchangedDocumentContext

CIOHExchangedDocumentContextType

1

CIOHExchangedDocument

CIOHExchangedDocumentType

1

CIOHSupplyChainTradeTransaction

CIOHSupplyChainTradeTransactionType

1

 

Si nous détaillons la dernière balise, nous voyons apparaitre les quatre blocs descriptifs : les opérateurs (prestataire et donneur d’ordre), les précisions de délivrance (bénéficiaire et contexte), les conditions financières (payeur, montants…) et enfin la liste des prestations à effectuer.

 

<xsd:complexType name="CIOHSupplyChainTradeTransactionType">

    <xsd:sequence>

        <xsd:element name="ApplicableCIOHSupplyChainTradeAgreement" type="CIOHSupplyChainTradeAgreementType"/>

        <xsd:element name="ApplicableCIOHSupplyChainTradeDelivery" type="CIOHSupplyChainTradeDeliveryType"/>

        <xsd:element name="ApplicableCIOHSupplyChainTradeSettlement" type="CIOHSupplyChainTradeSettlementType"/>

        <xsd:element name="IncludedCIOLSupplyChainTradeLineItem" type="CIOLSupplyChainTradeLineItemType" maxOccurs="unbounded"/>

    </xsd:sequence>

</xsd:complexType>

 

Balise

Type

Cardinalité

ApplicableCIOHSupplyChainTradeAgreement

CIOHSupplyChainTradeAgreementType

1

ApplicableCIOHSupplyChainTradeDelivery

CIOHSupplyChainTradeDeliveryType

1

ApplicableCIOHSupplyChainTradeSettlement

CIOHSupplyChainTradeSettlementType

1

IncludedCIOLSupplyChainTradeLineItem

CIOLSupplyChainTradeLineItemType

1..n

 

L’architecture globale du message est ainsi représentée par le schéma ci-dessous :

 

 

Ou, si nous détaillons le bloc ApplicableCIOHSupplyChainTradeAgreement :

 

 

Nous garderons, dans la suite du document ces codes couleur afin de faire ressortir les informations qui concernent la gestion documentaire, le prestataire, le donneur d’ordre, le bénéficiaire, les conditions financières et, finalement, la liste des prestations à réaliser.

3.3                    Message minimal

L’exemple ci-dessous montre un message Order « maigre », qui ne contient qu’une seule ligne de prestation et un nombre aussi réduit que possible d’informations optionnelles.

 

<order VersionID="1.2">

    <CrossIndustryOrder>

 

        <CIOHExchangedDocumentContext>

           <VersionID>1.2</ VersionID >

           <SpecifiedTransactionID>1297</SpecifiedTransactionID>

           < OrderContextParameter >

               <CommitteeDateTime>2015-05-01T00:00:00Z</CommitteeDateTime>

           </ OrderContextParameter >

        </CIOHExchangedDocumentContext>

        <CIOHExchangedDocument>

           <ID>0500254</ID>

           <TypeAide schemeAgencyName="EDESS" schemeID="ESPPADOM_TYPE_AIDE">APA</TypeAide>

           <IssueDateTime>2015-06-22T00:00:00Z</IssueDateTime>

           <EffectiveCISpecifiedPeriod>

               <StartDateTime>2015-07-01T00:00:00Z</StartDateTime>

               <EndDateTime>2020-12-31T00:00:00Z</EndDateTime>

           </EffectiveCISpecifiedPeriod>

        </CIOHExchangedDocument>

GED :

ID de transaction

 

Date de décision du plan d’aide

 

 

ID de commande

Date d’émission

 

Période de validité

        <CIOHSupplyChainTradeTransaction>

           <ApplicableCIOHSupplyChainTradeAgreement>

 

               <SellerCITradeParty>

                   <ID schemeAgencyName="token" schemeID="token"></ID>

                   <Name>Prest Domicile SARL</Name>

               </SellerCITradeParty>

Prestataire :

ID pour le donneur d’ordre

               <BuyerCITradeParty>

                   <ID schemeAgencyName="token" schemeID="token"></ID>

                   <Name>Conseil Général du Grand Paris</Name>

               </BuyerCITradeParty>

Donneur d’ordre

           </ApplicableCIOHSupplyChainTradeAgreement>

           <ApplicableCIOHSupplyChainTradeDelivery>

 

               <ShipToCITradeParty>

                   <ID schemeAgencyName="token" schemeID="token">2612430</ID>

                   <Name>ALITON Jean-Jacques</Name>

                   <Civility schemeAgencyName="EDESS" schemeID="ESPPADOM_CIVI">MR</ID>

                   <FirstName>Jean-Jacques</FirstName>

                   <LastName>ALITON</LastName>

                   <BirthDate>1980-05-01T00:00:00Z</BirthDate>

                   <PostalCITradeAddress>

                         <PostcodeCode>16500</PostcodeCode>

                         <LineOne>Le bourg</LineOne>

                         <CityName>ST GERMAIN DE CONFOLENS</CityName>

                   </PostalCITradeAddress>

                   <ContextShipTo>

                         <GIR>3</GIR>

                   </ContextShipTo>

               </ShipToCITradeParty>

Bénéficiaire :

ID pour le donneur d’ordre

           </ApplicableCIOHSupplyChainTradeDelivery>

           <ApplicableCIOHSupplyChainTradeSettlement>

 

               <PayerCITradeParty>

                   <ID schemeAgencyName="token" schemeID="token"></ID>

                   <Name>INTERNATIONAL ASSISTANCE</Name>

               </PayerCITradeParty>

Organisme payeur :

ID pour le donneur d’ordre

           </ApplicableCIOHSupplyChainTradeSettlement>

 

           <IncludedCIOLSupplyChainTradeLineItem>

               <AssociatedCIOLDocumentLineDocument>

                   <LineID>2565AL1</LineID>

               </AssociatedCIOLDocumentLineDocument>

               <SpecifiedCIOLSupplyChainTradeAgreement>

                   <NetPriceProductCITradePrice>

                         <ChargeAmount currencyID=”EUR”>20.0</ChargeAmount>

                   </NetPriceProductCITradePrice>

                   <ID schemeAgencyName="EDESS" schemeID="ESPPADOM_CADRE">PRE</ID>

               </SpecifiedCIOLSupplyChainTradeAgreement>

               <SpecifiedCIOLSupplyChainTradeDelivery>

                   <RequestedQuantity unitCode="HUR">25.0</RequestedQuantity>

               </SpecifiedCIOLSupplyChainTradeDelivery>

               <SpecifiedCITradeProduct>

                   <ID schemeAgencyName="EDESS" schemeID="ESPPADOM_PREST">0211.01</ID>

                   <Name>Aide au domicile</Name>

               </SpecifiedCITradeProduct>

           </IncludedCIOLSupplyChainTradeLineItem>

Prestation :

 

Identifiant de la prestation

 

Prix unitaire brut de l’unité de valeur

Mode prestataire

 

Nombre d’unités de valeur (ici des heures)

 

 

Qualification de la prestation

        </CIOHSupplyChainTradeTransaction>

    </CrossIndustryOrder>

</order>

 

 

Nous allons maintenant détailler l’ensemble du message, en commençant par le contexte documentaire du message.

3.4                    Contexte : transaction et identification de la commande

Le premier bloc d’informations du message, obligatoire, traite de données générales (dites « de contexte ») de la commande

3.4.1   Transaction

<xsd:complexType name=" CIOHExchangedDocumentContextType ">

    <xsd:sequence>

        <xsd:element name="VersionID" type="xsd:token"/>

        <xsd:element name="SpecifiedTransactionID" type="IDUnqualifiedType"/>

        <xsd:element name=" OrderContextParameter " type=" CIOHDocumentContextParameterType " minOccurs="0" maxOccurs="unbounded"/>

    </xsd:sequence>

</xsd:complexType>

 

La première information, obligatoire, rencontrée dans un message précise la version du schéma xsd auquel ce message est conforme.

CrossIndustryOrder / CIOHExchangedDocumentContextType / VersionID

 

La seconde information précise l’identifiant de transaction.

CrossIndustryOrder / CIOHExchangedDocumentContextType / SpecifiedTransactionID

Comme nous l’avons déjà précisé, cette information obligatoire est purement technique puisqu’elle sert, pour des raisons de traçabilité à rattacher la commande (qui est représentée par un bloc CrossIndustryOrder) au lot des autres fichiers envoyés simultanément. Tous les messages CrossIndustryOrder situés au sein d’un même fichier xml order doivent donc avoir un même identifiant de transaction.

 

Suit, dans le même chapitre du « contexte d’échange » un bloc d’informations optionnelles qui précisent le contexte d’application du document.

CrossIndustryOrder / CIOHExchangedDocumentContextType / OrderContextParameter

On peut y noter la date de la décision d’accord de la prise en charge :

CrossIndustryOrder / CIExchangedDocumentContext / OrderContextParameter / CommitteeDateTime

On trouve ensuite le bloc, obligatoire, qui contient les informations de commande :

3.4.2   Commande

La description dématérialisée de l’entête de la commande s’effectue dans le bloc CIOHExchangedDocument :

 

<xsd:complexType name="CIOHExchangedDocumentType">

    <xsd:sequence>

        <xsd:element name="ID" type="IDUnqualifiedType"/>

        <xsd:element name="TypeAide" type="CodeQualifiedType"/>

        <xsd:element name="IssueDateTime" type="DateMandatoryDateTimeType"/>

        <xsd:element name="IncludedCINote" type="CINoteType" minOccurs="0"/>

        <xsd:element name="EffectiveCISpecifiedPeriod" type="CISpecifiedPeriodType"/>

    </xsd:sequence>

</xsd:complexType>

 

Le numéro de commande est une information obligatoire générée par le donneur d’ordre.

CrossIndustryOrder / CIOHExchangedDocument / ID

Suit le type d’aide accordé (APA, PCH…), information obligatoire à choisir au sein de la liste ESPPADOM_TYPE_AIDE :

CrossIndustryOrder / CIOHExchangedDocument / TypeAide

Puis la date du bon de commande, information obligatoire qui contient la date d’émission (et non, par exemple, la date de création de la commande).

CrossIndustryOrder / CIOHExchangedDocument / IssueDateTime

Un bloc optionnel permet de préciser une note en texte libre.

CrossIndustryOrder / CIOHExchangedDocument / IncludedCINote

 

Ensuite, un bloc obligatoire contient les bornes de validité de la prise en charge. Si la prise en charge n’a pas de période de validité spécifique, ce bloc contiendra les dates de début et de fin du plan d’aide :

CrossIndustryOrder / CIOHExchangedDocument / EffectiveCISpecifiedPeriod

Il s’agit d’un intervalle de dates qui est global, unique et obligatoire. Il est déterminé par une date de début et une date de fin (toutes deux obligatoires) :

CrossIndustryOrder / CIOHExchangedDocument / EffectiveCISpecifiedPeriod / StartDateTime

CrossIndustryOrder / CIOHExchangedDocument / EffectiveCISpecifiedPeriod / EndDateTime

3.5                    Prestataire et donneur d’ordre

Nous quittons les informations documentaires et entrons maintenant dans le « corps » de la commande

CrossIndustryOrder / CIOHSupplyChainTradeTransaction

et plus précisément dans les informations qui décrivent les opérateurs : prestataire et donneur d’ordre

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / ApplicableCIOHSupplyChainTradeAgreement

La description XSD de ce bloc est la suivante :

 

<xsd:complexType name="CIOHSupplyChainTradeAgreementType">

    <xsd:sequence>

        <xsd:element name="SellerCITradeParty" type="CITradePartyType"/>

        <xsd:element name="BuyerCITradeParty" type="CITradePartyType"/>

        <xsd:element name="ContractReferencedCIReferencedDocument" type="CIReferencedDocumentType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

Balise

Type

Cardinalité

SellerCITradeParty

CITradePartyType

1

BuyerCITradeParty

CITradePartyType

1

ContractReferencedCIReferencedDocument

CIReferencedDocumentType

0..1

 

Soit :

§  2 CITradePartyType, qui représentent des personnes (morales ou physiques) : le prestataire (SellerCITradeParty) et le donneur d’ordre (BuyerCITradeParty).

§  1 CIReferencedDocumentType, qui représente l’identifiant d’un document externe : le contrat entre ces parties.

3.5.1   Prestataire

Le premier acteur décrit est le prestataire, celui qui exécutera la prise en charge.

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / ApplicableCIOHSupplyChainTradeAgreement / SellerCITradeParty

Ce bloc d’information est obligatoire.

 

Dans les cas d’usage où le message est utilisé pour transmettre un plan d’aide ou des éléments de plan d’aide en amont de la commande, il est laissé à la discrétion de l’émetteur et du récepteur de convenir d’une convention d’utilisation des deux balises obligatoires ID et name, soit en les laissant vides, soit en définissant un couple de valeurs spécifique pour les cas où le prestataire n’est pas attribué.

 

La balise SellerCITradeParty contient trois blocs de données : l’identification du prestataire tel qu’il est connu par le donneur d’ordre, qui est obligatoire, ainsi que deux ensembles de données optionnelles : une liste de contacts au sein du prestataire et l’adresse postale du prestataire.

 

Ces trois blocs ont été décrits au chapitre 2.

3.5.2   Donneur d’ordre et contrat

Le donneur d’ordre est décrit au sein du bloc de données obligatoire

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / ApplicableCIOHSupplyChainTradeAgreement / BuyerCITradeParty

Il contient la même structure d’informations que le prestataire, avec l’identification du donneur d’ordre, qui est obligatoire, ainsi que deux ensembles de données optionnelles : une liste de contacts au sein du donneur d’ordre (dont le type est à choisir dans la liste ESPPADOM_CONTACT_DONNEUR_ORDRE) et l’adresse postale du donneur d’ordre.

 

Le bloc de données décrivant le donneur d’ordre est suivi par un bloc optionnel qui permet de fournir l’adresse électronique du contrat qui lie les intervenants.

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / ApplicableCIOHSupplyChainTradeAgreement / ContractReferencedCIReferencedDocument

Ce chapitre, au format CIReferencedDocumentType ne contient qu’un seul élément, nommé GlobalID afin de préciser l’identifiant de contrat :

 

<xsd:complexType name="CIReferencedDocumentType">

    <xsd:sequence>

        <xsd:element name="GlobalID" type="IDQualifiedType"/>

    </xsd:sequence>

</xsd:complexType>

 

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / ApplicableCIOHSupplyChainTradeAgreement / ContractReferencedCIReferencedDocument / GlobalID

Le chapitre ApplicableCIOHSupplyChainTradeAgreement, qui précise les intervenants au contrat et la nature du contrat se clôt à ce stade et nous entrons dans le chapitre des instructions de délivrance des prestations au sein duquel se trouve le bénéficiaire.

3.6                    Bénéficiaire

Le type CIOHSupplyChainTradeDeliveryType ne contient qu’une seule balise qui permet de décrire le bénéficiaire :

 

<xsd:complexType name="CIOHSupplyChainTradeDeliveryType">

    <xsd:sequence>

        <xsd:element name="ShipToCITradeParty" type="CITradePartyType"/>

    </xsd:sequence>

</xsd:complexType>

 

Le bénéficiaire est décrit au chapitre

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / ApplicableCIOHSupplyChainTradeDelivery / ShipToCITradeParty

Ce bloc d’informations, au format CITradePartyType a déjà été décrit au chapitre 2.

3.7                    Conditions financières

Les informations financières sont précisées au sein du bloc

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / ApplicableCIOHSupplyChainTradeSettlement

Elles sont décrites par le type CIOHSupplyChainTradeSettlementType :

 

<xsd:complexType name="CIOHSupplyChainTradeSettlementType">

    <xsd:sequence>

        <xsd:element name="PayerCITradeParty" type="CITradePartyType"/>

        <xsd:element name="SpecifiedCIOHTradeSettlementMonetarySummation" type="CIOHTradeSettlementMonetarySummationType" minOccurs="0"/>

        <xsd:element name="PayableSpecifiedCITradeAccountingAccount" type="CITradeAccountingAccountType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

 

Balise

Type

Cardinalité

Payeur

PayerCITradeParty

CITradePartyType

1

Montant

SpecifiedCIOHTradeSettlementMonetarySummation

CIOHTradeSettlementMonetarySummationType

0..1

Imputation comptable

PayableSpecifiedCITradeAccountingAccount

CITradeAccountingAccountType

0..1

 

Elles permettent de décrire l’organisme payeur, le montant maximal pris en charge et la référence d’imputation comptable à rappeler dans les documents liés à la facturation.

3.7.1   Description du payeur

La première partie, unique et obligatoire, concerne la description du payeur, l’entité qui sera facturée.

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / ApplicableCIOHSupplyChainTradeSettlement / PayerCITradeParty

Le payeur, au format CITradePartyType est conforme à la description du chapitre 2.

3.7.2   Montant et imputation

Le montant maximum pris en charge, optionnel, est attaché au chemin :

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / ApplicableCIOHSupplyChainTradeSettlement / SpecifiedCIOHTradeSettlementMonetarySummation / ChargeTotalAmount

<xsd:complexType name="CIOHTradeSettlementMonetarySummationType">

    <xsd:sequence>

        <xsd:element name="ChargeTotalAmount" type="AmountType"/>

    </xsd:sequence>

</xsd:complexType>

 

La balise ChargeTotalAmount, au format AmountType inclut une variable qui permet de préciser la monnaie utilisée en utilisant la norme ISO 4217 pour remplir le « token » currencyID. Le code pour l’Euro est EUR. Par exemple :

<ChargeTotalAmount currencyID="EUR">200.0</ChargeTotalAmount>

La référence d’imputation comptable, à rappeler dans les bons de livraison, et dans les factures est attachée au chemin :

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / ApplicableCIOHSupplyChainTradeSettlement / PayableSpecifiedCITradeAccountingAccount / ID

Il permet simplement de préciser un identifiant :

 

<xsd:complexType name="CITradeAccountingAccountType">

    <xsd:sequence>

        <xsd:element name="ID" type="IDUnqualifiedType"/>

    </xsd:sequence>

</xsd:complexType>

3.8                    Liste des prestations à réaliser

La liste des prestations à réaliser (les « lignes de la commande ») occupent un bloc multiple et obligatoire.

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem

<xsd:complexType name="CIOLSupplyChainTradeLineItemType">

    <xsd:sequence>

        <xsd:element name="AssociatedCIOLDocumentLineDocument" type="CIOLDocumentLineDocumentType"/>

        <xsd:element name="SpecifiedCIOLSupplyChainTradeAgreement" type="CIOLSupplyChainTradeAgreementType"/>

        <xsd:element name="SpecifiedCIOLSupplyChainTradeDelivery" type="CIOLSupplyChainTradeDeliveryType"/>

        <xsd:element name="SpecifiedCIOLSupplyChainTradeSettlement" type="CIOLSupplyChainTradeSettlementType" minOccurs="0"/>

        <xsd:element name="SpecifiedCITradeProduct" type="CITradeProductType"/>

        <xsd:element name="SpecifiedCITradeProductDetails" type="CITradeDetailType" minOccurs="0" maxOccurs="unbounded"/>

        <xsd:element name="SpecifiedCITradeLineChange" type="CITradeLineChangeType" minOccurs="0" maxOccurs="unbounded"/>

    </xsd:sequence>

</xsd:complexType>

 

Si le bon de commande ne contient qu’un seul service, il n’y aura qu’une seule ligne au bon de commande, et ce bloc sera unique ; si plusieurs services sont commandés, il y aura autant de blocs IncludedCIOLSupplyChainTradeLineItem que de services.

 

Dans le cas où un même service serait rendu selon un calendrier qui inclut différentes périodes de tarification, par exemple « en semaine et le week-end », il est conseillé de le découper en plusieurs lignes afin que les messages ultérieurs qui y font référence, typiquement INVOICE qui comprendra nécessairement une ligne par catégorie de tarification, puissent référencer plus finement l’élément de commande qui les justifie.

 

Chaque ligne contient sept ensembles d’informations : l’identification de la ligne, le prix unitaire, les informations de mise en œuvre, les conditions financières, la description du service, la liste optionnelle des actes qui composent la prestation et la liste des modifications.

 

 

Balise

Type

Cardinalité

Identification

AssociatedCIOLDocumentLineDocument

CIOLDocumentLineDocumentType

1

Agrément financier

SpecifiedCIOLSupplyChainTradeAgreement

CIOLSupplyChainTradeAgreementType

1

Mise en œuvre

SpecifiedCIOLSupplyChainTradeDelivery

CIOLSupplyChainTradeDeliveryType

1

Conditions financières

SpecifiedCIOLSupplyChainTradeSettlement

CIOLSupplyChainTradeSettlementType

0..1

Description

SpecifiedCITradeProduct

CITradeProductType

1

Actes

SpecifiedCITradeProductDetails

CITradeDetailType

0..1

Modifications

SpecifiedCITradeLineChange

CITradeLineChangeType

0..1

 

3.8.1   Identification

Le premier élément d’une ligne de commande est un bloc d’identification, unique et obligatoire :

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / AssociatedCIOLDocumentLineDocument

<xsd:complexType name="CIOLDocumentLineDocumentType">

    <xsd:sequence>

        <xsd:element name="LineID" type="IDUnqualifiedType"/>

        <xsd:element name="IncludedCINote" type="CINoteType" minOccurs="0"/>

        <xsd:element name="EffectiveCISpecifiedPeriod" type="CISpecifiedPeriodType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

L’identification comprend l’identifiant de la prestation, unique et obligatoire, ainsi que deux éléments uniques et optionnels : une note en texte libre et une période de validité de cette ligne de commande, à renseigner si elle est différente de celle qui a été précisée pour l’ensemble de la commande (chemin CrossIndustryOrder / CIOHExchangedDocument / IssueDateTime / EffectiveCISpecifiedPeriod).

 

L’identifiant de la prestation est attaché au chemin

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / AssociatedCIOLDocumentLineDocument / LineID

Cet identifiant doit référencer la prestation de façon absolue au sein du plan d’aide. Ce n’est explicitement pas un identifiant défini dans le contexte local de cette commande (par exemple, troisième prestation de la commande).

 

La note optionnelle est attachée au chemin

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / AssociatedCIOLDocumentLineDocument / IncludedCINote / Content

La période de validité du service commandé à cette ligne est représentée par une date de début et une date de fin. Cette période doit être située au sein du plan d’aide ; si la prestation doit débuter à une date précise sans date de fin explicite, alors EndDateTime doit contenir la date de fin du plan d’aide :

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / AssociatedCIOLDocumentLineDocument / EffectiveCISpecifiedPeriod / StartDateTime

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / AssociatedCIOLDocumentLineDocument / EffectiveCISpecifiedPeriod / EndDateTime

3.8.2   Agrément financier

Les données financières du service décrit par cette ligne sont précisées dans un bloc unique et obligatoire :

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / SpecifiedCIOLSupplyChainTradeAgreement

<xsd:complexType name="CIOLSupplyChainTradeAgreementType">

    <xsd:sequence>

        <xsd:element name="NetPriceProductCITradePrice" type="CITradePriceType"/>

        <xsd:element name="CadreIntervention" type="CodeQualifiedType"/>

    </xsd:sequence>

</xsd:complexType>

 

Il contient le prix unitaire, information monétaire unique et obligatoire :

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / SpecifiedCIOLSupplyChainTradeAgreement / NetPriceProductCITradePrice / ChargeAmount

<xsd:complexType name="CITradePriceType">

    <xsd:sequence>

        <xsd:element name="ChargeAmount" type="AmountType"/>

    </xsd:sequence>

</xsd:complexType>

 

Ce prix unitaire brut est fixé par le donneur d’ordre. L’unité de valeur à laquelle se réfère ce prix unitaire (par exemple « par heure », « par visite ») est fixée au sein de la balise RequestedQuantity décrite ci-dessous.

 

L’autre information d’agrément financier pour cette prestation est le cadre d’intervention (mandataire, prestataire, gré à gré), à choisir au sein de la liste ESPPADOM_CADRE.

3.8.3   Informations de mise en œuvre

Les informations de mise en œuvre sont décrites dans un bloc unique et obligatoire :

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / SpecifiedCIOLSupplyChainTradeDelivery

<xsd:complexType name="CIOLSupplyChainTradeDeliveryType">

    <xsd:sequence>

        <xsd:element name="RequestedQuantity" type="QuantityType"/>

        <xsd:element name="AgreedQuantity" type="QuantityType" minOccurs="0"/>

        <xsd:element name="DeliveryCIDeliveryInstructions" type="CIDeliveryInstructionsType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

La première donnée précisée, unique et obligatoire, est la quantité globale commandée.

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / SpecifiedCIOLSupplyChainTradeDelivery / RequestedQuantity

Il s’agit d’une information numérique, qui comme toutes les données chiffrées non monétaires, inclut une variable unitCode afin de préciser en quelle unité est exprimée cette quantité, en utilisant la liste UN/CEFACT Recommandation 20 version 09B. C’est cette unité qui fait référence pour le prix unitaire fixé par la balise ChargeAmount décrite ci-dessus.

 

Il est ensuite possible, de façon optionnelle et unique, de préciser la quantité plafond de chaque livraison, qui correspond à la quantité maximale financée par le donneur d’ordre.

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / SpecifiedCIOLSupplyChainTradeDelivery / AgreedQuantity

Il est également possible, de façon optionnelle et unique, de décrire un bloc d’instructions pour l’exécution du service et de sa livraison.

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / SpecifiedCIOLSupplyChainTradeDelivery / DeliveryCIDeliveryInstructions

<xsd:complexType name="CIDeliveryInstructionsType">

    <xsd:sequence>

        <xsd:element name="HandlingCode" type="CodeQualifiedType" minOccurs="0" maxOccurs="1"/>

        <xsd:element name="Description" type="UNECE_UDT_9p0:TextType" minOccurs="0"  maxOccurs="1"/>

        <xsd:element name="RRule" type="TextType" minOccurs="0" maxOccurs="1"/>

    </xsd:sequence>

</xsd:complexType>

 

Les instructions sont de deux types : le profil des employés devant intervenir, qui est unique et optionnel, utilise la liste ESPPADOM_PROFIL

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / SpecifiedCIOLSupplyChainTradeDelivery / DeliveryCIDeliveryInstructions / HandlingCode

et la temporalité du service

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / SpecifiedCIOLSupplyChainTradeDelivery / DeliveryCIDeliveryInstructions /  Description

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / SpecifiedCIOLSupplyChainTradeDelivery / DeliveryCIDeliveryInstructions / RRule

La temporalité se décrit au sein de deux éléments, uniques et optionnels. L’élément Description contient un texte libre, alors que l’élément RRule utilise le format structuré RRULE.

3.8.4   Conditions financières

Les conditions financières sont décrites dans un bloc unique et optionnel :

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / SpecifiedCIOLSupplyChainTradeSettlement

<xsd:complexType name="CIOLSupplyChainTradeSettlementType">

    <xsd:sequence>

        <xsd:element name="SpecifiedCITradeAllowanceCharge" type="CITradeAllowanceChargeType"/>

    </xsd:sequence>

</xsd:complexType>

 

Il est possible d’y décrire les charges additionnelles ou les montants prépayés (ticket modérateur), qui est un bloc unique et obligatoire :

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / SpecifiedCIOLSupplyChainTradeSettlement / SpecifiedCITradeAllowanceCharge

<xsd:complexType name="CITradeAllowanceChargeType">

    <xsd:sequence>

        <xsd:choice>

           <xsd:element name="CalculationPercent" type="PercentType"/>

           <xsd:element name="ActualAmount" type="AmountType"/>

        </xsd:choice>

        <xsd:element name="ReasonCode" type="AdjustmentReasonCodeUNCL4465Type"/>

    </xsd:sequence>

</xsd:complexType>

 

Cette information peut être spécifiée, en pourcentage ou en montant fixe, les deux informations étant mutuellement exclusives :

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / SpecifiedCIOLSupplyChainTradeSettlement / SpecifiedCITradeAllowanceCharge / CalculationPercent

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / SpecifiedCIOLSupplyChainTradeSettlement / SpecifiedCITradeAllowanceCharge / ActualAmount

 

Enfin, une balise unique et obligatoire permet de préciser le motif de l’ajustement :

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / SpecifiedCIOLSupplyChainTradeSettlement / SpecifiedCITradeAllowanceCharge / ReasonCode

Cette donnée est arbitrairement fixée à « 30 », qui signifie « paiement direct au prestataire ».

3.8.5   Description du service

La description du service est effectuée dans un bloc unique et obligatoire :

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / SpecifiedCITradeProduct

<xsd:complexType name="CITradeProductType">

    <xsd:sequence>

        <xsd:element name="ID" type="IDQualifiedType"/>

        <xsd:element name="Name" type="TextType"/>

    </xsd:sequence>

</xsd:complexType>

 

Ce bloc contient deux informations, l’identifiant du service et son libellé ; ces deux informations sont uniques et obligatoires.

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / SpecifiedCITradeProduct / ID

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / SpecifiedCITradeProduct / Name

L’ID est, comme toujours, du type schemeID (identifiant) et schemeAgencyName (libellé) ; le Name est un libellé en texte libre.

3.8.6   Actes qui constituent des consignes au sein de la prestation

La notion de « plan d’aide qualitatif » amène à pouvoir signaler, au sein d’une prestation générique définie par un nombre d’heure, par exemple « Aide à domicile », un ensemble d’actes qui constituent des points importants, ou des consignes, comme « aide aux repas du lundi au vendredi », « aide à la toilette du lundi au vendredi », « aide au lever le WE ».

 

Ces actes ne sont pas assimilables à des prestations au sens où elles ne portent pas d’informations horaires ou financières. Il s’agit bien d’un ensemble de consignes (pendant le temps imparti, il faut au moins faire ceci ou cela, ce qui induit telle ou telle contrainte – par exemple, dans le cas de l’aide au lever, effectuer la prestation à une heure compatible avec le rythme de vie de la personne). Dans ce cadre d’une évolution d’une logique purement quantitative vers une démarche qui « injecte » des consignes qualitatives, il ne faut surtout pas interpréter cette liste d’actes comme une décomposition de la plage horaire en tâches unitaires.

 

La description de ces actes est multiple et optionnelle.

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / SpecifiedCITradeProductDetails

Cette balise est de type CITradeDetailType :

 

<xsd:complexType name="CITradeDetailType">

    <xsd:sequence>

        <xsd:element name="DetailLineID" type="IDUnqualifiedType"/>

        <xsd:element name="ID" type=”CodeQualifiedType"/>

        <xsd:element name="Name" type="TextType"/>

        <xsd:element name="DeliveryInstruction" type="CIOLSupplyChainTradeDeliveryType"/>

    </xsd:sequence>

</xsd:complexType>

 

Il est ainsi possible de décrire un acte en lui attribuant un identifiant unique (qu’on pourra, par exemple, rappeler dans le message Delivery), un identifiant au sein de la liste ESPPADOM_SERVICE, un libellé, et un bloc DeliveryInstruction identique à celui de la prestation qui permet de définir la quantité et les instructions de mise en œuvre (type d’intervenant et calendrier).

3.8.7   Modifications de la prestation

Les révisions de plan d’aide sont fréquentes. Elles peuvent consister en l’ajout de nouvelles prestations, en l’arrêt de certaines prestations (avec une date d’arrêt) ou en la suspension de prestations (avec une date de début et une date de fin), par exemple dans le cas où le bénéficiaire est hospitalisé. Il doit même être possible de supprimer une prestation « non démarrée ».

 

Dans le cadre UN/CEFACT, la modification de commande donne lieu à un ensemble de messages spécifiques (Cross Industry Order Change) ; compte tenu du fait qu’un message Order véhicule essentiellement une liste de prestations, et qu’il était possible de créer des règles de mise en œuvre à la fois précises et simples, il a paru plus logique de gérer les évolutions au sein même du message.

 

Les règles sont les suivantes :

1)    Toute prestation sans instruction de modification est considérée comme nouvelle.

2)    Une prestation non démarrée peut être supprimée.

3)    Une prestation peut être suspendue entre deux dates précises.

4)    En dehors de la suspension, toute modification de prestation doit passer par l’arrêt de la prestation à modifier et la mise en place d’une nouvelle prestation, porteuse des évolutions souhaitées.

 

Pour gérer les évolutions, le bloc de description de la prestation possède désormais un bloc SpecifiedCITradeLineChange :

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / SpecifiedCITradeLineChange

Ce bloc permet de décrire le type d’évolution (suppression/arrêt/suspension, à prendre dans la liste ESPPADOM_CHANGE_TYPE), sa date de prise d’effet, sa date de fin d’effet en cas de suspension, son motif (à prendre dans la liste ESPPADOM_CHANGE_REASON) et un libellé qui permet de fournir un texte explicatif.

 

<xsd:complexType name="CITradeLineChangeType">

    <xsd:sequence>

        <xsd:element name="ChangeType" type="CodeQualifiedType"/>

        <xsd:element name="EffectDateTime" type="DateMandatoryDateTimeType"/>

        <xsd:element name="EndOfEffectDateTime" type="DateMandatoryDateTimeType" minOccurs="0"/>

        <xsd:element name="ReasonForChange" type="CodeQualifiedType"/>

        <xsd:element name="Label" type="TextType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

4                      Message DELIVERY

4.1                    Structure du message

Le message Delivery, qui permet la télégestion d’une intervention, a été développé dans le contexte « de cardinalité » suivant :

 

§  1 message de télégestion concerne 1 à n prestations pour 1 bénéficiaire.

§  1 message de télégestion intéresse 1 donneur d’ordre

 

Les informations correspondantes sont détaillées dans le schéma historique ci-dessous :

 

 

Un message Delivery contient ainsi six blocs d’informations qui décrivent respectivement la commande (identifiant, date…), le prestataire, le donneur d’ordre, le bénéficiaire, l’imputation comptable et, finalement, la liste des prestations réalisées. Nous allons les détailler en précisant leur place dans le message et en donnant des exemples d’implémentations.

4.2                    Architecture

Le message Esppadom Delivery est basé sur le message XML UN/CEFACT CrossIndustryDespatchAdvice, auquel il ajoute quelques éléments spécifiques au contexte d’utilisation.

 

La description XSD Esppadom de la balise CrossIndustryDespatchAdvice est la suivante :

 

<xsd:complexType name="CrossIndustryDespatchAdviceType">

    <xsd:sequence>

        <xsd:element name="CIDDHExchangedDocumentContext" type="CIDDHExchangedDocumentContextType"/>

        <xsd:element name="CIDDHExchangedDocument" type="CIDDHExchangedDocumentType"/>

        <xsd:element name="CIDDHSupplyChainTradeTransaction" type="CIDDHSupplyChainTradeTransactionType"/>

    </xsd:sequence>

</xsd:complexType>

 

Balise

Type

Cardinalité

CIDDHExchangedDocumentContext

CIDDHExchangedDocumentContextType

1

CIDDHExchangedDocument

CIDDHExchangedDocumentType

1

CIDDHSupplyChainTradeTransaction

CIDDHSupplyChainTradeTransactionType

1

 

Soit deux balises de gestion documentaire, CIDDHExchangedDocumentContext et CIDDHExchangedDocument, suivies du contenu du document : CIDDHSupplyChainTradeTransaction.

 

Si nous détaillons cette balise de contenu, nous voyons apparaitre les quatre blocs descriptifs : les opérateurs (prestataire et donneur d’ordre), les précisions de délivrance (bénéficiaire et contexte), les conditions financières (payeur, montants…) et enfin la liste des prestations à effectuer.

 

<xsd:complexType name="CIDDHSupplyChainTradeTransactionType">

    <xsd:sequence>

        <xsd:element name="ApplicableCIDDHSupplyChainTradeAgreement" type="CIDDHSupplyChainTradeAgreementType"/>

        <xsd:element name="ApplicableCIDDHSupplyChainTradeDelivery" type="CIDDHSupplyChainTradeDeliveryType"/>

        <xsd:element name="ApplicableCIDDHSupplyChainTradeSettlement" type="CIDDHSupplyChainTradeSettlementType"/>

        <xsd:element name="IncludedCIDDLSupplyChainTradeLineItem" type="CIDDLSupplyChainTradeLineItemType" maxOccurs="unbounded"/>

    </xsd:sequence>

</xsd:complexType>

 

Balise

Type

Cardinalité

ApplicableCIDDHSupplyChainTradeAgreement

CIDDHSupplyChainTradeAgreementType

1

ApplicableCIDDHSupplyChainTradeDelivery

CIDDHSupplyChainTradeDeliveryType

1

ApplicableCIDDHSupplyChainTradeSettlement

CIDDHSupplyChainTradeSettlementType

1

IncludedCIDDLSupplyChainTradeLineItem

CIDDLSupplyChainTradeLineItemType

1..n

 

L’architecture globale du message est ainsi représentée par le schéma ci-dessous, si nous détaillons le bloc ApplicableCIOHSupplyChainTradeAgreement :

 

4.3                    Message minimal

L’exemple ci-dessous montre un message Delivery « maigre », qui ne contient qu’une seule ligne de prestation et un nombre aussi réduit que possible d’informations optionnelles.

 

<delivery VersionID="1.2">

    <CrossIndustryDespatchAdvice>

 

        <CIDDHExchangedDocumentContext>

           <VersionID>1.2</ VersionID >

           <SpecifiedTransactionID>1522</SpecifiedTransactionID>

        </CIDDHExchangedDocumentContext>

        <CIDDHExchangedDocument>

           <ID>0500254</ID>

           <IssueDateTime>2015-10-22T00:00:00Z</IssueDateTime>

        </CIDDHExchangedDocument>

GED :

ID de transaction

 

 

ID de Bon de Livraison

Date d’émission

        <CIDDHSupplyChainTradeTransaction>

           <ApplicableCIDDHSupplyChainTradeAgreement>

 

               <BuyerOrderReferencedCIReferencedDocument>

                   <IssuerCITradeParty>

                         <ID schemeAgencyName="token" schemeID="token"></ID>

                         <Name>Conseil Général du Grand Paris</Name>

                   </IssuerCITradeParty>

               </ BuyerOrderReferencedCIReferencedDocument >

Donneur d’ordre

               <ContractReferencedCIReferencedDocument>

                   <GlobalID schemeAgencyName="token" schemeID="token">P</GlobalID>

               </ContractReferencedCIReferencedDocument>

           </ApplicableCIDDHSupplyChainTradeAgreement>

           <ApplicableCIDDHSupplyChainTradeDelivery>

 

               <ShipToCITradeParty>

                   <ID schemeAgencyName="token" schemeID="token">2612430</ID>

                   <Name>ALITON Jean-Jacques</Name>

                   <FirstName>Jean-Jacques</FirstName>

                   <LastName>ALITON</LastName>

                   <BirthDate>1980-05-01T00:00:00Z</BirthDate>

                   <PostalCITradeAddress>

                         <PostcodeCode>16500</PostcodeCode>

                         <LineOne>Le bourg</LineOne>

                         <CityName>ST GERMAIN DE CONFOLENS</CityName>

                   </PostalCITradeAddress>

                   <ContextShipTo>

                         <GIR>3</GIR>

                   </ContextShipTo>

               </ShipToCITradeParty>

Bénéficiaire :

ID pour le donneur d’ordre

               <ShipFromCITradeParty>

                   <ID schemeAgencyName="token" schemeID="token"></ID>

                   <Name>Prest Domicile SARL</Name>

               </ShipFromCITradeParty>

Prestataire :

ID pour le donneur d’ordre

               <ActualDespatchCISupplyChainEvent>

                   <TypeCode schemeAgencyName="EDESS" schemeID="ESPPADOM_EFFECTIVITY_AJUST"></TypeCode>

                   <OccurrenceCISpecifiedPeriod>

                         <StartDateTime>2015-10-20T17:48:00Z</StartDateTime>

                         <EndDateTime>2015-10-20T18:45:00Z</EndDateTime>

                   </OccurrenceCISpecifiedPeriod>

               </ActualDespatchCISupplyChainEvent>

 

Intervalle de temps de prestation des services, ici non ajusté

           </ApplicableCIDDHSupplyChainTradeDelivery>

           <ApplicableCIDDHSupplyChainTradeSettlement>

 

           </ApplicableCIDDHSupplyChainTradeSettlement>

 

           <IncludedCIDDLSupplyChainTradeLineItem>

               <AssociatedCIDDLDocumentLineDocument>

                   <LineID>2565AL1</LineID>

               </AssociatedCIDDLDocumentLineDocument>

               <SpecifiedCIDDLSupplyChainTradeDelivery>

                   <BilledQuantity unitCode="HUR">3.0</BilledQuantity>

               </SpecifiedCIDDLSupplyChainTradeDelivery>

               <SpecifiedCIDDLSupplyChainTradeSettlement>

               </SpecifiedCIDDLSupplyChainTradeSettlement>

               <SpecifiedCITradeProduct>

                   <ID schemeAgencyName="EDESS" schemeID="ESPPADOM_TYPE_AIDE">0211.01</ID>

                   <Name>Aide au domicile</Name>

               </SpecifiedCITradeProduct>

           </IncludedCIDDLSupplyChainTradeLineItem>

Prestation :

 

Identifiant Order de la prestation

 

Nombre d’unités de valeur (ici des heures)

 

 

Qualification de la prestation

        </CIDDHSupplyChainTradeTransaction>

    </CrossIndustryDespatchAdvice>

</delivery>

 

 

Nous allons maintenant détailler l’ensemble du message, en commençant par le contexte documentaire du message.

4.4                    Contexte : transaction et identification de la commande

Le premier bloc d’informations du message, obligatoire, traite de données générales (dites « de contexte »).

4.4.1   Transaction

<xsd:complexType name="CIDDHExchangedDocumentContextType">

    <xsd:sequence>

        <xsd:element name="VersionID" type="xsd:token"/>

        <xsd:element name="SpecifiedTransactionID" type="IDUnqualifiedType"/>

        <xsd:element name="DeliveryContextParameter" type="CIDeliveryContextParameterType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

La première information, obligatoire, rencontrée dans un message précise la version du schéma xsd auquel ce message est conforme.

CrossIndustryDespatchAdvice / CIDDHExchangedDocumentContext / VersionID

 

La seconde information précise l’identifiant de transaction.

CrossIndustryDespatchAdvice / CIDDHExchangedDocumentContext / SpecifiedTransactionID

Comme nous l’avons déjà précisé, cette information obligatoire est purement technique puisqu’elle sert, pour des raisons de traçabilité à rattacher l’information de télégestion (qui est représentée par un bloc CrossIndustryDespatchAdvice) au lot des autres fichiers envoyés simultanément. Tous les messages CrossIndustryDespatchAdvice situés au sein d’un même fichier xml delivery doivent donc avoir un même identifiant de transaction.

 

Suit, dans le même chapitre du « contexte d’échange » un bloc d’informations optionnelles qui précisent le contexte d’application du document.

 

<xsd:complexType name="CIDeliveryContextParameterType">

    <xsd:sequence>

        <xsd:element name="ReasonForAbsence" type="TextType" minOccurs="0" />

        <xsd:element name="TypeAide" type="TextType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

Le motif d’absence est logiquement optionnel.

CrossIndustryDespatchAdvice / CIDDHExchangedDocumentContext / DeliveryContextParameter / ReasonForAbsence

Cette information reste volontairement non structurée car, dans les cas où une intervention est validée (en tout ou partie) même en cas d’absence, l’information structurée correspondante est à préciser dans les motifs de correction, attachés au chemin :

CrossIndustryDespatchAdvice / CIDDHSupplyChainTradeTransaction / ApplicableCIDDHSupplyChainTradeDelivery / ActualDespatchCISupplyChainEvent / TypeCode

Le type d’aide permet de préciser, au sein de la liste ESPPADOM_TYPE_AIDE, le cadre général dans lequel se situe l’intervention : APA, PCH, AM :

CrossIndustryDespatchAdvice / CIDDHExchangedDocumentContext / DeliveryContextParameter / TypeAide

On trouve ensuite le bloc, obligatoire, qui contient les informations de télégestion :

4.4.2   Télégestion

La description dématérialisée de l’entête de télégestion s’effectue dans le bloc CIDDHExchangedDocumentType :

 

<xsd:complexType name="CIDDHExchangedDocumentType">

    <xsd:sequence>

        <xsd:element name="ID" type="IDUnqualifiedType"/>

        <xsd:element name="IssueDateTime" type="DateMandatoryDateTimeType"/>

        <xsd:element name="IncludedCINote" type="CINoteType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

Le numéro de bon de livraison est une information obligatoire générée par le prestataire.

CrossIndustryDespatchAdvice / CIDDHExchangedDocument / ID

Suit la date du bon de livraison, information obligatoire qui contient la date d’émission (et non, par exemple, la date de réalisation des prestations).

CrossIndustryDespatchAdvice / CIDDHExchangedDocument / IssueDateTime

Un bloc optionnel permet de préciser une note en texte libre.

CrossIndustryDespatchAdvice / CIDDHExchangedDocument / IncludedCINote

4.5                    Prestataire et donneur d’ordre

Nous quittons les informations documentaires et entrons maintenant dans le « corps » de la livraison

CrossIndustryDespatchAdvice / CIDDHSupplyChainTradeTransaction

et plus précisément dans les informations qui décrivent les opérateurs : prestataire et donneur d’ordre

CrossIndustryDespatchAdvice / CIDDHSupplyChainTradeTransaction / ApplicableCIDDHSupplyChainTradeAgreement

La description XSD de ce bloc est la suivante :

 

<xsd:complexType name="CIDDHSupplyChainTradeAgreementType">

    <xsd:sequence>

        <xsd:element name="BuyerOrderReferencedCIReferencedDocument" type="CIReferencedDocumentOrderType"/>

        <xsd:element name="ContractReferencedCIReferencedDocument" type=" CIReferencedDocumentType "/>

    </xsd:sequence>

</xsd:complexType>

 

Balise

Type

Cardinalité

BuyerOrderReferencedCIReferencedDocument

CIReferencedDocumentOrderType

1

ContractReferencedCIReferencedDocument

CIReferencedDocumentType

1

 

Soit :

§  BuyerOrderReferencedCIReferencedDocument, qui représente la commande qui incluait la prestation déclarée dans le bon de livraison, avec son identifiant et le rappel du donneur d’ordre.

§  CIReferencedDocumentIdentificationType, qui représente l’identifiant d’un document externe : le contrat entre ces parties.

4.5.1   Donneur d’ordre et identifiant de commande

Le donneur d’ordre est décrit au sein du bloc de données obligatoire

CrossIndustryDespatchAdvice / CIDDHSupplyChainTradeTransaction / ApplicableCIDDHSupplyChainTradeAgreement / BuyerOrderReferencedCIReferencedDocument

La description XSD de ce bloc est la suivante :

 

<xsd:complexType name="CIReferencedDocumentOrderType">

    <xsd:sequence>

        <xsd:element name="IssuerAssignedID" type="IDUnqualifiedType" minOccurs="0"/>

        <xsd:element name="IssuerCITradeParty" type="CITradePartyType"/>

    </xsd:sequence>

</xsd:complexType>

 

Il contient, de façon optionnelle, l’identifiant de la commande qui justifie cette intervention. Ce bloc est optionnel car le flux Delivery peut être utilisé dans des contextes où le flux Order, qui porte cette information n’est pas (encore) utilisé.

CrossIndustryDespatchAdvice / CIDDHSupplyChainTradeTransaction / ApplicableCIDDHSupplyChainTradeAgreement / BuyerOrderReferencedCIReferencedDocument / IssuerAssignedID

Au sein du message Order, cette information est située au chemin :

CrossIndustryOrder / CIOHExchangedDocument / ID

Ensuite, un bloc obligatoire décrit le donneur d’ordre, au format usuel CITradePartyType :

CrossIndustryDespatchAdvice / CIDDHSupplyChainTradeTransaction / ApplicableCIDDHSupplyChainTradeAgreement / BuyerOrderReferencedCIReferencedDocument / IssuerCITradeParty

Ce bloc contient la structure d’informations usuelle pour les personnes, décrite au chapitre 2.

4.5.2   Type de contrat

La description du contrat est spécifiée par la balise

CrossIndustryDespatchAdvice / CIDDHSupplyChainTradeTransaction / ApplicableCIDDHSupplyChainTradeAgreement / ContractReferencedCIReferencedDocument

Ce bloc contient une balise GlobalID au format IDQualifiedType qui permet de préciser l’identifiant du contrat qui lie les parties.

4.6                    Délivrance des prestations

La délivrance des prestations est décrite par le bloc

CrossIndustryDespatchAdvice / CIDDHSupplyChainTradeTransaction / ApplicableCIDDHSupplyChainTradeDelivery

Ce bloc est décrit par le schéma xsd suivant :

 

<xsd:complexType name="CIDDHSupplyChainTradeDeliveryType">

    <xsd:sequence>

        <xsd:element name="ShipToCITradeParty" type="CITradePartyType"/>

        <xsd:element name="ShipFromCITradeParty" type="CITradePartyType"/>

        <xsd:element name="ActualDespatchCISupplyChainEvent" type="CISupplyChainEventType"/>

        <xsd:element name="AdditionalReferencedCIReferencedDocument" type="CIReferencedDocumentSignatureType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

 

Balise

Type

Cardinalité

Bénéficiaire

ShipToCITradeParty

CITradePartyType

1

Prestataire

ShipFromCITradeParty

CITradePartyType

1

Effectivité retenue

ActualDespatchCISupplyChainEvent

CISupplyChainEventType

1

Horodatage

AdditionalReferencedCIReferencedDocument

CIReferencedDocumentSignatureType

0..1

 

Il permet de décrire, de façon obligatoire, le bénéficiaire, le prestataire, la délivrance du service telle que retenue et la délivrance effective du service.

 

L’effectivité retenue correspond à la période à prendre réellement en compte. Elle peut avoir trois significations distinctes :

§  Le plus fréquemment, une simple retranscription de la période horodatée.

§  En cas de défaut de l’horodatage, une correction manuelle, justifiée, de la période horodatée.

§  En absence de données d’horodatage, une période purement déclarative, par exemple dans le cas d’un cahier de présence ou d’absence du bénéficiaire là où une compensation forfaitaire est prévue.

4.6.1   Bénéficiaire

Le bénéficiaire est décrit au chapitre

CrossIndustryDespatchAdvice / CIDDHSupplyChainTradeTransaction / ApplicableCIDDHSupplyChainTradeDelivery / ShipToCITradeParty

Ce bloc d’information est obligatoire et conforme au type « CITradeParty » décrit au chapitre 2.

4.6.2   Prestataire

Le second acteur décrit est le prestataire, celui qui a émis le bon de livraison.

CrossIndustryDespatchAdvice / CIDDHSupplyChainTradeTransaction / ApplicableCIDDHSupplyChainTradeDelivery / ShipFromCITradeParty

Ce bloc d’information est obligatoire et conforme au type « CITradeParty » décrit au chapitre 2.

4.6.3   Délivrance retenue

La délivrance retenue est décrite dans le bloc obligatoire :

CrossIndustryDespatchAdvice / CIDDHSupplyChainTradeTransaction / ApplicableCIDDHSupplyChainTradeDelivery / ActualDespatchCISupplyChainEvent

Qui est décrit par le schéma xsd :

 

<xsd:complexType name="CISupplyChainEventType">

    <xsd:sequence>

        <xsd:element name="TypeCode" type="CodeQualifiedType" minOccurs="0"/>

        <xsd:element name="OccurrenceCISpecifiedPeriod" type="CISpecifiedPeriodType"/>

    </xsd:sequence>

</xsd:complexType>

 

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.

CrossIndustryDespatchAdvice / CIDDHSupplyChainTradeTransaction / ApplicableCIDDHSupplyChainTradeDelivery / ActualDespatchCISupplyChainEvent / TypeCode

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).

 

Le bloc OccurrenceCISpecifiedPeriod, unique et obligatoire, est décrit pas le schéma xsd :

 

<xsd:complexType name="CISpecifiedPeriodType">

    <xsd:sequence>

        <xsd:element name="StartDateTime" type="DateTimeType"/>

        <xsd:element name="EndDateTime" type="DateTimeType"/>

    </xsd:sequence>

</xsd:complexType>

 

Il permet de préciser les éléments retenus de début et de fin d’effectivité de l’intervention. Tant l’information de début que celle de fin sont uniques et obligatoires.

4.6.4   Délivrance effective

Les éléments de délivrance recueillis sur le terrain sont décrits dans le bloc optionnel :

CrossIndustryDespatchAdvice / CIDDHSupplyChainTradeTransaction / ApplicableCIDDHSupplyChainTradeDelivery / AdditionalReferencedCIReferencedDocument

Son schéma xsd est :

 

<xsd:complexType name="CIReferencedDocumentSignatureType">

    <xsd:sequence>

        <xsd:element name="EffectiveCISpecifiedPeriod" type="CIDTimeStampPeriodType"/>

    </xsd:sequence>

</xsd:complexType>

 

Le bloc EffectiveCISpecifiedPeriod, obligatoire, permet de préciser les éléments d’horodatage mesurés de début et de fin de l’événement issus du système de pointage du prestataire.

 

<xsd:complexType name="CIDTimeStampPeriodType">

    <xsd:sequence>

        <xsd:element name="StartDateTime" type="CIDDateTimeStampType" minOccurs="0"/>

        <xsd:element name="EndDateTime" type="CIDDateTimeStampType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

Chaque élément d’horodatage (arrivée et départ) permet de spécifier l’heure mesurée (avec, éventuellement, sa preuve sous forme de fichier binaire) ainsi que la méthode qui a été ponctuellement utilisée pour identifier le bénéficiaire et localiser le prestataire.

 

 

Balise

Type

Cardinalité

Date et heure

CertifiedDateTime

DateMandatoryDateTimeType

1

Méthode d’identification du bénéficiaire

CustomerIdentificationMethod

CodeQualifiedType

1

Méthode d’identification du prestataire

SupplierIdentificationMethod

CodeQualifiedType

1

Fichier d’horodatage

AttachedSpecifiedBinaryFile

SpecifiedBinarymessageType

0..1

 

<xsd:complexType name="CIDDateTimeStampType">

    <xsd:sequence>

        <xsd:element name="CertifiedDateTime" type="UNECE_QDT_8p0:DateMandatoryDateTimeType"/>

        <xsd:element name="CustomerIdentificationMethod" type="UNECE_UDT_9p0:CodeQualifiedType"/>

        <xsd:element name="SupplierIdentificationMethod" type="UNECE_UDT_9p0:CodeQualifiedType"/>

        <xsd:element name="AttachedSpecifiedBinaryFile" type="UNECE_QDT_8p0:SpecifiedBinarymessageType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

Les balises CustomerIdentificationMethod et SupplierIdentificationMethod utilisent toutes deux la liste ESPPADOM_TIMESTAMP_METHOD. On notera que son absence au sein de cette liste permet de bien préciser que la « feuille de présence » n’est pas une technique d’horodatage ; dans ce cas d’usage, seule la délivrance retenue peut donc être inscrite au sein du message.

 

Au sein du bloc CIDTimeStampPeriodType, les balises StartDateTime et EndDateTime sont optionnelles afin de permettre d’utiliser le message Delivery comme support d’échange des informations d’horodatage. Les acteurs pourront définir à leur convenance les scénarios d’usage ; par exemple :

§  Le système d’horodatage renseigne toujours la balise StartDateTime et l’horodatage final se fait en supposant qu’en physique non quantique, et pour un intervenant externe, la date d’arrivée précède toujours la date de départ.

§  Le système d’horodatage permet de qualifer l’arrivée et le départ et utilise éventuellement alternativement chaque balise.

§  Le message Delivery « se remplit » à mesure des échanges, et le système d’horodatage émet un premier message ne contenant que StartDateTime puis un second message précisant les deux balises.

 

Le bloc AttachedSpecifiedBinaryFile, unique et optionnel, peut contenir, sous forme binaire, un document d’horodatage de la prestation issu du système de pointage.

4.7                    Imputation comptable

L’imputation comptable est précisée au sein du bloc

CrossIndustryDespatchAdvice / CIDDHSupplyChainTradeTransaction / ApplicableCIDDHSupplyChainTradeSettlement

De schéma :

 

<xsd:complexType name="CIDDHSupplyChainTradeSettlementType">

    <xsd:sequence>

        <xsd:element name="PurchaseSpecifiedCITradeAccountingAccount" type="CITradeAccountingAccountType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

Il contient simplement un bloc optionnel PurchaseSpecifiedCITradeAccountingAccount qui permet de fournir la référence d’imputation comptable, provenant de la commande, à rappeler dans les factures. Ce bloc ne contient qu’un identifiant :

 

<xsd:complexType name="CITradeAccountingAccountType">

    <xsd:sequence>

        <xsd:element name="ID" type="IDUnqualifiedType"/>

    </xsd:sequence>

</xsd:complexType>

 

Ce chapitre permet ainsi de fournir la référence comptable du donneur d’ordre dans l’élément

CrossIndustryDespatchAdvice / CIDDHSupplyChainTradeTransaction / ApplicableCIDDHSupplyChainTradeSettlement / PurchaseSpecifiedCITradeAccountingAccount / ID

Au sein du message Order, cette information de référence comptable est véhiculée par la balise

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / ApplicableCIOHSupplyChainTradeSettlement / PayableSpecifiedCITradeAccountingAccount / ID

4.8                    Liste des prestations réalisées

La liste des prestations réalisée, les « lignes du bon de livraison », occupent un bloc multiple et obligatoire.

CrossIndustryDespatchAdvice / CIOHSupplyChainTradeTransaction / IncludedCIDDLSupplyChainTradeLineItem

Son schéma est le suivant :

 

<xsd:complexType name="CIDDLSupplyChainTradeLineItemType">

    <xsd:sequence>

        <xsd:element name="AssociatedCIDDLDocumentLineDocument" type="CIDDLDocumentLineDocumentType"/>

        <xsd:element name="SpecifiedCIDDLSupplyChainTradeDelivery" type="CIDDLSupplyChainTradeDeliveryType"/>

        <xsd:element name="SpecifiedCIDDLSupplyChainTradeSettlement" type="CIDDLSupplyChainTradeSettlementType"/>

        <xsd:element name="SpecifiedCITradeProduct" type="CITradeProductType"/>

        <xsd:element name="SpecifiedCIDDLDeliveryDetail" type="CIDDLDeliveryDetailType" minOccurs="0" maxOccurs="unbounded"/>

    </xsd:sequence>

</xsd:complexType>

 

 

Balise

Type

Cardinalité

Identification

AssociatedCIDDLDocumentLineDocument

CIDDLDocumentLineDocumentType

1

Quantité théorique à facturer

SpecifiedCIDDLSupplyChainTradeDelivery

CIDDLSupplyChainTradeDeliveryType

1

Information financières

SpecifiedCIDDLSupplyChainTradeSettlement

CIDDLSupplyChainTradeSettlementType

1

Description

SpecifiedCITradeProduct

CITradeProductType

1

Actes

SpecifiedCIDDLDeliveryDetail

CIDDLDeliveryDetailType

0..n

 

Si le bon de livraison ne contient qu’une seule prestation, il n’y aura qu’une seule ligne au bon de livraison, et ce bloc sera unique ; si plusieurs prestations sont déclarées, il y aura autant de blocs IncludedCIDDLSupplyChainTradeLineItem que de services.

 

Chaque ligne contient cinq ensembles d’informations : l’identification de la prestation commandée qui correspond à l’acte déclaré, la quantité théorique à facturer, les conditions financières, la description du service et, éventuellement, la liste des actes spécifiés au sein de la prestation qui ont été traités lors de l’intervention.

4.8.1   Identification

Le premier élément d’une ligne de commande est un bloc d’identification, unique et obligatoire :

CrossIndustryDespatchAdvice / CIOHSupplyChainTradeTransaction / IncludedCIDDLSupplyChainTradeLineItem / AssociatedCIDDLDocumentLineDocument

Son schéma est :

 

<xsd:complexType name="CIDDLDocumentLineDocumentType">

    <xsd:sequence>

        <xsd:element name="LineID" type="IDUnqualifiedType"/>

        <xsd:element name="OrderLineID" type="IDUnqualifiedType"/>

        <xsd:element name="IncludedCINote" type="CINoteType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

 

Balise

Type

Cardinalité

Identifiant de cette partie d’intervention

LineID

IDUnqualifiedType

1

Identifiant de la prestation commandée

OrderLineID

IDUnqualifiedType

1

Note

IncludedCINote

CINoteType

0..1

 

L’identification comprend l’identifiant de la prestation commandée, unique et obligatoire, qui correspond à l’acte déclaré, l’identifiant de la partie de l’intervention qui correspond à cette prestation, unique et obligatoire, ainsi qu’une note optionnelle en texte libre.

 

L’identifiant de la « ligne de bon de livraison », c'est-à-dire de la partie de l’intervention qui correspond à une prestation commandée est attaché au chemin

CrossIndustryDespatchAdvice / CIOHSupplyChainTradeTransaction / IncludedCIDDLSupplyChainTradeLineItem / AssociatedCIDDLDocumentLineDocument / LineID

L’identifiant de la prestation commandée est attaché au chemin

CrossIndustryDespatchAdvice / CIOHSupplyChainTradeTransaction / IncludedCIDDLSupplyChainTradeLineItem / AssociatedCIDDLDocumentLineDocument / OrderLineID

Au sein du message Order, cette information est véhiculée par la balise

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / AssociatedCIOLDocumentLineDocument / LineID

La note optionnelle est attachée au chemin

CrossIndustryDespatchAdvice / CIOHSupplyChainTradeTransaction / IncludedCIDDLSupplyChainTradeLineItem / AssociatedCIDDLDocumentLineDocument / IncludedCINote / Content

4.8.2   Quantité théorique à facturer

La « quantité théorique à facturer » est précisée dans un bloc unique et obligatoire :

CrossIndustryDespatchAdvice / CIOHSupplyChainTradeTransaction / IncludedCIDDLSupplyChainTradeLineItem / SpecifiedCIDDLSupplyChainTradeDelivery

Son schéma est le suivant :

 

<xsd:complexType name="CIDDLSupplyChainTradeDeliveryType">

    <xsd:sequence>

        <xsd:element name="BilledQuantity" type="QuantityType"/>

        <xsd:element name="SpecifiedCIDeliveryAdjustment" type="CIDeliveryAdjustmentType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

Il contient, sous forme unique et obligatoire la quantité réalisée (nombre et unité) qui donnera lieu à facturation.

CrossIndustryDespatchAdvice / CIOHSupplyChainTradeTransaction / IncludedCIDDLSupplyChainTradeLineItem / SpecifiedCIDDLSupplyChainTradeDelivery / BilledQuantity

Il contient également, de façon optionnelle, les ajustements effectués par rapport aux actes réellement effectués.

CrossIndustryDespatchAdvice / CIOHSupplyChainTradeTransaction / IncludedCIDDLSupplyChainTradeLineItem / SpecifiedCIDDLSupplyChainTradeDelivery / SpecifiedCIDeliveryAdjustment

Son schéma est le suivant :

 

<xsd:complexType name="CIDeliveryAdjustmentType">

    <xsd:sequence>

        <xsd:element name="ReasonCode" type="CodeQualifiedType"/>

        <xsd:element name="ActualQuantity" type="QuantityType"/>

    </xsd:sequence>

</xsd:complexType>

 

Il est ainsi possible de fournir la quantité de service effectivement réalisée et le motif d’ajustement à la quantité donnant lieu à facturation.

 

L’ajustement est utilisé, par exemple, lorsque la durée d’intervention pour cette prestation vient partiellement en excès de la quantité totale commandée. La durée totale effectivement réalisée sera alors indiquée dans ActualQuantity alors que seul le reliquat de commande sera indiqué dans la balise BilledQuantity.

4.8.3   Informations de traitement financier

Les conditions financières sont décrites dans un bloc unique obligatoire :

CrossIndustryDespatchAdvice / CIOHSupplyChainTradeTransaction / IncludedCIDDLSupplyChainTradeLineItem / SpecifiedCIDDLSupplyChainTradeSettlement

Son schéma est le suivant :

 

<xsd:complexType name="CIDDLSupplyChainTradeSettlementType">

    <xsd:sequence>

        <xsd:element name="CadreIntervention" type="CodeQualifiedType"/>

    </xsd:sequence>

</xsd:complexType>

 

Ce bloc permet de préciser le cadre d’intervention (mandataire, prestataire, gré à gré), à choisir au sein de la liste ESPPADOM_CADRE.

4.8.4   Description du service

La description du service est effectuée dans un bloc unique et obligatoire :

CrossIndustryDespatchAdvice / CIOHSupplyChainTradeTransaction / IncludedCIDDLSupplyChainTradeLineItem / SpecifiedCITradeProduct

<xsd:complexType name="CITradeProductType">

    <xsd:sequence>

        <xsd:element name="ID" type="IDQualifiedType"/>

        <xsd:element name="Name" type="TextType"/>

    </xsd:sequence>

</xsd:complexType>

 

Ce bloc contient deux informations, l’identifiant du service et son libellé ; ces deux informations sont uniques et obligatoires.

CrossIndustryDespatchAdvice / CIOHSupplyChainTradeTransaction / IncludedCIDDLSupplyChainTradeLineItem / SpecifiedCITradeProduct / ID

CrossIndustryDespatchAdvice / CIOHSupplyChainTradeTransaction / IncludedCIDDLSupplyChainTradeLineItem / SpecifiedCITradeProduct / Name

L’ID est, comme toujours, du type schemeID (identifiant) et schemeAgencyName (libellé) ; le Name est un libellé en texte libre.

4.8.5   Liste des actes

La liste des actes spécifiés au sein de la prestation qui ont été traités lors de l’intervention se matérialise par le bloc optionnel et éventuellement multiple

CrossIndustryDespatchAdvice / CIOHSupplyChainTradeTransaction / IncludedCIDDLSupplyChainTradeLineItem / SpecifiedCIDDLDeliveryDetail

Son schéma, conforme au principe selon lequel un acte est homogène à une prestation sans tarif est :

 

<xsd:complexType name="CIDDLDeliveryDetailType">

    <xsd:sequence>

        <xsd:element name="DetailLineID" type="IDUnqualifiedType"/>

        <xsd:element name="OrderedDetailLineID" type="IDUnqualifiedType"/>

        <xsd:element name="ID" type="CodeQualifiedType"/>

        <xsd:element name="Name" type="TextType"/>

        <xsd:element name="SpecifiedCIDDLSupplyChainTradeDelivery" type="CIDDLSupplyChainTradeDeliveryType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

Soit :

 

 

Balise

Type

Cardinalité

Identifiant de cette partie d’intervention

DetailLineID

IDUnqualifiedType

1

Identifiant de l’acte commandé

OrderedDetailLineID

IDUnqualifiedType

1

Code de l’acte

ID

CodeQualifiedType

1

Libellé de l’acte

Name

TextType

1

Quantité théorique à comptabiliser

SpecifiedCIDDLSupplyChainTradeDelivery

CIDDLSupplyChainTradeDeliveryType

1

 

Ce bloc permet ainsi de décrire l’identifiant unique attribué à cette « sous-ligne », l’identifiant de l’acte au sein du message Order (si cet acte constituait une consigne), le code et le libellé de l’acte (code à prendre dans la liste ESPPADOM_SERVICE) et, enfin, la quantité théorique à comptabiliser selon la même structure que celle de la quantité théorique à facturer (quantité effectivement réalisée et quantité à prendre en compte en télégestion). Cette dernière information ne sera généralement pas précisée, aussi est-elle optionnelle.

 

Cette liste d’actes peut être utilisée, en fonction des accords passés entre le prestataire et le donneur d’ordres, de plusieurs façons :

·         En rappelant simplement à l’identique les codes des consignes transmises au sein du message Order qui ont effectivement été prises en charge.

·         En détaillant la façon dont les consignes ont été prises en charge, par l’utilisation éventuelle de codes plus précis (à la consigne de code X, sera attribué un code de type X.Y – par exemple, si la consigne est 2.2.1.1.1 Aide à la toilette, il sera transmis le code 2.2.1.1.1.1 Aide à la toilette partielle).

·         En transmettant la liste exhaustive des prestations réalisées, qu’elles valident ou non une consigne.

 

5                      Message INVOICE

5.1                    Structure du message

Le message Invoice, qui décrit une facture, a été développé dans le contexte « de cardinalité » suivant :

 

§  1 facture est générée par 1 prestataire et concerne 1 bénéficiaire.

§  1 facture correspond 1 à n prestation(s)

§  1 facture est adressée à destination d’un 1 Donneur d’ordre pour 1 Financeur

 

Les informations correspondantes sont détaillées dans le schéma historique ci-dessous :

 

 

Une facture concerne 1 à n commandes, il est donc important que chaque ligne de la facture identifie sans ambiguïté la ligne de commande à laquelle elle fait référence, et ceci comme élément d’une commande spécifique.

 

Un message Invoice contient six blocs d’informations qui décrivent respectivement la facture (identifiant, date…), le prestataire, le donneur d’ordre, le bénéficiaire, les conditions financières et, finalement, la liste des prestations facturées. Nous allons les détailler en précisant leur place dans le message et en donnant des exemples d’implémentations.

5.2                    Architecture

Le message Esppadom Invoice est basé sur le message UN/CEFACT CrossIndustryInvoice, auquel il ajoute quelques éléments spécifiques au contexte d’utilisation.

 

Par ailleurs, ses règles d’usage doivent être conformes aux « business rules » du CEN Workshop Agreement CWA 16356[1].

 

La description XSD Esppadom de la balise CrossIndustryInvoice est la suivante :

 

<xsd:complexType name="CrossIndustryInvoiceType">

        <xsd:sequence>

           <xsd:element name="CIIHExchangedDocumentContext" type="CIIHExchangedDocumentContextType"/>

           <xsd:element name="CIIHExchangedDocument" type="CIIHExchangedDocumentType"/>

           <xsd:element name="CIIHSupplyChainTradeTransaction" type="CIIHSupplyChainTradeTransactionType"/>

        </xsd:sequence>

</xsd:complexType>

 

Soit deux balises de gestion documentaire, CIExchangedDocumentContext et CIIHExchangedDocument, suivies du contenu effectif du document : CIIHSupplyChainTradeTransaction :

 

Balise

Type

Cardinalité

CIIHExchangedDocumentContext

CIIHExchangedDocumentContextType

1

CIIHExchangedDocument

CIIHExchangedDocumentType

1

CIIHSupplyChainTradeTransaction

CIIHSupplyChainTradeTransactionType

1

 

Si nous détaillons la dernière balise, nous voyons apparaitre les quatre blocs descriptifs : les opérateurs (prestataire et donneur d’ordre), les précisions de délivrance (bénéficiaire et contexte), les conditions financières (payeur, montants…) et enfin la liste des prestations facturées.

 

<xsd:complexType name="CIIHSupplyChainTradeTransactionType">

    <xsd:sequence>

        <xsd:element name="ApplicableCIIHSupplyChainTradeAgreement" type="CIIHSupplyChainTradeAgreementType"/>

        <xsd:element name="ApplicableCIIHSupplyChainTradeDelivery" type="CIIHSupplyChainTradeDeliveryType"/>

        <xsd:element name="ApplicableCIIHSupplyChainTradeSettlement" type="CIIHSupplyChainTradeSettlementType"/>

        <xsd:element name="IncludedCIILSupplyChainTradeLineItem" type="CIILSupplyChainTradeLineItemType" maxOccurs="unbounded"/>

    </xsd:sequence>

</xsd:complexType>

 

Balise

Type

Cardinalité

ApplicableCIIHSupplyChainTradeAgreement

CIIHSupplyChainTradeAgreementType

1

ApplicableCIIHSupplyChainTradeDelivery

CIIHSupplyChainTradeDeliveryType

1

ApplicableCIIHSupplyChainTradeSettlement

CIIHSupplyChainTradeSettlementType

1

IncludedCIILSupplyChainTradeLineItem

CIILSupplyChainTradeLineItemType

1..n

 

L’architecture globale du message est ainsi représentée par le schéma ci-dessous, si nous détaillons le bloc ApplicableCIIHSupplyChainTradeAgreement :

 

 

Soit six blocs d’informations qui précisent la gestion documentaire, le prestataire, le donneur d’ordre, le bénéficiaire, les conditions financières et, finalement, la liste des prestations facturées.

5.3                    Règles européennes

L’Union Européenne précise dans un document en ligne les règles de facturation de la TVA[2]. Les éléments obligatoires sont rappelés par la spécification 24 (Rq024) du CWA 16356-2 :

 

§  la date d’émission;

§  le numéro séquentiel unique permettant d’identifier la facture;

§  le numéro d'identification TVA du client (si celui-ci est redevable de la taxe sur l'opération);

§  le nom complet et l'adresse du fournisseur;

§  le nom complet et l'adresse du client;

§  la description de la quantité et de la nature des biens livrés ou de la nature et de l’étendue des services rendus;

§  la date de l'opération ou du paiement (si elle est différente de la date de facturation);

§  le taux de TVA appliqué;

§  le montant de la TVA à payer;

§  la ventilation du montant de la TVA à payer par taux de TVA ou l'exonération;

§  le prix unitaire des biens ou des services — hors taxe, rabais ou remises (sauf s'ils sont inclus dans le prix unitaire).

5.4                    Message minimal

L’exemple ci-dessous montre un message Invoice « maigre », qui ne contient qu’une seule ligne de prestation et un nombre aussi réduit que possible d’informations optionnelles.

 

<invoice VersionID="1.2">

    <CrossIndustryInvoice>

 

        <CIIHExchangedDocumentContext>

           <VersionID>1.2</VersionID >

           <SpecifiedTransactionID>1297</SpecifiedTransactionID>

        </CIIHExchangedDocumentContext>

        <CIIHExchangedDocument>

           <ID>1512035</ID>

           <TypeCode>380</TypeCode>

           <IssueDateTime>2015-12-15T00:00:00Z</IssueDateTime>

        </CIIHExchangedDocument>

GED :

ID de transaction

 

 

ID de facture

Document = facture

Date de facture

        <CIIHSupplyChainTradeTransaction>

           <ApplicableCIIHSupplyChainTradeAgreement>

 

               <SellerCITradeParty>

                   <ID schemeAgencyName="token" schemeID="token"></ID>

                   <Name>Prest Domicile SARL</Name>

               </SellerCITradeParty>

Prestataire :

ID pour le donneur d’ordre

               <BuyerCITradeParty>

                   <ID schemeAgencyName="token" schemeID="token"></ID>

                   <Name>Conseil Général du Grand Paris</Name>

               </BuyerCITradeParty>

Donneur d’ordre

               <BuyerOrderReferencedCIReferencedDocument>

                   <IssuerAssignedID>0500254</IssuerAssignedID>

               </BuyerOrderReferencedCIReferencedDocument>

           </ApplicableCIIHSupplyChainTradeAgreement>

           <ApplicableCIIHSupplyChainTradeDelivery>

 

Numéro de commande correspondante

               <ShipToCITradeParty>

                   <ID schemeAgencyName="token" schemeID="token">2612430</ID>

                   <Name>ALITON Jean-Jacques</Name>

                   <Civility schemeAgencyName="EDESS" schemeID="ESPPADOM_CIVI">MR</Civility>

                   <FirstName>Jean-Jacques</FirstName>

                   <LastName>ALITON</LastName>

                   <BirthDate>1980-05-01T00:00:00Z</BirthDate>

                   <PostalCITradeAddress>

                         <PostcodeCode>16500</PostcodeCode>

                         <LineOne>Le bourg</LineOne>

                         <CityName>ST GERMAIN DE CONFOLENS</CityName>

                   </PostalCITradeAddress>

                   <ContextShipTo>

                         <GIR>3</GIR>

                   </ContextShipTo>

               </ShipToCITradeParty>

Bénéficiaire :

ID pour le donneur d’ordre

               <ActualDeliveryCISupplyChainEvent>

                   <OccurrenceDateTime>2015-11-30T00:00:00Z</OccurrenceDateTime>

               </ActualDeliveryCISupplyChainEvent>

           </ApplicableCIIHSupplyChainTradeDelivery>

           <ApplicableCIIHSupplyChainTradeSettlement>

 

Date d’arrêté de la facture

               <DuePayableAmount>140.00</DuePayableAmount>

               <InvoiceCurrencyCode listID="4217 3A" listAgencyID="5" listVersionID="2010-04-07">EUR</InvoiceCurrencyCode>

               <SpecifiedCIIHTradeSettlementMonetarySummation>

                   <LineTotalAmount>140.00</LineTotalAmount>

                   <TaxBasisTotalAmount>0.00</TaxBasisTotalAmount>

                   <GrandTotalAmount>140.00</GrandTotalAmount>

               </SpecifiedCIIHTradeSettlementMonetarySummation>

Organisme payeur :

ID pour le donneur d’ordre

           </ApplicableCIIHSupplyChainTradeSettlement>

 

           <IncludedCIILSupplyChainTradeLineItem>

               <AssociatedCIILDocumentLineDocument>

                   <LineID>151125_253</LineID>

                   <OrderID>2565AL1</OrderID>

                   <EffectiveCISpecifiedPeriod>

                         <StartDateTime>2015-11-01T00:00:00Z</StartDateTime>

                         <EndDateTime>2015-11-30T00:00:00Z</EndDateTime>

                   </EffectiveCISpecifiedPeriod>

               </AssociatedCIILDocumentLineDocument>

               <SpecifiedCIILSupplyChainTradeAgreement>

                   <NetPriceProductCITradePrice>

                         <ChargeAmount currencyID="EUR">20.0</ChargeAmount>

                   </NetPriceProductCITradePrice>

               </SpecifiedCIILSupplyChainTradeAgreement>

               <SpecifiedCIILSupplyChainTradeDelivery>

                   <BilledQuantity unitCode="HUR">7.0</BilledQuantity>

               </SpecifiedCIILSupplyChainTradeDelivery>

               <SpecifiedCIILSupplyChainTradeSettlement>

                   <SpecifiedCIILTradeSettlementMonetarySummation>

                         <LineTotalAmount currencyID="EUR">140.0</LineTotalAmount>

                   </SpecifiedCIILTradeSettlementMonetarySummation>

               </SpecifiedCIILSupplyChainTradeSettlement>

               <SpecifiedCITradeProduct>

                   <ID schemeAgencyName="EDESS" schemeID="ESPPADOM_PREST">0211.01</ID>

                   <Name>Aide au domicile</Name>

               </SpecifiedCITradeProduct>

           </IncludedCIILSupplyChainTradeLineItem>

Prestation :

 

Identifiant facture

Identifiant commande

 

Période facturée

 

 

 

 

 

Prix net/unité

 

 

 

Nombre d’unités de valeur (ici des heures)

 

 

Montant total

 

 

 

Définition de la prestation

        </CIIHSupplyChainTradeTransaction>

    </CrossIndustryInvoice>

</invoice>

 

 

Nous allons maintenant détailler l’ensemble du message, en commençant par le contexte documentaire du message.

5.5                    Contexte : transaction et identification de la facture

Le premier bloc d’informations du message, obligatoire, traite de données générales (dites « de contexte ») de la facture

5.5.1   Transaction

<xsd:complexType name="CIIHExchangedDocumentContextType">

    <xsd:sequence>

        <xsd:element name="VersionID" type="xsd:token"/>

        <xsd:element name="SpecifiedTransactionID" type="IDType_Unqualified"/>

    </xsd:sequence>

</xsd:complexType>

 

La première information, obligatoire, rencontrée dans un message précise la version du schéma xsd auquel ce message est conforme.

CrossIndustryInvoice / CIIHExchangedDocumentContext / VersionID

 

La seconde information précise l’identifiant de transaction.

CrossIndustryInvoice / CIIHExchangedDocumentContext / SpecifiedTransactionID

Comme nous l’avons déjà précisé, cette information obligatoire est purement technique puisqu’elle sert, pour des raisons de traçabilité à rattacher la facture (qui est représentée par un bloc CrossIndustryInvoice) au lot des autres fichiers envoyés simultanément. Tous les messages CrossIndustryInvoice situés au sein d’un même fichier xml invoice doivent donc avoir un même identifiant de transaction.

 

On trouve ensuite le bloc, obligatoire, qui contient les informations de description de la facture :

5.5.2   Facture

La description dématérialisée de l’entête de la facture s’effectue dans le bloc CIIHExchangedDocument :

 

<xsd:complexType name="CIIHExchangedDocumentType">

    <xsd:sequence>

        <xsd:element name="ID" type="IDType_Unqualified"/>

        <xsd:element name="TypeCode" type="InvoiceDocumentCodeType_CEN_MUG3" minOccurs="0"/>

        <xsd:element name="IssueDateTime" type="DateTimeType"/>

        <xsd:element name="IncludedCINote" type="CINoteType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

Le numéro de facture est une information obligatoire générée par la personne morale ou physique qui émet la facture.

CrossIndustryInvoice / CIIHExchangedDocument / ID

C’est usuellement le prestataire, sauf dans le cas d’autofacturation, où il peut s’agir du donneur d’ordre. On notera que les spécifications européennes précisent que, en cas d’autofacturation (le client émet la facture à la place du fournisseur) la facture devra faire mention du terme «autofacturation». On pourra utiliser la balise IncludedCINote à cette fin.

 

Suit le type de document à choisir au sein de la liste UN/EDIFACT 1001 Document name code[3], pour une facture commerciale classique, utiliser le code 380. Les autres types à considérer sont facture proforma (325), avoir (381) ou acompte (386), ainsi que rapport de transaction pour information seulement (342).

Le code 342 est typiquement celui qui doit être utilisé lorsqu’un mandataire envoie au département un récapitulatif chiffré des interventions pouvant notamment servir de base au paiement vers le bénéficiaire.

CrossIndustryInvoice / CIIHExchangedDocument / TypeCode

Suit la date de facture, information obligatoire.

CrossIndustryInvoice / CIIHExchangedDocument / IssueDateTime

Un bloc optionnel permet de préciser une note en texte libre.

CrossIndustryInvoice / CIIHExchangedDocument / IncludedCINote

5.6                    Prestataire et donneur d’ordre

Nous quittons les informations documentaires et entrons maintenant dans le « corps » de la facture.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction

et plus précisément dans les informations qui décrivent les opérateurs : prestataire et donneur d’ordre

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeAgreement

La description XSD de ce bloc est la suivante :

 

<xsd:complexType name="CIIHSupplyChainTradeAgreementType">

    <xsd:sequence>

        <xsd:element name="SellerCITradeParty" type="CITradePartyType_Seller"/>

        <xsd:element name="BuyerCITradeParty" type="CITradePartyType_Buyer"/>

        <xsd:element name="BuyerOrderReferencedCIReferencedDocument" type="CIReferencedDocumentType_Buyer" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

Balise

Type

Cardinalité

SellerCITradeParty

CITradePartyType_Seller

1

BuyerCITradeParty

CITradePartyType_Buyer

1

BuyerOrderReferencedCIReferencedDocument

CIReferencedDocumentType_Buyer

0..1

 

Soit :

§  2 CITradePartyType, qui représentent des personnes (morales ou physiques) : le prestataire (SellerCITradeParty) et le donneur d’ordre (BuyerCITradeParty).

§  1 CIReferencedDocumentType_Buyer, qui représente l’identifiant du bon de commande.

5.6.1   Prestataire

Le premier acteur décrit est le prestataire, celui qui exécute la prise en charge et émet la facture.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeAgreement / SellerCITradeParty

Ce bloc d’information est obligatoire. Il est dérivé du type CITradePartyType décrit au chapitre 2.

 

<xsd:complexType name="CITradePartyType_Seller">

    <xsd:complexContent>

        <xsd:extension base="CITradePartyType">

           <xsd:sequence>

               <xsd:element name="SpecifiedCITaxRegistration" type="CITaxRegistrationType_Seller" minOccurs="0"/>

               <xsd:element name="EndPointURICIUniversalCommunication" type="CIUniversalCommunicationType_Qualified_URI" minOccurs="0"/>

           </xsd:sequence>

        </xsd:extension>

    </xsd:complexContent>

</xsd:complexType>

 

Sa particularité est de contenir une balise SpecifiedCITaxRegistration qui permet de préciser le numéro de TVA intracommunautaire et une balise EndPointURICIUniversalCommunication qui permet d’indiquer une adresse e-mail.

 

<xsd:complexType name="CITaxRegistrationType_Seller">

    <xsd:sequence>

        <xsd:element name="ID" type="IDType_Qualified" minOccurs="0"/>

        <xsd:element name="AssociatedCIRegisteredTax" type="CIRegisteredTaxType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

5.6.2   Donneur d’ordre

Le donneur d’ordre est décrit au sein du bloc de données obligatoire

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeAgreement / BuyerCITradeParty

Ce bloc d’information est obligatoire. Il est dérivé du type CITradePartyType décrit au chapitre 2.

 

<xsd:complexType name="CITradePartyType_Buyer">

    <xsd:complexContent>

        <xsd:extension base="CITradePartyType">

           <xsd:sequence>

               <xsd:element name="SpecifiedCITaxRegistration" type="CITaxRegistrationType_Buyer" minOccurs="0"/>

               <xsd:element name="EndPointURICIUniversalCommunication" type="CIUniversalCommunicationType_Qualified_URI" minOccurs="0"/>

           </xsd:sequence>

        </xsd:extension>

    </xsd:complexContent>

</xsd:complexType>

 

Sa particularité est de contenir une balise SpecifiedCITaxRegistration qui permet de préciser le numéro de TVA intracommunautaire et une balise EndPointURICIUniversalCommunication qui permet d’indiquer une adresse e-mail.

 

Rappelons que le numéro d'identification TVA du client n’est obligatoire sur la facture que si celui-ci est redevable de la taxe sur l'opération, c'est-à-dire s’il s’agit d’une procédure d'autoliquidation (en anglais « reverse charge »). L'autoliquidation de TVA consiste, pour le vendeur ou le prestataire, à facturer hors taxe le client en lui laissant la charge de payer la TVA aux impôts. Ce mécanisme a été mis en place pour réglementer le cadre juridique de la TVA dans le cadre d'opérations réalisées par des prestataires ou des vendeurs établis hors du territoire français. L'autoliquidation permet d'éviter que les sociétés étrangères, qui facturent en France, soient contraintes de s'immatriculer sur le territoire français pour déposer des déclarations de TVA en France.

 

<xsd:complexType name="CITaxRegistrationType_Buyer">

    <xsd:sequence>

        <xsd:element name="ID" type="IDType_Qualified" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

5.6.3   Identifiant de commande

Le bloc de données décrivant le donneur d’ordre est suivi par la l’identifiant de la commande :

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeAgreement / BuyerOrderReferencedCIReferencedDocument

Cette balise contient un bloc d’information au format CIReferencedDocumentType_Buyer :

 

<xsd:complexType name="CIReferencedDocumentType_Buyer">

    <xsd:sequence>

        <xsd:element name="IssuerAssignedID" type="IDUnqualifiedType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

Qui permet, au sein de la balise IssuerAssignedID, de spécifier le numéro de commande :

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeAgreement / BuyerOrderReferencedCIReferencedDocument / IssuerAssignedID

Au sein du message Order, cette information est située au chemin :

CrossIndustryOrder / CIOHExchangedDocument / ID

Le chapitre ApplicableCIIHSupplyChainTradeAgreement, qui précise les intervenants au contrat et la nature du contrat se clôt à ce stade et nous entrons dans le chapitre des instructions de délivrance des prestations au sein duquel se trouve le bénéficiaire.

5.7                    Bénéficiaire

Le type CIIHSupplyChainTradeDeliveryType contient deux balises qui permettent de décrire le bénéficiaire et la date de prestation ou d’arrêté des prestations :

 

<xsd:complexType name="CIIHSupplyChainTradeDeliveryType">

    <xsd:sequence>

        <xsd:element name="ShipToCITradeParty" type="CITradePartyType_ShipTo" minOccurs="0"/>

        <xsd:element name="ActualDeliveryCISupplyChainEvent" type="CIIHSupplyChainEventType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

Le bénéficiaire est décrit au chapitre

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeDelivery / ShipToCITradeParty

Ce bloc d’informations, au format CITradePartyType a déjà été décrit au chapitre 2.

On peut remarquer que cette information est optionnelle, puisqu’une facture présentée par un prestataire à un donneur d’ordre pourrait ne pas concerner un bénéficiaire. Dans le cas classique où un bénéficiaire est concerné, il faudra le spécifier à l’aide de cette balise.

 

La date d’arrêté des prestations peut être indiquée grâce à la balise ActualDeliveryCISupplyChainEvent au format CIIHSupplyChainEventType :

 

<xsd:complexType name="CIIHSupplyChainEventType">

    <xsd:sequence>

        <xsd:element name="OccurrenceDateTime" type="DateTimeType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

Cette information est donc attachée au chemin :

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeDelivery / ActualDeliveryCISupplyChainEvent / OccurrenceDateTime

5.8                    Conditions financières

Les informations financières sont précisées au sein du bloc

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement

Elles sont décrites par le type CIIHSupplyChainTradeSettlementType:

 

<xsd:complexType name="CIIHSupplyChainTradeSettlementType">

    <xsd:sequence>

        <xsd:element name="DuePayableAmount" type="AmountType"/>

        <xsd:element name="PaymentReference" type="TextType" minOccurs="0"/>

        <xsd:element name="InvoiceCurrencyCode" type="CodeType_ISO_4217"/>

        <xsd:element name="SpecifiedCITradeSettlementPaymentMeans" type="CITradeSettlementPaymentMeansType" minOccurs="0"/>

        <xsd:element name="ApplicableCITradeTax" type="CITradeTaxType" minOccurs="0" maxOccurs="unbounded"/>

        <xsd:element name="BillingCISpecifiedPeriod" type="CISpecifiedPeriodType" minOccurs="0"/>

        <xsd:element name="SpecifiedCITradeAllowanceCharge" type="CIIHTradeAllowanceChargeType" minOccurs="0" maxOccurs="unbounded"/>

        <xsd:element name="SpecifiedCITradePaymentTerms" type="CITradePaymentTermsType" minOccurs="0"/>

        <xsd:element name="SpecifiedCIIHTradeSettlementMonetarySummation" type="CIIHTradeSettlementMonetarySummationType"/>

        <xsd:element name="ReceivableSpecifiedCITradeAccountingAccount" type="CITradeAccountingAccountType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

Soit :

 

 

Balise

Type

Cardinalité

Montant total dû

DuePayableAmount

AmountType

1

Référence de paiement

PaymentReference

TextType

0..1

Devise pour la facture

InvoiceCurrencyCode

CodeType_ISO_4217

1

Moyen de paiement

SpecifiedCITradeSettlementPaymentMeans

CITradeSettlementPaymentMeansType

0..1

Taxes applicables

ApplicableCITradeTax

CITradeTaxType

0..n

Période facturée

BillingCISpecifiedPeriod

CISpecifiedPeriodType

0..1

Remises et frais

SpecifiedCITradeAllowanceCharge

CIIHTradeAllowanceChargeType

0..n

Echéance de paiement

SpecifiedCITradePaymentTerms

CITradePaymentTermsType

0..1

Détails de calcul

SpecifiedCIIHTradeSettlementMonetarySummation

CIIHTradeSettlementMonetarySummationType

1

Référence comptable

ReceivableSpecifiedCITradeAccountingAccount

CITradeAccountingAccountType

0..1

 

Précisons que la balise optionnelle PaymentReference contient simplement une référence fournie par le prestataire au donneur d’ordre afin qu’il la précise comme identifiant de paiement.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / PaymentReference

5.8.1   Gestion des décimales

Avant de détailler ces blocs d’information, rappelons la règle 9 du CWA 16356-2 :

 

Rule 9 (Decimals)

Currency amounts are stated with maximum 2 decimals rounded as necessary.

VAT rates are stated as percentages with maximum 2 decimals. E.g. twenty one and one third percent is

stated as 21.33

Quantity is stated with maximum 3 decimals.

Unit prices are stated with maximum of 4 decimals.

 

En application de cette règle :

§  les montants doivent être représentés avec au plus deux décimales,

§  les taux de TVA doivent être exprimés en pourcent, avec au plus deux décimales,

§  les quantités de produit doivent être représentés avec au plus trois décimales,

§  les prix unitaires doivent être représentés avec au plus quatre décimales.

5.8.2   Montant total dû

La balise DuePayableAmount (INV061), unique et obligatoire, indique le montant total toutes taxes comprises à régler.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / DuePayableAmount

5.8.3   Devise

La balise InvoiceCurrencyCode (INV007), unique et obligatoire, indique la monnaie dans laquelle tous les montants précisés au sein de la facture sont exprimés.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / InvoiceCurrencyCode

Cette monnaie est précisée en utilisant la norme ISO 4217 dont le code pour l’Euro est EUR.

5.8.4   Informations bancaires du prestataire

La balise optionnelle SpecifiedCITradeSettlementPaymentMeans permet de spécifier l’identification bancaire du prestataire.

 

Elle est de type CITradeSettlementPaymentMeansType :

 

<xsd:complexType name="CITradeSettlementPaymentMeansType">

    <xsd:sequence>

        <xsd:element name="TypeCode" type="CodeType_CEN_MUG4" minOccurs="0"/>

        <xsd:element name="PayeePartyCICreditorFinancialAccount" type="CICreditorFinancialAccountType" minOccurs="0"/>

        <xsd:element name="PayeeSpecifiedCICreditorFinancialInstitution" type="CICreditorFinancialInstitutionType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

Soit :

 

 

Balise

Type

Cardinalité

Mode de paiement

TypeCode

CodeType_CEN_MUG4

0..1

IBAN du prestataire

PayeePartyCICreditorFinancialAccount

CICreditorFinancialAccountType

0..1

BIC du prestataire

PayeeSpecifiedCICreditorFinancialInstitution

CICreditorFinancialInstitutionType

0..1

 

La balise TypeCode permet de spécifier le moyen de paiement. Il utilise la liste MUG-4 détaillée en annexe. Le code "31" indique un virement et spécifie (règle 10 du CWA 16356-2) que les autres balises doivent indiquer respectivement l’IBAN et le BIC du prestataire.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / SpecifiedCITradeSettlementPaymentMeans

La balise PayeePartyCICreditorFinancialAccount permet de préciser les coordonnées bancaires du prestataire afin que le donneur d’ordre puisse effectuer le transfert.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / PayeePartyCICreditorFinancialAccount

Cette balise est au type CICreditorFinancialAccountType :

 

<xsd:complexType name="CICreditorFinancialAccountType">

    <xsd:sequence>

        <xsd:element name="IBANID" type="IDQualifiedType" minOccurs="0"/>

        <xsd:element name="ProprietaryID" type="IDQualifiedType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

Sa balise IBANID (INV043) permet de préciser l’IBAN du prestataire (International Bank Account Number).

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / PayeePartyCICreditorFinancialAccount / IBANID

La balise PayeeSpecifiedCICreditorFinancialInstitution permet de préciser l’établissement bancaire du prestataire afin que le donneur d’ordre puisse effectuer le transfert.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / PayeeSpecifiedCICreditorFinancialInstitution

Cette balise est au type CICreditorFinancialInstitutionType :

 

<xsd:complexType name="CICreditorFinancialInstitutionType">

    <xsd:sequence>

        <xsd:element name="BICID" type="IDUnqualifiedType" minOccurs="0"/>

        <xsd:element name="SubDivisionBranchFinancialInstitution" type="BranchFinancialInstitutionType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

La balise optionnelle BICID (INV045) permet de préciser le code BIC de l’établissement bancaire du prestataire (Bank Identifier Code).

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / PayeeSpecifiedCICreditorFinancialInstitution / BICID

La balise optionnelle SubDivisionBranchFinancialInstitution (INV044) permet, dans certains pays, de sur-préciser l’établissement bancaire du prestataire par sa branche ou sous-division.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / PayeeSpecifiedCICreditorFinancialInstitution / SubDivisionBranchFinancialInstitution

 

5.8.5   Taux de TVA

La balise ApplicableCITradeTax, multiple et optionnelle, permet de préciser le (ou les) taux de TVA utilisés au sein de la facture.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / ApplicableCITradeTax

<xsd:complexType name="CITradeTaxType">

    <xsd:sequence>

        <xsd:element name="CalculatedAmount" type="AmountType"/>

        <xsd:element name="TypeCode" type="TaxTypeCodeType_UNCL_5153" fixed="VAT"/>

        <xsd:element name="ExemptionReason" type="TextType" minOccurs="0"/>

        <xsd:element name="BasisAmount" type="AmountType"/>

        <xsd:element name="CategoryCode" type="CodeType_CEN_MUG1"/>

        <xsd:element name="RateApplicablePercent" type="PercentType"/>

    </xsd:sequence>

</xsd:complexType>

 

Soit :

 

 

Balise

Type

Cardinalité

Montant de TVA pour ce taux

CalculatedAmount

AmountType

1

Type de taxe – fixé à "TVA"

TypeCode

TaxTypeCodeType_UNCL_5153

1

Motif d’exemption

ExemptionReason

TextType

0..1

Base HT pour ce taux

BasisAmount

AmountType

1

Code catégorie pour ce taux

CategoryCode

CodeType_CEN_MUG1

1

Pourcentage

RateApplicablePercent

PercentType

1

 

La balise CalculatedAmount (INV051), unique et obligatoire, permet de préciser le montant de la TVA calculée à ce taux.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / ApplicableCITradeTax / CalculatedAmount

La balise TypeCode, unique et obligatoire, permet de préciser le type de taxe ; par convention, elle est fixée à la valeur "VAT" qui spécifie une taxe à la valeur ajoutée.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / ApplicableCITradeTax / TypeCode

La balise ExemptionReason, unique et optionnelle, permet de préciser le motif d’exemption, au cas où le code de catégorie préciserait que la TVA ne s’applique pas.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / ApplicableCITradeTax / ExemptionReason

La balise BasisAmount (INV050), unique et obligatoire, permet de préciser le montant hors taxe de la facture concerné par ce taux de TVA.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / ApplicableCITradeTax / BasisAmount

La balise CategoryCode, unique et obligatoire, permet de préciser le code de catégorie attribué à ce taux de TVA.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / ApplicableCITradeTax / CategoryCode

Cette catégorie doit être choisie au sein de la liste MUG-1 version 2011-8 du CEN :

 

<xsd:complexType name="CodeType_CEN_MUG1">

    <xsd:simpleContent>

        <xsd:extension base="xsd:token">

           <xsd:attribute name="listID" type="xsd:token" use="required" fixed="MUG-1"/>

           <xsd:attribute name="listAgencyName" type="xsd:string" use="required" fixed="CEN"/>

           <xsd:attribute name="listVersionID" type="xsd:token" use="required" fixed="2011-8"/>

        </xsd:extension>

    </xsd:simpleContent>

</xsd:complexType>

 

T01

Taxed at rate level 1

Code specifying the VAT rate at a User Defined Level 1.

T02

Taxed at rate level 2

Code specifying the VAT rate at a User Defined Level 2.

T03

Taxed at rate level 3

Code specifying the VAT rate at a User Defined Level 3.

T04

Taxed at rate level 4

Code specifying the VAT rate at a User Defined Level 4.

T05

Taxed at rate level 5

Code specifying the VAT rate at a User Defined Level 5.

T06

Taxed at rate level 6

Code specifying the VAT rate at a User Defined Level 6.

T07

Taxed at rate level 7

Code specifying the VAT rate at a User Defined Level 7.

T08

Taxed at rate level 8

Code specifying the VAT rate at a User Defined Level 8.

T09

Taxed at rate level 9

Code specifying the VAT rate at a User Defined Level 9.

AE

VAT Reverse Charge

Code specifying that the VAT rate is levied from the invoicee.

E

Exempt from tax

Code specifying that taxes are not applicable.

Z

Zero rated goods

Code specifying that the goods are at a zero rate.

O

Outside scope of tax

Code specifying that taxes are not applicable.

IC

Intra-Community Supply

Code specifying that the VAT rate is levied from the invoicee for Intra-Community supplies.

 

Note : Codes T01 - T09 are used in conjunction with a percentage rate in a particular invoice and convey no meaning outside the context of that invoice.

 

En routine, on sélectionnera donc un code dans l’intervalle T01 à T09 afin que les lignes de la facture puissent s’y référer.

 

Enfin, la balise RateApplicablePercent (INV096), unique et obligatoire, permet de préciser le taux de TVA en pourcent.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / ApplicableCITradeTax / RateApplicablePercent

5.8.6   Période facturée

La balise BillingCISpecifiedPeriod, unique et optionnelle, indique la période facturée.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / BillingCISpecifiedPeriod

Son type, CISpecifiedPeriodType, permet d’indiquer une date de début et une date de fin pour définir la période d’exécution de services qui fait l’objet de la facture.

5.8.7   Remises et frais

La balise SpecifiedCITradeAllowanceCharge optionnelle et multiple permet d’énumérer les remises et les frais. Les remises sont retranchées du montant total HT tandis que les frais lui sont ajoutés ; ces sommes sont nettes et hors taxe.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / SpecifiedCITradeAllowanceCharge

Son type, CIIHTradeAllowanceChargeType, permet de préciser chaque remise ou frais.

 

<xsd:complexType name="CIIHTradeAllowanceChargeType">

    <xsd:sequence>

        <xsd:element name="ChargeIndicator" type="IndicatorType"/>

        <xsd:element name="ActualAmount" type="AmountType"/>

        <xsd:element name="ReasonCode" type="AdjustmentReasonCodeUNCL4465Type" minOccurs="0"/>

        <xsd:element name="Reason" type="TextType"/>

        <xsd:element name="CategoryCITradeTax" type="CITradeTaxType_Category" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

La balise ChargeIndicator, obligatoire, indique le statut frais ou remise ; ses seules valeurs autorisées sont "true", s’il s’agit de frais, et "false" s’il s’agit d’une remise.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / SpecifiedCITradeAllowanceCharge / ChargeIndicator

La balise ActualAmount (INV047), obligatoire, donne le montant net hors taxe.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / SpecifiedCITradeAllowanceCharge / ActualAmount

La balise optionnelle ReasonCode fournit le motif de remise ou charge au format UN/EDIFACT 4465.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / SpecifiedCITradeAllowanceCharge / ReasonCode

La balise Reason, obligatoire, fournit le libellé du motif de remise ou charge.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / SpecifiedCITradeAllowanceCharge / Reason

La balise optionnelle CategoryCITradeTax fournit la catégorie de TVA applicable à cette remise ou charge.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / SpecifiedCITradeAllowanceCharge / CategoryCITradeTax

5.8.8   Echéance de paiement

La balise SpecifiedCITradePaymentTerms, unique et optionnelle, indique la date limite de paiement.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / SpecifiedCITradePaymentTerms

Son type, CITradePaymentTermsType, permet d’indiquer une date et un texte descriptif.

 

<xsd:complexType name="CITradePaymentTermsType">

    <xsd:sequence>

        <xsd:element name="Description" type="TextType" minOccurs="0"/>

        <xsd:element name="DueDateDateTime" type="DateTimeType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

5.8.9   Détails de calcul du montant total dû

La balise SpecifiedCIIHTradeSettlementMonetarySummation, unique et obligatoire, permet de détailler les étapes de calcul qui aboutissent au montant total dû, comme le montant hors taxe, le montant des taxes, la remise appliquée.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / SpecifiedCIIHTradeSettlementMonetarySummation

Cette balise a pour type CIIHTradeSettlementMonetarySummationType :

 

<xsd:complexType name="CIIHTradeSettlementMonetarySummationType">

    <xsd:sequence>

        <xsd:element name="LineTotalAmount" type="AmountType"/>

        <xsd:element name="ChargeTotalAmount" type="AmountType" minOccurs="0"/>

        <xsd:element name="AllowanceTotalAmount" type="AmountType" minOccurs="0"/>

        <xsd:element name="TaxBasisTotalAmount" type="AmountType"/>

        <xsd:element name="TaxTotalAmount" type="AmountType" minOccurs="0" maxOccurs="2"/>

        <xsd:element name="RoundingAmount" type="AmountType" minOccurs="0"/>

        <xsd:element name="GrandTotalAmount" type="AmountType"/>

        <xsd:element name="TotalPrepaidAmount" type="AmountType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

Soit :

 

 

Balise

Type

Cardinalité

Montant total des lignes HT

LineTotalAmount

AmountType

1

Somme des remises

ChargeTotalAmount

AmountType

0..1

Somme des charges

AllowanceTotalAmount

AmountType

0..1

Base d’application de la TVA

TaxBasisTotalAmount

AmountType

1

Montant total de la TVA

TaxTotalAmount

AmountType

0..2

Montant de l’arrondi

RoundingAmount

AmountType

0..1

Grand total (avec TVA et arrondi)

GrandTotalAmount

AmountType

1

Montant prépayé, à déduire

TotalPrepaidAmount

AmountType

0..1

 

5.8.9.1 Montant total HT des lignes

Le montant contenu dans la balise LineTotalAmount (INV054), unique et obligatoire, représente la somme hors taxe des lignes de la facture hors TVA.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / SpecifiedCIIHTradeSettlementMonetarySummation / LineTotalAmount

5.8.9.2 Montant total HT des charges

Le montant contenu dans la balise ChargeTotalAmount (INV058), unique et optionnelle, représente la somme des charges hors TVA.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / SpecifiedCIIHTradeSettlementMonetarySummation / ChargeTotalAmount

5.8.9.3 Montant total HT des remises

Le montant contenu dans la balise AllowanceTotalAmount (INV057), unique et optionnelle, représente la somme des remises hors TVA.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / SpecifiedCIIHTradeSettlementMonetarySummation / AllowanceTotalAmount

5.8.9.4 Base d’application de la TVA

Le montant contenu dans la balise TaxBasisTotalAmount (INV055), unique et obligatoire, représente le montant total de la facture, avant arrondi, hors TVA. C’est la base d’application de la TVA.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / SpecifiedCIIHTradeSettlementMonetarySummation / TaxBasisTotalAmount

5.8.9.5 Montant total de la TVA

Le montant contenu dans la balise TaxTotalAmount (INV049), représente le montant total de la TVA. C'est-à-dire la somme des montants de TVA calculés pour chaque taux.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / SpecifiedCIIHTradeSettlementMonetarySummation / TaxTotalAmount

5.8.9.6 Montant total de l’arrondi

Le montant contenu dans la balise RoundingAmount (INV060), représente le montant, positif ou négatif, qu’il faudra ajouter au total de facture pour obtenir le « grand total ».

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / SpecifiedCIIHTradeSettlementMonetarySummation / RoundingAmount

5.8.9.7 Grand total

Le montant contenu dans la balise GrandTotalAmount (INV056), unique et obligatoire, représente le montant TTC, avec application de l’arrondi, des services facturés.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / SpecifiedCIIHTradeSettlementMonetarySummation / GrandTotalAmount

5.8.9.8 Montant à déduire

Le montant contenu dans la balise TotalPrepaidAmount (INV059), représente un montant déjà payé, à déduire du « grand total » pour obtenir la somme à régler.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / SpecifiedCIIHTradeSettlementMonetarySummation / TotalPrepaidAmount

5.8.9.9 Mode opératoire

D’après la Règle 2, le mode opératoire de calcul de toutes ces variables est la suivante :

 

Opération

Variable

ID

Exemple

+

Somme des lignes

INV054

321,82

-

Somme des remises

INV057

9,20

+

Somme des charges

INV058

7,60

=

Total Hors Taxe

INV055

320,22

+

TVA totale

INV049

40,25

+

Arrondi

INV060

-0,47

=

Total TTC

INV056

360,00

-

Déjà versé

INV059

120,00

=

Paiement dû

INV061

240,00

 

Le montant total hors taxe INV055 est calculé en sommant les montants hors taxe de chaque ligne de la facture, en déduisant les remises et en ajoutant les charges.

Le montant total de la TVA INV049 est calculé de la même façon en sommant les montants de TVA de chaque ligne de la facture, en déduisant la TVA des remises et en ajoutant la TVA des charges.

L’arrondi INV060 est calculé en faisant la différence entre Sh, qui est une somme de valeurs arrondies à deux décimales, et l’arrondi final de la somme de ces valeurs. En résumé, « entre la somme des arrondis et l’arrondi de la somme ».

 

Le « grand total », INV056 est calculé en effectuant la somme des trois montants précédents : INV056 = INV055 + INV049 + INV060

Enfin, par soustraction à ce grand total d’un éventuel montant prépayé INV059, on obtient le total à payer de la facture.

 

On calcule l’arrondi par différence entre la somme des prix et la somme des prix arrondis ; par exemple :

 

 

Quantité

Prix unitaire

% TVA

Prix

Prix arrondi

TVA

Ligne 1

25,5

19,75

5,5

503,625

503,63

27,6994

Ligne 2

12,5

19,75

5,5

246,875

246,88

13,5781

Ligne 3

13,3

19,75

5,5

262,675

262,68

14,4471

Total

 

 

 

1013,175

1013,19

55,7246

 

Dans ce cas :

 

INV054

LineTotalAmount

1013,19

Total des « prix arrondis »

Sb

TaxBasisTotalAmount

1013,175

Total des prix

INV049

TaxTotalAmount

55,72

Arrondi du Total TVA

INV060

RoundingAmount

- 0,02

Arrondi de (Sb - INV054)

INV056

GrandTotalAmount

1 068,89

INV054 + INV049 + INV060

 

Les règles de conformité à vérifier sont les suivantes :

ü  Somme des lignes        INV054 = somme des montants nets de chaque ligne (somme des INV065)

ü  Total HT                       INV055 = INV054 - INV057 + INV058

ü  Total TTC                      INV056 = INV055 + INV049 + INV060

ü  Remise totale               INV057 = somme des INV047 avec ChargeIndicator = false

ü  Charge totale               INV058 = somme des INV047 avec ChargeIndicator = true

ü  Paiement dû                 INV061 = INV056 – INV059

5.8.10                Référence d’imputation comptable

La balise ReceivableSpecifiedCITradeAccountingAccount, unique et optionnelle, indique la référence d’imputation comptable.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / ReceivableSpecifiedCITradeAccountingAccount

Il permet simplement de préciser un identifiant :

 

<xsd:complexType name="CITradeAccountingAccountType">

    <xsd:sequence>

        <xsd:element name="ID" type="IDUnqualifiedType"/>

    </xsd:sequence>

</xsd:complexType>

 

Cette information provient généralement du bon de commande ; au sein du message Order, elle est attachée au chemin :

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / ApplicableCIOHSupplyChainTradeSettlement / PayableSpecifiedCITradeAccountingAccount / ID

5.9                    Liste des prestations facturées

La liste des prestations facturées (les « lignes de la facture ») occupent un bloc multiple et obligatoire.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / IncludedCIILSupplyChainTradeLineItem

<xsd:complexType name="CIILSupplyChainTradeLineItemType">

    <xsd:sequence>

        <xsd:element name="AssociatedCIILDocumentLineDocument" type="CIILDocumentLineDocumentType"/>

        <xsd:element name="SpecifiedCIILSupplyChainTradeAgreement" type="CIILSupplyChainTradeAgreementType" minOccurs="0"/>

        <xsd:element name="SpecifiedCIILSupplyChainTradeDelivery" type="CIILSupplyChainTradeDeliveryType"/>

        <xsd:element name="SpecifiedCIILSupplyChainTradeSettlement" type="CIILSupplyChainTradeSettlementType"/>

        <xsd:element name="SpecifiedCITradeProduct" type="CITradeProductType"/>

    </xsd:sequence>

</xsd:complexType>

 

Si la facture ne contient qu’un seul service, il n’y aura qu’une seule ligne de facturation, et ce bloc sera unique ; si plusieurs services sont facturés, il y aura autant de blocs IncludedCIILSupplyChainTradeLineItem que de services.

 

Chaque ligne contient cinq ensembles d’informations : l’identification de la ligne, le prix unitaire, les informations de mise en œuvre, les conditions financières et la description du service.

 

 

Balise

Type

Cardinalité

Identification

AssociatedCIILDocumentLineDocument

CIILDocumentLineDocumentType

1

Agrément financier

SpecifiedCIILSupplyChainTradeAgreement

CIILSupplyChainTradeAgreementType

0..1

Mise en œuvre

SpecifiedCIILSupplyChainTradeDelivery

CIILSupplyChainTradeDeliveryType

1

Conditions financières

SpecifiedCIILSupplyChainTradeSettlement

CIILSupplyChainTradeSettlementType

1

Description

SpecifiedCITradeProduct

CITradeProductType

1

 

5.9.1   Identification

Le premier élément d’une ligne de commande est un bloc d’identification, unique et obligatoire :

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / IncludedCIILSupplyChainTradeLineItem / AssociatedCIILDocumentLineDocument

<xsd:complexType name="CIILDocumentLineDocumentType">

    <xsd:sequence>

        <xsd:element name="LineID" type="IDType_Unqualified"/>

        <xsd:element name="OrderID" type="IDType_Unqualified"/>

        <xsd:element name="IncludedCINote" type="CINoteType" minOccurs="0"/>

        <xsd:element name="EffectiveCISpecifiedPeriod" type="CISpecifiedPeriodType" minOccurs="0"/>

        <xsd:element name="SpecialLine" type="SpecialLineType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

L’identification comprend l’identifiant de la ligne, unique et obligatoire, l’identifiant de la prestation commandée correspondante, unique et obligatoire, ainsi que deux éléments uniques et optionnels : une note en texte libre et une période de validité de cette ligne de commande.

 

L’identifiant de la prestation est attaché au chemin

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / IncludedCIILSupplyChainTradeLineItem / AssociatedCIILDocumentLineDocument / LineID

Cet identifiant doit référencer la prestation facturée de façon absolue. Ce n’est explicitement pas un identifiant défini dans le contexte local de cette facture (par exemple, troisième prestation facturée).

 

L’identifiant de la prestation commandée correspondante est attaché au chemin

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / IncludedCIILSupplyChainTradeLineItem / AssociatedCIILDocumentLineDocument / OrderID

Cette information sera usuellement véhiculée lors de la transmission du plan de charge au sein d’un message Order : on la trouve alors attaché au chemin :

CrossIndustryOrder / CIOHSupplyChainTradeTransaction / IncludedCIOLSupplyChainTradeLineItem / AssociatedCIOLDocumentLineDocument / LineID

 

La note optionnelle est attachée au chemin

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / IncludedCIILSupplyChainTradeLineItem / AssociatedCIILDocumentLineDocument / IncludedCINote / Content

La période de validité du service facturé par cette ligne est représentée par une date de début et une date de fin. Cette période doit être située au sein du plan d’aide ; si la prestation doit débuter à une date précise sans date de fin explicite, alors EndDateTime doit contenir la date de fin du plan d’aide :

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / IncludedCIILSupplyChainTradeLineItem / AssociatedCIILDocumentLineDocument / EffectiveCISpecifiedPeriod / StartDateTime

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / IncludedCIILSupplyChainTradeLineItem / AssociatedCIILDocumentLineDocument / EffectiveCISpecifiedPeriod / EndDateTime

Certaines lignes de facture peuvent appartenir à un type particulier, par exemple une ligne de régularisation, qui complète une ligne précédemment facturée (par exemple en cas de changement de tarif) ou une ligne de complément qui ajoute après coup une ligne à une facture déjà émise. Ces spécificités peuvent être déclarées grâce à la balise SpecialLine, attachée au chemin

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / IncludedCIILSupplyChainTradeLineItem / AssociatedCIILDocumentLineDocument / SpecialLine

Le bloc de détail étant décrit par :

 

<xsd:complexType name="SpecialLineType">

    <xsd:sequence>

        <xsd:element name="LineType" type="IDQualifiedType"/>

        <xsd:element name="RegularizedLineID" type="IDUnqualifiedType" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

La valeur de la balise LineType étant à choisir au sein de la liste ESPPADOM_INVOICE_LINE_TYPE.

En cas de régularisation, la ligne régularisée doit être indiquée au sein de la balise RegularizedLineID.

En cas de complément, on utilisera la balise déjà existante OrderID pour préciser la facture qui fait l’objet d’un complément.

5.9.2   Agrément financier

Les données financières du service facturé à cette ligne sont précisées dans un bloc unique et optionnel ; qui précise l’agrément financier entre les parties concernant cette ligne (typiquement une modification du prix unitaire) :

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / IncludedCIILSupplyChainTradeLineItem / SpecifiedCIILSupplyChainTradeAgreement

<xsd:complexType name="CIILSupplyChainTradeAgreementType">

    <xsd:sequence>

        <xsd:element name="BuyerOrderReferencedCIReferencedDocument" type="CIReferencedDocumentType_OrderReference" minOccurs="0"/>

        <xsd:element name="GrossPriceProductCITradePrice" type="CITradePriceType_Gross" minOccurs="0"/>

        <xsd:element name="NetPriceProductCITradePrice" type="CITradePriceType_Net" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

5.9.2.1 Calcul du prix unitaire net

La balise GrossPriceProductCITradePrice, unique et optionnelle, permet de préciser les règles de calcul du prix unitaire net :

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / IncludedCIILSupplyChainTradeLineItem / SpecifiedCIILSupplyChainTradeAgreement / GrossPriceProductCITradePrice

<xsd:complexType name="CITradePriceType_Gross">

    <xsd:sequence>

        <xsd:element name="ChargeAmount" type="AmountType"/>

        <xsd:element name="AppliedCITradeAllowanceCharge" type="CITradeAllowanceChargeType_Gross" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

La balise ChargeAmount (INV077) indique le prix unitaire brut, avant adaptation :

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / IncludedCIILSupplyChainTradeLineItem / SpecifiedCIILSupplyChainTradeAgreement / GrossPriceProductCITradePrice / ChargeAmount

Le bloc AppliedCITradeAllowanceCharge permet d’indiquer l’ajustement effectué :

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / IncludedCIILSupplyChainTradeLineItem / SpecifiedCIILSupplyChainTradeAgreement / GrossPriceProductCITradePrice / AppliedCITradeAllowanceCharge

<xsd:complexType name="CITradeAllowanceChargeType_Gross">

    <xsd:sequence>

        <xsd:element name="ActualAmount" type="AmountType"/>

        <xsd:element name="ReasonCode" type="AdjustmentReasonCodeUNCL4465Type" fixed="77"/>

    </xsd:sequence>

</xsd:complexType>

 

La balise ActualAmount (INV076) permet d’indiquer le montant de l’ajustement unitaire :

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / IncludedCIILSupplyChainTradeLineItem / SpecifiedCIILSupplyChainTradeAgreement / GrossPriceProductCITradePrice / AppliedCITradeAllowanceCharge / ActualAmount

La balise ReasonCode permet d’indiquer le motif d’ajustement, elle est, par convention, fixée à 77 (ristourne) :

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / IncludedCIILSupplyChainTradeLineItem / SpecifiedCIILSupplyChainTradeAgreement / GrossPriceProductCITradePrice / AppliedCITradeAllowanceCharge / ReasonCode

5.9.2.2 Prix unitaire net

Le bloc NetPriceProductCITradePrice, unique et optionnel, indique le prix unitaire net, après adaptation :

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / IncludedCIILSupplyChainTradeLineItem / SpecifiedCIILSupplyChainTradeAgreement / NetPriceProductCITradePrice

<xsd:complexType name="CITradePriceType_Net">

    <xsd:sequence>

        <xsd:element name="ChargeAmount" type="AmountType"/>

    </xsd:sequence>

</xsd:complexType>

 

Il n’héberge qu’une balise ChargeAmount (INV075), unique et obligatoire, qui contient le prix net calculé après remise :

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / IncludedCIILSupplyChainTradeLineItem / SpecifiedCIILSupplyChainTradeAgreement / NetPriceProductCITradePrice / ChargeAmount

La règle 8 du CWA 16356-2 précise que ce prix unitaire net INV075 doit être égal au prix unitaire brut INV077 déduit de la remise INV076.

 

Price calculation (rule 8)

The net price of an item SHOULD be equal to the gross price less the discounted amount.

Net price (INV075) SHOULD equal gross price (INV077) less price discount (INV076) amount.

5.9.3   Informations de mise en œuvre

Les informations de mise en œuvre sont décrites dans un bloc unique et obligatoire :

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / IncludedCIILSupplyChainTradeLineItem / SpecifiedCIILSupplyChainTradeDelivery

<xsd:complexType name="CIILSupplyChainTradeDeliveryType">

    <xsd:sequence>

        <xsd:element name="BilledQuantity" type="QuantityType"/>

    </xsd:sequence>

</xsd:complexType>

 

Elle ne contient qu’une balise BilledQuantity, unique et obligatoire, la quantité globale facturée.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / IncludedCIILSupplyChainTradeLineItem / SpecifiedCIILSupplyChainTradeDelivery / BilledQuantity

Il s’agit d’une information numérique, qui comme toutes les données chiffrées non monétaires, inclut une variable unitCode afin de préciser en quelle unité est exprimée cette quantité, en utilisant la liste UN/CEFACT Recommandation 20 version 09B. C’est cette unité qui fait référence pour le prix unitaire fixé par la balise ChargeAmount décrite ci-dessus.

5.9.4   Conditions financières

Les conditions financières sont décrites dans un bloc SpecifiedCIILSupplyChainTradeSettlement unique et obligatoire :

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / IncludedCIILSupplyChainTradeLineItem / SpecifiedCIILSupplyChainTradeSettlement

<xsd:complexType name="CIILSupplyChainTradeSettlementType">

    <xsd:sequence>

        <xsd:element name="ApplicableCITradeTax" type="CITradeTaxType_Category" minOccurs="0"/>

        <xsd:element name="SpecifiedCIILTradeSettlementMonetarySummation" type="CIILTradeSettlementMonetarySummationType"/>

    </xsd:sequence>

</xsd:complexType>

5.9.4.1 Taux de TVA

Elle contient une balise ApplicableCITradeTax, unique et optionnelle, qui précise les modalités d’application de la TVA.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / IncludedCIILSupplyChainTradeLineItem / SpecifiedCIILSupplyChainTradeSettlement / ApplicableCITradeTax

<xsd:complexType name="CITradeTaxType_Category">

    <xsd:sequence>

        <xsd:element name="TypeCode" type="TaxTypeCodeType_UNCL_5153" minOccurs="0" fixed="VAT"/>

        <xsd:element name="CategoryCode" type="CodeType_CEN_MUG1" minOccurs="0"/>

    </xsd:sequence>

</xsd:complexType>

 

La balise TypeCode unique et optionnelle, qui précise le type de taxe, est fixée par convention à la valeur "VAT" qui indique une taxe sur la valeur ajoutée (TVA).

 

La balise CategoryCode précise une catégorie de taux de TVA à sélectionner au sein des codes de catégories définis au sein de la balise

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / ApplicableCIIHSupplyChainTradeSettlement / ApplicableCITradeTax / CategoryCode

5.9.5   Montant net HT

La balise SpecifiedCIILTradeSettlementMonetarySummation, unique et obligatoire, permet de fixer le montant net hors taxe pour cette ligne.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / IncludedCIILSupplyChainTradeLineItem / SpecifiedCIILSupplyChainTradeSettlement / SpecifiedCIILTradeSettlementMonetarySummation

<xsd:complexType name="CIILTradeSettlementMonetarySummationType">

    <xsd:sequence>

        <xsd:element name="LineTotalAmount" type="AmountType"/>

    </xsd:sequence>

</xsd:complexType>

 

Cette information est spécifiée au sein de la balise LineTotalAmount (INV065), unique et obligatoire ;

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / IncludedCIILSupplyChainTradeLineItem / SpecifiedCIILSupplyChainTradeSettlement / SpecifiedCIILTradeSettlementMonetarySummation / LineTotalAmount

Il n’est pas possible actuellement de décrire de façon très précise la façon dont est calculé le reste à charge en fonction des cinq règles de calcul qu’on peut rencontrer sur le terrain et qui sont détaillées ci-dessous :

 

Chaque cas est basé sur une quantité de 17,99 éléments au prix unitaire brut de 20,33 €

 

A la charge du bénéficiaire

0,13 % du prix unitaire

2,64 € par unité

100 € forfaitaire

Régle

Arrondi final

TG = TF + TB

Intermédiaire

TG = TF + TB

TG =

TF + TB

TF = TG - TB

 

Prix net unitaire financeur

17,6871

17,69

17,69

17,69

20,33

Prix net unitaire bénéficiaire

2,6429

2,64

2,64

2,64

20,33

Total (TG)

365,74

365,73

365,73

365,74

365,74

Total financeur (TF)

318,19

318,24

318,24

318,25

265,74

Total bénéficiaire (TB)

47,55

47,49

47,49

47,49

100

 

Les deux cas basés sur un reste à charge du bénéficiaire en pourcent, ne diffèrent que par la règle d’arrondi, avec dans le premier cas un prix unitaire net à quatre décimales et, dans le second, à deux décimales. Le total financeur reste l’arrondi de ce prix unitaire multiplié par la quantité.

Les deux cas qui traitent d’un reste à charge monétaire unitaire diffèrent par la façon dont est calculé le total financeur. Dans le premier cas, c’est simplement l’arrondi du prix unitaire net par la quantité. Dans le second cas, on calcule le prix total (prix unitaire brut multiplié par la quantité) puis le prix dû par le patient (remise unitaire multipliée par la quantité) puis, par soustraction de l’un par l’autre, on en déduit la somme restant due.

Le dernier cas est basé sur un montant dû forfaitaire et n’appelle pas de commentaire – hormis le fait qu’il n’est pas possible de le détailler avec la balise AppliedCITradeAllowanceCharge qui ne permet que de préciser une remise unitaire.

5.9.6   Description de la prestation

La description du service facturé est effectuée dans un bloc unique et obligatoire :

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / IncludedCIILSupplyChainTradeLineItem / SpecifiedCITradeProduct

<xsd:complexType name="CITradeProductType">

    <xsd:sequence>

        <xsd:element name="ID" type="IDQualifiedType"/>

        <xsd:element name="Name" type="TextType"/>

    </xsd:sequence>

</xsd:complexType>

 

Ce bloc contient deux informations, l’identifiant du service et son libellé ; ces deux informations sont uniques et obligatoires.

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / IncludedCIILSupplyChainTradeLineItem / SpecifiedCITradeProduct / ID

CrossIndustryInvoice / CIIHSupplyChainTradeTransaction / IncludedCIILSupplyChainTradeLineItem / SpecifiedCITradeProduct / Name

L’ID est, comme toujours, du type schemeID (identifiant) et schemeAgencyName (libellé) ; le Name est un libellé en texte libre.

6                      Dictionnaire des termes utilisés

6.1                    APA

L’allocation personnalisée d'autonomie (APA) est une mesure sociale en faveur des personnes âgées et dépendantes (GIR 1 à 4).

 

Référence : https://www.service-public.fr/particuliers/vosdroits/F10009

6.2                    GIR

Les groupes iso-ressources (GIR) permettent de classer les personnes en six différents stades de perte d'autonomie. Le classement dans un GIR s'effectue en fonction des données recueillies par une équipe médico-sociale à l'aide de la grille Aggir (Autonomie gérontologie-groupe iso-ressources) qui permet de pondérer différentes variables (par exemple : la cohérence, l'orientation, la toilette, la communication).

 

Code

Définition

1

Personne confinée au lit ou au fauteuil ou dont les fonctions intellectuelles sont gravement altérées. La présence constante d'intervenants est indispensable.

2

Personne confinée au lit ou au fauteuil et dont les fonctions intellectuelles ne sont pas totalement altérées ; une prise en charge est nécessaire pour la plupart des activités de la vie courante.
Personne dont les fonctions mentales sont altérées, mais qui peuvent se déplacer ; certains gestes, tels que l'habillage, la toilette, ne peuvent être accomplis en raison de la déficience mentale.

3

Personne qui a conservé partiellement ses capacités motrices, mais a besoin d'être assistée pour se nourrir, se coucher, se laver, aller aux toilettes.

4

Personne qui a besoin d'aide pour se lever, se coucher, mais peut se déplacer seule à l'intérieur du logement ; une assistance est parfois nécessaire pour la toilette et l'habillage.
Personne qui n'a pas de problème de transfert ou de déplacement, mais qui doit être assistée pour les activités corporelles ainsi que pour les repas.

5

Personne relativement autonome dans ses activités : elle se déplace seule, mais a besoin d'aides ponctuelles pour la toilette, la préparation des repas, l'entretien du logement.

6

Personne autonome dans tous les actes de la vie courante

 

Référence : http://www.cnsa.fr/documentation/guide_aggir_2008.pdf

6.3                    ISO 3166

ISO 3166 est la norme internationale des codes des noms de pays et de leurs subdivisions. Elle a pour but de définir des codes internationalement reconnus de lettres et/ou de chiffres qui peuvent être utilisés pour désigner des pays et leurs subdivisions.

 

Les codes de pays peuvent être représentés par un code à deux lettres (alpha-2) recommandé pour l'usage général, un code à trois lettres (alpha-3) associé plus étroitement au nom de pays, et un code à trois chiffres (numeric-3), utile lorsque les codes doivent être compris dans des pays n'utilisant pas l'alphabet latin.

Esppadom utilise les codes à deux lettres alpha-2 ; le code pour la France est FR ; la liste ci-dessous contient les codes les plus utiles en métropole et dans les DOM-TOM.

 

Code

Définition

FR

France

GF

Guyane française

GP

Guadeloupe

MQ

Martinique

PF

Polynésie française

PM

Saint-Pierre et Miquelon

RE

La Réunion

TF

Territoires australs d’outre-mer

YT

Mayotte

 

Référence : http://www.iso.org/iso/fr/home/standards/country_codes.htm

Liste des codes alpha-2 : https://www.iso.org/obp/ui/fr/#search

6.4                    ISO 4217

ISO 4217 est la norme internationale des codes pour la représentation des monnaies.

Le code pour l’Euro est EUR.

6.5                    PCH

La prestation de compensation du handicap (PCH) est une aide personnalisée permettant la prise en charge de dépenses liées au handicap (aide humaine, matérielle, animalière...). Il est possible de bénéficier de la PCH à domicile ou en établissement.

 

Référence : https://www.service-public.fr/particuliers/vosdroits/N14201

6.6                    SIRET

Le numéro SIRET est un identifiant d'établissement.


Cet identifiant numérique de 14 chiffres est articulé en deux parties : la première est le numéro SIREN de l'unité légale à laquelle appartient l'unité SIRET ; la seconde, habituellement appelée NIC (Numéro Interne de Classement), se compose d'un numéro d'ordre à quatre chiffres attribué à l'établissement et d'un chiffre de contrôle, qui permet de vérifier la validité de l'ensemble du numéro SIRET.

 

Source : INSEE http://www.insee.fr/fr/methodes/default.asp?page=definitions/numero-siret.htm

 

7                      Identifiants ESPPADOM

7.1                    Liste ESPPADOM_ADDITIONAL_INFORMATION

Qualification

schemeAgencyName=‘EDESS’

schemeID=’ESPPADOM_ADDITIONNAL_INFORMATION’

Exemple ESPPADOM_Order

<Type schemeID="ESPPADOM_ADDITIONAL_INFORMATION" schemeAgencyName="EDESS">IPA</Type>

Définition

Détermine un type d’information optionnelle.

Table des valeurs

Code

Libellé

IPA

Identifiant de « dossier papier »

DDC

Date de décès du bénéficiaire

NNA

Nom de naissance

7.2                    Liste ESPPADOM_CADRE

Qualification

schemeAgencyName=‘EDESS’

schemeID=’ESPPADOM_CADRE’

Exemple ESPPADOM_Order

<ram:CadreIntervention schemeID="ESPPADOM_CADRE" schemeAgencyName="EDESS">MDT</ram:CadreIntervention>

Définition

Détermine le cadre d’intervention.

Table des valeurs

Code

Libellé

MDT

Mandataire

EDI

Emploi direct

PRE

Prestataire

AID

Aidant familial

7.3                    Liste ESPPADOM_CHANGE_REASON

Qualification

schemeAgencyName=‘EDESS’

schemeID=’ESPPADOM_CHANGE_REASON’

Exemple ESPPADOM_Order

<ReasonForChange schemeID="ESPPADOM_CHANGE_REASON" schemeAgencyName="EDESS">HOP</ReasonForChange>

Définition

Détermine le motif d’une modification appliquée à une prestation.

Table des valeurs

Code

Libellé

HOP

Hospitalisation

DCD

Décès

CDS

Changement de domicile de secours

7.4                    Liste ESPPADOM_CHANGE_TYPE

Qualification

schemeAgencyName=‘EDESS’

schemeID=’ESPPADOM_CHANGE_TYPE’

Exemple ESPPADOM_Order

<ChangeType schemeID="ESPPADOM_CHANGE_TYPE" schemeAgencyName="EDESS">HOL</ChangeType>

Définition

Détermine le type de modification appliqué à une prestation.

Table des valeurs

Code

Libellé

HOL

Suspension

STP

Arrêt

SUP

Suppression

7.5                    Liste ESPPADOM_CIVILITY

Qualification

schemeAgencyName=‘EDESS’

schemeID=’ESPPADOM_CIVILITY’

Exemple ESPPADOM_Order

<Civility schemeID="ESPPADOM_CIVILITY" schemeAgencyName="EDESS">MME</Civility>

Définition

Détermine la civilité.

Table des valeurs

Code

Libellé

MME

Madame

MSR

Monsieur

7.6                    Liste ESPPADOM_CONTACT_BENEFICIAIRE

Qualification

schemeAgencyName=‘EDESS’

schemeID=’ESPPADOM_CONTACT_BENEFICIAIRE’

Exemple ESPPADOM_Order

<TypeCode schemeID="ESPPADOM_CONTACT_BENEFICIAIRE" schemeAgencyName="EDESS">DPA</TypeCode>

Définition

Détermine le type de contact pour le bénéficiaire.

Table des valeurs

Code

Libellé

DPA

Proche aidant

DSC

Domicile de secours

LCU

Curateur

LTU

Tuteur

PSA

Professionnel de santé

INT

Autre intervenant

7.7                    Liste ESPPADOM_CONTACT_DONNEUR_ORDRE

Qualification

schemeAgencyName=‘EDESS’

schemeID=’ESPPADOM_CONTACT_DONNEUR_ORDRE’

Exemple ESPPADOM_Order

<TypeCode schemeID="ESPPADOM_CONTACT_DONNEUR_ORDRE" schemeAgencyName="EDESS">DPA</TypeCode>

Définition

Détermine le type de contact pour le donneur d’ordre.

Table des valeurs

Code

Libellé

INS

Agent instructeur

7.8                    Liste ESPPADOM_CONTACT_PAYEUR

Qualification

schemeAgencyName=‘EDESS’

schemeID=’ESPPADOM_CONTACT_PAYEUR’

Exemple ESPPADOM_Order

<TypeCode schemeID="ESPPADOM_CONTACT_PAYEUR" schemeAgencyName="EDESS">DPA</TypeCode>

Définition

Détermine le type de contact pour le payeur.

Table des valeurs

Code

Libellé

 

 

 

 

 

 

 

 

7.9                    Liste ESPPADOM_CONTACT_PRESTATAIRE

Qualification

schemeAgencyName=‘EDESS’

schemeID=’ESPPADOM_CONTACT_PRESTATAIRE’

Exemple ESPPADOM_Order

<TypeCode schemeID="ESPPADOM_CONTACT_PRESTATAIRE" schemeAgencyName="EDESS">DPA</TypeCode>

Définition

Détermine le type de contact pour le prestataire.

Table des valeurs

Code

Libellé

INT

Intervenant à domicile (la personne qui est effectivement intervenue)

RSE

Responsable de secteur

CSE

Coordinateur de secteur

GES

Gestionnaire de dossier

7.10                 Liste ESPPADOM_EFFECTIVITY_AJUST

Qualification

listAgencyName=‘EDESS’

listID=’ESPPADOM_EFFECTIVITY_AJUST’

Exemple ESPPADOM_Delivery

<ram:PurposeCode listID="ESPADDOM_EFFECTIVITY_AJUST" listAgencyName="EDESS">1</ram:PurposeCode >

Définition

Motifs d’adaptation de la période d’effectivité par rapport aux données d’horodatage.

Table des valeurs

Code

Libellé

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.

7.11                 Liste ESPPADOM_GIR

Qualification

listAgencyName=‘EDESS’

listID=’ESPPADOM_GIR’

Exemple ESPPADOM_Order

<ram:PurposeCode listID="ESPADDOM_GIR" listAgencyName="EDESS">1</ram:PurposeCode >

Définition

Valeurs de 1 à 6 en fonction du score GIR (voir détails dans le dictionnaire des termes utilisés)

Table des valeurs

Code

Libellé

1

GIR 1

2

GIR 2

3

GIR 3

4

GIR 4

5

GIR 5

6

GIR 6

7.12                 Liste ESPPADOM_INVOICE_LINE_TYPE

Qualification

listAgencyName=‘EDESS’

listID=’ESPPADOM_INVOICE_LINE_TYPE’

Exemple ESPPADOM_Order

<LineType listID="ESPADDOM_INVOICE_LINE_TYPE" listAgencyName="EDESS">1</LineType>

Définition

Précise si une ligne de facturation « spéciale » est une ligne de régularisation ou de complément

Table des valeurs

Code

Libellé

REG

Régularisation (régularise une ligne déjà émise)

CPL

Complément (complète une facture déjà émise)

7.13                 Liste ESPPADOM_PROFIL

Qualification

listAgencyName =‘EDESS’

listID=’ESPPADOM_PROFIL’

Exemple ESPPADOM_Order

<ram:HandlingCode listID="ESPPADOM_PROFIL" listAgencyName="EDESS">ZZZ</ram:HandlingCode>

Définition

Décrit le profil d’un intervenant, comme par exemple par une qualification professionnelle particulière.

Table des valeurs

Code

Name

 

 

 

La nomenclature des qualifications professionnelles pose le même type de difficulté d’élaboration que celle des prestations, détaillée ci-dessous. Avec le même intérêt à l’uniformiser puisqu’il semble difficile que chaque donneur d’ordre l’impose à des prestataires qui exercent parfois sur tout le territoire, et qu’il serait anormal qu’un prestataire l’impose au donneur d’ordre, créant ainsi le type même de verrouillage sur une solution que les messages Esppadom visent à réduire.

 

La première piste envisagée est de sélectionner un sous-ensemble des listes fournies par l’INSEE, par exemple :

 

Professions les plus typiques

Professions assimilées

Aide ménagère
Aide à domicile
Travailleuse familiale, technicien de l'intervention sociale et familiale

Agent social <s.a.i.>
Aide (à domicile) de personnes âgées <SALARIE>
Aide familial <travail social> <services domestiques> <SALARIE>
Aide familiale rurale
Animateur d'un service de travailleuses familiales
Assistante de vie
Assistante familiale
Auxiliaire de vie
Auxiliaire en gérontologie
Auxiliaire familiale
Auxiliaire sociale
Dame de compagnie
Employé garde malade
Femme de ménage <soins à domicile>
Garde malade <services domestiques>
Garde malade de jour/de nuit <au domicile>
Garde à domicile
Monitrice familiale
Tierce personne

 

L’autre approche serait de reprendre l’arborescence des services, en sous entendant « personne qualifiée pour le service », qui serait étendue (spécifiée) par des qualifications précises à l’image de la liste ci-dessus.

 

Pour reprendre, de façon étendue, la branche donnée en exemple pour les services, on pourrait imaginer une construction du type :

 

2 Qualifié en matière d’autonomie

2.2  Besoins directs

2.2.1 Qualifié pour assister aux actes essentiels (y compris les déplacements)

2.2.1.1 Qualifié en matière d’hygiène des personnes

2.2.1.1.1 Qualifié en matière d’aide à la toilette

2.2.1.1.1.2 Qualifié en matière d’aide à la toilette au lit

2.2.1.1.1.2.1 Auxiliaire de vie

2.2.1.1.1.2.2 Auxiliaire en gérontologie

 

Au sein d’un plan d’aide, le profil est toujours complémentaire d’une prestation. Ne pas spécifier de profil, c’est donc implicitement demander une personne qualifiée pour la prestation, ce qui rend inutile toute la partie qui « recopie » les services. Cette construction n’aurait donc d’intérêt que si on souhaitait préciser, comme dans l’exemple ci-dessus, qu’on exige un « Auxiliaire de vie qualifié en matière d’aide à la toilette au lit ».

7.14                 Liste ESPPADOM_SERVICE

Qualification

listAgencyName =‘CNSA’

listID=’ESPPADOM_SERVICE’

Exemple ESPPADOM_Order

<ID listID="ESPPADOM_SERVICE" listAgencyName="EDESS">ZZZ</ram:HandlingCode>

Définition

Décrit un type de prestation.

 

La liste actuellement proposée est un sous-ensemble, qui regroupe les prestations les plus fréquentes, d’une classification arborescente de plus grande envergure. Elle sera complétée au cours du temps en fonction des besoins exprimés sur le terrain.

 

Un document complémentaire détaille la logique d’élaboration de la nomenclature et attribue une définition précise à chaque élément.

 

La classification arborescente est construite pour induire une « sémantique de position », en ce sens qu’il est toujours légitime d’affirmer qu’un service de code X.Y (ou X et Y sont deux séquences quelconques) « est un » X (par exemple, dans la liste ci-dessous, 2.2.1.1.1.1 (Aide à la toilette partielle) est un 2.2.1.1.1 (Aide à la toilette)).

 

Ce mécanisme permet donc d’être « aussi précis que nécessaire » et, par exemple, de valider une consigne de code X par une prestation effective de code X.Y.

 

On peut rappeler que cette liste de prestations a deux usages fort distincts :

·         Dans le message Order, elle permet au donneur d’ordre de signaler au prestataire des « points d’attention » qui induisent des consignes personnalisées. Il s’agit bien d’exprimer que le temps imparti doit inclure certaines prestations mais en aucun cas qu’il se décompose en ces prestations.

·         Au sein du message Delivery, qui rend compte du travail du prestataire, on peut imaginer plusieurs usages, en fonction du type de retour attendu par le donneur d’ordre : un simple rappel des consignes effectivement prises en charge (niveau de détail identique à celui qui a été transmis par Order), une validation détaillée des consignes prises en charges (une consigne X est éventuellement validée par une prestation plus précise de type X.Y) ou, enfin, un rapport détaillé des prestations effectuées (qu’elles valident des consignes ou non).

Table des valeurs

Code

Libellé

2.1.1.10.1.3.1

Aide à la prise de médicament

2.2.1.1.1

Aide à la toilette

2.2.1.1.1.1

Aide à la toilette partielle

2.2.1.1.3.3

Assistance à la protection hygiénique

2.2.1.1.4.1

Aide à l’habillage au lever

2.2.1.1.4.2

Aide au déshabillage pour le coucher

2.2.1.1.5.1

Aide à la prise de repas

2.2.1.1.6

Aide au transfert

2.2.1.1.6.1

Aide au lever

2.2.1.1.6.2

Aide au coucher

2.2.1.1.6.3

Aide à la mobilité intérieure

2.3.2.2.2

Accompagnement aux tâches ménagères

2.3.2.2.2.1

Aide à la préparation de repas

2.3.4.2.1

Accompagnement pour les déplacements à l’extérieur 

2.3.4.2.1.1

Accompagnement aux courses

7.15                 Liste ESPPADOM_TIMESTAMP_METHOD

Qualification

listAgencyName =‘EDESS’

listID=’ESPPADOM_TIMESTAMP_METHOD’

Exemple ESPPADOM_Delivery

<SupplierIdentificationMethod listID="ESPPADOM_TIMESTAMP_METHOD" listAgencyName="EDESS">MOB</SupplierIdentificationMethod>

Définition

Précise la méthode d’horodatage utilisée.

Table des valeurs

Code

Name

BDG

Badge

BIO

Biométrie

MOB

Identifiant mobile

RNG

Audioring

SVI

Code sur SVI

7.16                 Liste ESPPADOM_TYPE_AIDE

Qualification

listAgencyName=‘EDESS’

listID=’ESPPADOM_TYPE_AIDE’

Exemple ESPPADOM_Order

<TypeAide listID="ESPADDOM_TYPE_AIDE" listAgencyName="EDESS">APA</TypeAide>

Définition

Nature des prestations

Table des valeurs

Code

Libellé

Définition

APA

APA

Allocation personnalisée d'autonomie

PCH

PCH

Prestation de compensation du handicap

AM

AM

Aide ménagère

ASE

ASE

Aide sociale à l’enfance

FAJ

FAJ

Fond d’aide aux jeunes

7.17                 Liste ESPPADOM_TYPE_BENEFICIAIRE

Qualification

listAgencyName =‘EDESS’

listID=’ESPPADOM_TYPE_BENEFICIAIRE’

Exemple ESPPADOM_Order

<TypeBeneficiaire listID="ESPPADOM_TYPE_BENEFICIAIRE" listAgencyName="EDESS">HAN</TypeBeneficiaire>

Définition

Décrit la catégorie du bénéficiaire qui justifie la prise en charge.

Table des valeurs

Code

Name

HAA

Adulte en situation de handicap

HAE

Enfant en situation de handicap

ENF

Enfant

 

8                      Identifiants EXTERNES

8.1                    Code MUG-1 (Core Invoice VAT Category Code)

Définition

Cette table recense les identifiants de catégories de TVA. Elle reprend en partie la table UN/EDIFACT 5305 B (http://www.unece.org/trade/untdid/d07b/tred/tred5305.htm) à laquelle elle ajoute les codes T01 à T09 pour indexer les taux de TVA référencés au sein d’une instance donnée de facture.

Table des valeurs

T01

Taxé au niveau de taxe 1

Code spécifiant que le taux de TVA est au 1er niveau défini au sein de la facture.

T02

Taxé au niveau de taxe 2

Code spécifiant que le taux de TVA est au 2ième niveau défini au sein de la facture.

T03

Taxé au niveau de taxe 3

Code spécifiant que le taux de TVA est au 3ième niveau défini au sein de la facture.

T04

Taxé au niveau de taxe 4

Code spécifiant que le taux de TVA est au 4ième niveau défini au sein de la facture.

T05

Taxé au niveau de taxe 5

Code spécifiant que le taux de TVA est au 5ième niveau défini au sein de la facture.

T06

Taxé au niveau de taxe 6

Code spécifiant que le taux de TVA est au 6ième niveau défini au sein de la facture.

T07

Taxé au niveau de taxe 7

Code spécifiant que le taux de TVA est au 7ième niveau défini au sein de la facture.

T08

Taxé au niveau de taxe 8

Code spécifiant que le taux de TVA est au 8ième niveau défini au sein de la facture.

T09

Taxé au niveau de taxe 9

Code spécifiant que le taux de TVA est au 9ième niveau défini au sein de la facture.

AE

VAT Reverse Charge

Code specifying that the VAT rate is levied from the invoicee.

E

Exempté de taxe

Code spécifiant que la TVA n’est pas applicable.

Z

Services à taxe nulle

Code spécifiant que les services sont exempts de TVA.

O

Hors du champ de la TVA

Code spécifiant que la TVA n’est pas applicable.

IC

Opération intra-communautaire

Code specifying that the VAT rate is levied from the invoicee for Intra-Community supplies.

 

Note : Les codes T01 à T09 sont utilisés comme index d’un taux de TVA défini au sein même de la facture et n’ont pas de signification en dehors de cette facture.

8.2                    Code MUG-2 (Core Invoice Units of Measure)

Définition

Cette table correspond aux codes recommandés dans la facture européenne. C’est un sous-ensemble de la liste de codes définie par UN/CEFACT Recommandation 20 version 09B.

Table des valeurs

Code

Définition internationale

Traduction

C62

One

Unité

DAY

day

Jour

HUR

Hour

Heure

MIN

Minute

Minute

 

Pour la liste exhaustive des codes définis par UN/CEFACT Recommandation 20 version 09B : voir

http://www.unece.org/tradewelcome/un-centre-for-trade-facilitation-and-e-business-uncefact/outputs/cefactrecommendationsrec-index/list-of-trade-facilitation-recommendations-n-16-to-20.html

8.3                    Code MUG-4 (Payment means code)

Définition

Cette table référence les moyens de paiement. C’est un sous-ensemble de la liste de codes UN/EDIFACT 4461

Table des valeurs

Code

Définition internationale

Traduction

31

Debit transfer

Payment by debit movement of funds from one account to another.

 

Pour la liste exhaustive des codes, voir http://www.unece.org/trade/untdid/d03b/tred/tred4461.htm

8.4                    Code UN/EDIFACT 4465 (Adjustment reason description code)

Définition

Cette table référence les motifs de remise ou d’application de frais

Table des valeurs

Code

Définition internationale

Traduction

1

Agreed settlement

An adjustment made based on an agreement between partners.

4

Short delivery

An adjustment made because the delivered quantity was less than expected.

5

Price query

An adjustment due to a price query.

6

Proof of delivery required

The buyer requires that proof of delivery be made before payment.

7

Payment on account

Buyer is to make payment later.

9

Invoice error

Invoice not in accordance with the order.

11

Bank charges

Bank charges have been deducted from payment.

12

Agent commission

Agent commission has been deducted from payment.

13

Counter claim

Buyer claims an existing (financial) obligation from seller which (partly) offsets the outstanding invoice(s).

14

Wrong delivery

Delivery not according to specifications.

19

Trade discount

Trade discount deducted from payment.

77

Pricing discount

An adjustment has been made due to the application of a pricing discount.

 

Pour la liste exhaustive des codes, voir https://www.unece.org/fileadmin/DAM/trade/untdid/d12b/tred/tred4465.htm

Types xsd de base

8.5                    Types xsd de référence

Les types xsd de référence utilisés au sein du message Order sont de trois types :

 

§  Chaine de caractères : xsd:string et xsd:token

§  Numérique : xsd:decimal

§  Date : xsd:date et xsd:dateTime

8.5.1   xsd:string

Le type xsd:string représente tout type de séquences de caractères au format Unicode.

8.5.2   xsd:token

Le type xsd:token est dérivé du type xsd:normalizedString, lui-même dérivé de xsd:string.

Un xsd:normalizedString représente une chaîne de caractères normalisée, c'est-à-dire ne contenant pas de tabulation (U+09), de saut de ligne (U+0A) ou de retour chariot (U+0D).

Un xsd:token décrit une chaîne normalisée qui ne contient pas, en outre, d’espace en début ou en fin ni d’espaces consécutifs.

8.5.3   xsd:decimal

Le type xsd:decimal décrit un nombre décimal sans limite de précision. Il s’agit d’une séquence finie de chiffres (#x30-#x39), incluant éventuellement un point comme séparateur décimal et un commençant éventuellement par un indicateur de signe (+ étant supposé en absence de précision).

 

La représentation canonique du type xsd:decimal restreint cette description avec les règles suivantes :

§  L’indicateur de signe + est prohibé.

§  Le séparateur décimal est obligatoire.

§  Les zéros de début et de fin doivent être supprimés, hormis s’ils sont uniques d’un côté ou de l’autre du séparateur décimal.

8.5.4   xsd:date

Le type xsd:date représente une date au format YYYY-MM-DD, par exemple 2008-01-16. Tous les champs sont obligatoires.

8.5.5   xsd:dateTime

Le type xsd:dateTime représente un couple date et heure au format YYYY-MM-DDThh:mm:ss comme 2008-01-16T14:07:23. Tous les champs sont obligatoires.

8.6                    Types Unece / Esppadom

8.6.1   AmountType

Le type AmountType décrit un montant financier. C’est un type complexe qui contient la somme, sous forme d’un xsd:decimal, et la monnaie sous forme d’un attribut nommé currencyID au format ISO3AlphaCurrencyCode.

 

<xsd:complexType name="AmountType">

    <xsd:simpleContent>

        <xsd:extension base="xsd:decimal">

           <xsd:attribute name="currencyID" type="ISO_ISO3AlphaCurrencyCode_20100407:ISO3AlphaCurrencyCodeContentType"/>

        </xsd:extension>

    </xsd:simpleContent>

</xsd:complexType>

 

Exemple :

<TotalAmount currencyID="EUR">150.0</TotalAmount>

8.6.2   CodeQualifiedType

Le type CodeQualifiedType est un type complexe qui permet de préciser un code issu d’une liste prédéfinie ou d’une classification.

 

Ce type contient un code sous la forme d’un xsd:token et trois attributs, listID et listAgencyName, qui sont obligatoires et permettent d’identifier la liste et name, optionnel, qui peut contenir le libellé correspondant au code :

 

<xsd:complexType name="CodeQualifiedType">

    <xsd:simpleContent>

        <xsd:extension base="xsd:token">

           <xsd:attribute name="listID" type="xsd:token" use="required"/>

           <xsd:attribute name="listAgencyName" type="xsd:string" use="required"/>

           <xsd:attribute name="name" type="xsd:string"/>

        </xsd:extension>

    </xsd:simpleContent>

</xsd:complexType>

 

listID

Identifiant de la liste utilisée

xsd:token

listAgencyName

Nom de l’organisme qui maintient cette liste

xsd:string

name

Libellé correspondant au code

xsd:string

 

Exemple :

 

<ram:HandlingCode listID=" ESPADDOM _PROFIL" listAgencyName="EDESS" name=”Auxiliaire de vie”>1.3.4</ram: HandlingCode >

8.6.3   DateMandatoryDateTimeType

Ce type est défini dans AUX_UNECE_QDT_8p0_ESPPADOM_Order_V00_02.xsd :

 

<xsd:simpleType name="DateMandatoryDateTimeType">

    <xsd:union memberTypes="UNECE_UDT_9p0:DateTimeType UNECE_UDT_9p0:DateType"/>

</xsd:simpleType>

 

Il représente donc soit un DateTimeType, soit un DateType

8.6.4   DateTimeType

Le type DateTimeType est simplement un xsd:dateTime

8.6.5   DateType

Le type DateType est simplement un xsd:date

8.6.6   IDUnqualifiedType

Le type IDUnqualifiedType est simplement un xsd:token

8.6.7   IDISO3166Type

Le type IDISO3166Type est simplement un xsd:token

8.6.8   PercentType

Le type PercentType est simplement un xsd:decimal

8.6.9   TextType

Le type TextType est simplement un xsd:string

8.6.10                QuantityType

Le type QuantityType décrit une donnée quelconque. C’est un type complexe qui contient la somme, sous forme d’un xsd:decimal, et une unité sous forme d’un attribut obligatoire nommé unitCode, à prendre dans la liste des codes MUG-2 (voir le chapitre « identifiants externes »).

 

<xsd:complexType name="QuantityType">

    <xsd:simpleContent>

        <xsd:extension base="xsd:decimal">

           <xsd:attribute name="unitCode" type="MeasurementUnitCommonCodeContentType" use="required"/>

        </xsd:extension>

    </xsd:simpleContent>

</xsd:complexType>

 

<xsd:simpleType name="MeasurementUnitCommonCodeContentType">

    <xsd:restriction base="xsd:token"/>

</xsd:simpleType>

 

Exemple :

<RequestedQuantity unitCode="HUR">50.0</RequestedQuantity>

9                      Schémas XML

9.1                    Emplacement

 

9.2                    Conventions

9.2.1   Règles de nommage des fichiers

Le document « UN/CEFACT XML Naming and Design Rules Technical Specification » précise que les fichiers de schéma XML doivent avoir un nom du type <Schema Module Name>_<Version Identifier>.xsd, où l’identifiant de version est représenté sous forme version majeure, version mineure, séparées par la lettre ‘p’ en remplacement de l’usuel point. Par exemple AUX_UNECE_RAM_8p0.xsd.

 

Par ailleurs, les noms de modules UN/CEFACT incluent les qualitatifs RAM, UDT et QDT pour distinguer les types d’objets décrits :

 

UN/CEFACT Reusable Aggregate Business Information Entity

RAM

UN/CEFACT Unqualified Data Type

UDT

UN/CEFACT Qualified Data Type

QDT

 

Pour rester en harmonie avec cette règle de nommage, les fichiers de schéma XML d’Esppadom prolongent le nom de fichier UN/CFACT dont ils sont issus par le nom du module Esppadom et son identifiant de version s’il existe, ou par le simple qualificatif « ESPPADOM » suivi d’un numéro de version si le schéma n’est pas spécifique d’un message donné.

 

Par exemple :

 

AUX_UNECE_RAM_8p0_ESPPADOM_ORDER_1p0.xsd est le nom de fichier de la version 1.0 du schéma principal du message Order

 

AUX_UNECE_QDT_8p0_ESPPADOM_1p0.xsd désigne le fichier qui contient les types de données qualifiées utilisés dans tous les schémas Esppadom.


[1]           Voir CEN Workshop on 'e-business Board for European Standardization' (WS/eBES) https://www.cen.eu/work/areas/ict/ebusiness/pages/ws-ebes.aspx

[2]           Règles de facturation de la TVA : http://ec.europa.eu/taxation_customs/taxation/vat/topics/invoicing_fr.htm

[3]           Voir liste complète à l’adresse : http://www.unece.org/trade/untdid/d00a/tred/tred1001.htm