Protocole d'echanges standard

1.Objet

• 
  Transport des descriptions des pièces justificatives dématérialisées associées aux objets comptables (domaines Dépense, Recette et Marché) et le cas échéant des pièces justificatives elles-mêmes.
  
• 
  Référence aux pièces justificatives dans chaque objet comptable
  
• 
  Possibilités de signature électronique :
  

• 
  Des bordereaux de dépense et de recette
  
• 
  Des pièces justificatives (externe)
  
• 
  De l’enveloppe de transport.
  

Sur ce dernier cas, en l'absence d'enveloppe de transport normalisée, une signature ‘technique’ du flux PES_Aller a été définie afin de garantir l'intégrité du flux. Cette signature aura vocation à disparaître dès que l'enveloppe de transport sera normalisée et intégrée par Helios.

• 
  Les données du PES V2 sous forme de syntaxes XML, selon la notation XML Schema. Les syntaxes XML utilisées sont :
  

• 
  Spécifiques au PES et font l’objet d’une description dans le document et regroupées dans l’annexe [R2].
  
• 
  Normalisées par les recommandations W3C : XML Signature [R4] et XADES [R5]
  

• 
  Signatures électronique : XML Signature [R4] et XADES [R5].
  
• 
  Chiffrement : syntaxes de chiffrements XML (cas des pièces justificatives véhiculées par les flux).
  

• 
  Le regroupement des données du PES V2 sous forme de messages et les règles d’échanges associées.
  

• 
  Le chapitre 2 présente les principes généraux gouvernant les échanges entre ordonnateurs et HELIOS.
  
• 
  Le chapitre 3 précise l’organisation générale des schémas XML constitutifs du PES V2.
  
• 
  Le chapitre 4 présente de façon progressive, par domaine, la modélisation XML des blocs de données utilisés dans le cadre du PES.
  
• 
  Le chapitre 5 présente le regroupement de données sous forme de messages XML. 
  

2.Principes généraux des échanges

2.1Canaux de communication Ordonnateur / HELIOS

Un ordonnateur a le choix, pour effectuer la transmission et la réception de données et de documents électroniques, de recourir soit à un dispositif de transmission mis en oeuvre par un opérateur «  tiers de transmission », soit à la passerelle de transmission sécurisée d'Hélios. L’ordonnateur peut assumer directement la fonction de tiers de transmission en mettant en oeuvre un dispositif de transmission. Le recours à un dispositif de transmission mis en oeuvre par un tiers de transmission est recommandé dans la logique d'interopérabilité des échanges entre administrations.

La description de l’infrastructure de transfert ainsi que la définition des canaux sont en dehors du cadre de ce document.

Les fichiers échangés entre l’ordonnateur et HELIOS sont construits selon la syntaxe XML, selon des dispositions décrites dans ce document.

2.2Flux de communication

Nous décrivons ci-dessous les flux d’échanges associés à la transmission en mode fil (synchrone ou asynchrone).

2.2.1Flux Aller

2.2.1.1Principes de base

F
igure 1

• 
  Le message PES Aller est transmis par l’ordonnateur à HELIOS selon la règle d’acheminement sélectionnée entre l’ordonnateur et le comptable. Le fichier correspondant peut regrouper des objets comptables de domaines fonctionnels distincts pour une collectivité budget donnée.
  
• 
  La zone d’échange HELIOS exerce un contrôle d’acceptabilité sur le fichier reçu. Ce contrôle porte sur les éléments suivants :
  

• 
  Conformité du message reçu à la syntaxe du PES (validation du schéma XML correspondant à la version référencée).
  
• 
  Validation des éléments d’en-tête (codique du poste, code collectivité & code budget, ainsi que identifiant collectivité le cas échéant).
  
• 
  Contrôle des éléments de signature du flux, quand ces derniers sont présents. Dans le cadre de cette version, ces contrôles sont limités à une vérification d’empreinte sur l'objet PES_Aller.
  

• 
  Lorsque le contrôle d’acceptabilité précédent est réussi, HELIOS délivre vers l’émetteur du fichier un message d’acquittement de prise des données ordonnateurs dans la zone de gestion HELIOS se traduit par la délivrance d’un acquit de prise en compte. Le mode de délivrance de l’acquit est fonction du type de canal d’acheminement. Il garantit à l’ordonnateur que les données véhiculées par le flux seront en visibilité du comptable.
  
• 
  Lorsque le contrôle d’acceptabilité précédent est en échec, HELIOS délivre vers l’émetteur du fichier un message de non acquittement de prise en compte des données ordonnateurs, contenant la cause du rejet.
  

2.2.1.2Mode de délivrance des messages d’acquit et de non acquit

Dans le cas d’une transmission synchrone (formulaire HTML), l’acquit de prise en compte ou le non acquit figure dans le statut de retour de la requête HTML. Il ne nécessite donc pas un message séparé.

2.2.2Flux retour