EDESS. 1 Démarche générale principes 2

Transcription

1 EDESS 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 V 1.0 décembre 2014 Le présent document accompagne les livrables d'esppadom. Il est avant tout le fruit du travail dans les départements pilotes et résulte des questions posées par les utilisateurs et développeurs au cours des travaux. Il sera amené à se développer et à évoluer au fur et à mesure des déploiements et de la généralisation du standard. Ce sera un des outils importants de la communauté en création. La version 1.0 en est la première instance. Le document s'organise en deux parties. La première fournit des informations communes aux troix flux Plan d'aide, Facture, Télégestion. Ils traitent en effet principalement des mêmes données. La deuxième partie représente des réponses à des questions pratiques sur les flux et leur "mapping" avec les normes UN CEFACT qui les structurent. Les mappings précisent quelle donnée (qui plus est en français) occupe telle place dans le message. Ces mappings sont nécessaires pour chaque secteur et chaque langage, chaque donnée se rattachant à un concept général, comme par exemple un rôle (client, destinataire, adresse de livraison etc.). 1 Démarche générale principes Origine des choix techniques d ESPPADOM Accès à l information Listes de codes Nomenclature des prestations 3 2 Règles d'ensemble pour le standard et les trois flux Caractères XML Contraintes (0,1) Comment savoir si on est sur une création, modification Taille des champs (par ex. pour un identifiant) Commande et lots de commandes Commande et transaction Quelle différence à faire entre le numéro de transaction et le numéro de commande? 2.7 Tarifs, référence externe Bloc instruction de livraison Instructions optionnelles pour l exécution des services : Recurrence Rule Quelle différence à faire entre le plan d aide et la prise en charge Dates Gestion des factures Gestion des décimales Changement de prise en charge 7 3 Notes particulières pour les développeurs sur les mappings Order et Delivery Mapping Order Delivery 9 4

2 1 Démarche générale principes 1.1 Origine des choix techniques d ESPPADOM ESPPADOM s appuie sur des standards internationaux. Trois flux ont été identifiés (plan d aide, facture et télégestion), en commençant en particulier par la facture, sur un modèle international et européen, conforme aux recommandations du ministère des Finances : INVOICE. Puis ce sont ORDER et DELIVERY. Les modèles ont été écrits en UML et les messages en XML. Ils sont donc basés sur des standards présents dans tous les domaines de l industrie et des services en France et en Europe. Il s'agit de standards (cependant INVOICE est en cours de normalisation européenne). S'il y a besoin de faire évoluer Esppadom vers une norme, il faudra passer par la filière AFNOR, CEN et ISO. Esppadom ne traite ni des applicatifs internes, ni des aspects d infrastructure et de sécurité. Il considère les données échangeables, le modèle des échanges et la structure des messages. 1.2 Accès à l information Les documents en rapport avec le projet sont disponibles sur après identification. Sur la gauche, aller sur groupe de travail Esppadom à Phase 1 à les livrables. On peut alors trouver les trois flux et en dessus les exemples descriptif des XSD (définition de la structure des schémas XML) de chacun des flux. 2

3 1.3 Listes de codes Le standard ne fournit pas, dans son périmètre actuel, les nomenclatures et codes à utiliser. Ce ne sera jamais le cas, sauf pour celles des données qui font ou feraient l'objet de norme française obligatoire. Des interdictions peuvent aussi exister (comme pour l'utilisation du NIR "n SS"). Aujourd'hui, il est essentiel de conserver les référentiels utilisés dans les échanges, en général définis par le Conseil général et souvent en référence aux normes et standards de l'administration lorsqu'il en existe. A terme, Esppadom, comme tout standard d'échange, devra fournir des codes par défaut. C'est à l'ensemble des utilisateurs, en accord avec les tutelles du secteur, d'identifier ces codes par défaut. Par ailleurs, l'évolution vers des codes standard est souhaitable, pour faciliter le travail des uns et des autres et les comparaisons et regroupements. Il sera aussi nécessaire pour tous les utilisateurs d'esppadom de pouvoir se relier à un site fournissant les différents référentiels, car en tout état de cause, des évolutions seront inévitables. 1.4 Nomenclature des prestations Comme les autres, cette nomenclature est libre. En fait, l'unicité n'est pas recherchée systématiquement. Des spécificités, des accords locaux peuvent apporter par exemple un détail plus fin. En revanche une nomenclature pivot apparaît indispensable et Edess a commencé d'y travailler. La version de mai 2014 est sur le site Edisanté-Edess. 2 Règles d'ensemble pour le standard et les trois flux 2.1 Caractères XML Une liste des caractères spéciaux en XML, notamment le é et le è (utiles pour les noms et prénoms), peut être trouvée à cette adresse : Contraintes (0,1) Ce qui est noté obligatoire sur papier est noté 1 dans le format, c est une notion obligatoire. 0 : facultatif, avec 0 n lorsqu'il peut y avoir plusieurs occurrences. 2.3 Comment savoir si on est sur une création, modification Le type de code : champ typecode, qui permet de dire si l on est sur une création ou une modification. Le flux Order est un peu compliqué. En effet, il faut distinguer le flux de données (le véritable objet) mais prendre en compte le flux d échange de documents. Or, ceux-ci ne sont pas listés, mais ils font partie de la vie de la commande. 2.4 Taille des champs (par ex. pour un identifiant) On ne fixe pas la taille des champs dans l EDI et en particulier en XML c'est une arborescence logique. 2.5 Commande et lots de commandes Conformément à la norme européenne, il n y a qu un seul fichier par commande donc autant de fichiers XML. 3

4 2.6 Commande et transaction Quelle différence à faire entre le numéro de transaction et le numéro de commande? Le numéro de transaction est unique et correspond à l envoi d un lot de commandes (l enveloppe de transmission). La transaction est l'équivalent du cachet de la poste. Le n de transaction est porté par tous les messages qui ont été envoyés au cours de la session correspondante. C'est important pour tracer les messages. Chaque commande porte son propre numéro de commande. Le numéro de commande correspond à une commande à une date et heure données. Si l on constate une erreur dans le corps de la commande, on crée un nouveau numéro de commande qui se trouvera dans un envoi suivant donc avec un nouveau numéro de transaction. Seul, celui qui émet le message peut faire référence du n de transaction dans la suite du processus pour la traçabilité. Le numéro de commande est un numéro de plan d aide. 2.7 Tarifs, référence externe. Le catalogue est une référence de tarif qui peut être différent selon le prestataire. On émet la commande en fonction de la révision de prix et on ne révise pas toutes les commandes. Le prix doit être indépendant de la commande. Par exemple, aujourd hui beaucoup font des révisions de prix en fonction de chaque prestataire. On peut imaginer envoyer un bon de commande avec une prise en charge, (qui fait référence au tarif décrit dans une référence externe) de par exemple 20 heures plafonné à 400 euros. On n a donc pas à rééditer les commandes, chaque fois que l on change un prix. Comment on prend en compte le Ticket Modérateur? La prise en charge est de 20 h avec une référence à un tarif avec un plafond de 400 euros. Il y a alors deux solutions possibles : - - On peut définir la règle pour faire varier le nombre d heures par exemple 20h00 à 20 euros plafonné à 400 euros, et on applique le calcul avec le prix négocié dans la référence externe. On peut aussi fixer la règle que la prise en charge est toujours de 20 heures avec un plafond de 400 euros, et lorsque l on on fait varier le prix le montant attribué change et le TM avec. Soit le prix est dans la ligne de commande, soit il est en dehors de la commande. C est au choix. C est par exemple le CG ou la CARSAT qui définit la table des prix et qui la diffuse. C est le catalogue des tarifs que l on trouve dans l industrie. 2.8 Bloc instruction de livraison. On définit la nature du contrat à cet endroit. 2.9 Instructions optionnelles pour l exécution des services : Recurrence Rule Bloc instructions optionnelles pour l exécution des livraisons avec un champ libre avec du texte. Utilisation de la norme Recurrence Rule, standard utilisé par tous les agendas. Il faut définir un champ spécifique "RRULE". C est un seul champ texte qui permet de définir l ensemble. Les noms des jours et des mois sont totalement codifiés. 4

5 Comme on le voit sur le format est défini ainsi : rrule = "RRULE" rrulparam ":" recur CRLF rrulparam = *(";" xparam) Par exemple, pour 10 occurrences d une prestation hebdomadaire: DTSTART;TZID=US-Eastern: T RRULE:FREQ=WEEKLY;COUNT=10 ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21 (1997 9:00 AM EST)October 28;November 4 De nombreux exemples pour des cas différents et très spécifiques sont disponibles sur le site, où l on trouvera notamment le code des jours et des mois. RRULE doit être spécifié à deux endroits : la règle attendue pour le mois et en dessous, pour le détail de la mise en œuvre des heures dans la semaine et la journée. On peut toutefois spécifier uniquement le détail en champ texte sans faire référence à RRULE Quelle différence à faire entre le plan d aide et la prise en charge Le plan d aide, c est la définition de ce que l on va apporter au bénéficiaire. La prise en charge, c est ce que l on demande à un prestataire en particulier de faire (pour tout ou partie du plan d aide). Un plan d aide pour un unique bénéficiaire peut donc correspondre à plusieurs prises en charge, l une d un mandataire et l autre d un prestataire par exemple ; il est donc nécessaire de séparer les deux bons de commande Dates Les dates sont toujours au même format international. (HH, MM, SS) 2.12 Gestion des factures Une facture pour chaque prise en charge : c'est la norme européenne. Il faut distinguer les récap. En général, le prestataire envoie une récap. des factures, alors que le message Invoice envoie une facture par bénéficiaire. En fait, toutes les factures vont être envoyées dans une transaction. La récap c'est la liste des factures de la transaction. C'est aux SI de le faire pour ceux qui le veulent. C'est inévitable en pratique car le volume de factures, (et en particulier si on doit avoir du papier), serait trop grand. Donc, ce qu'esppadom appelle "Facture" est une ligne dans ce que les acteurs actuels papier appellent "Facture". Récap = transaction, Ligne = numéro de facture Il n y a pas de problème d intégration des factures une à une dans un logiciel métier du CG, pas plus qu un fichier récapitulatif des factures. Le logiciel métier doit pouvoir faire le nécessaire pour reconstituer un ordre de paiement «proforma» correspondant au prestataire (avec le code «N de transaction» regroupement de factures du prestataire). 5

6 Le principe retenu par Esppadom est de dissocier d une part l émission d une facture (le document d échange) dans laquelle, il doit y avoir la granularité la plus grande des informations et d autre part, le traitement des données et la forme de la restitution de l information qui interviennent ensuite dans le logiciel médico-social du CG. La dématérialisation électronique permet cela sans les inconvénients de recevoir tous les mois au Conseil général une pile de factures papier. La fonction «vérification du service fait» par rapprochement de la facture du plan d aide est en aval de la transmission. Le repérage dans le SI peut être la concaténation numéro de Transaction - numéro de facture Lorsqu il y a une anomalie sur une facture dans une transaction (groupe de factures), seule la facture incriminée est rejetée et renvoyée au prestataire. Il n y a pas de réémission de la même facture (même numéro de facture) mais la production d une nouvelle facture avec un nouveau numéro de facture Gestion des décimales A nouveau, ESPPADOM s appuie sur les normes internationales. Il convient de rappeler trois règles de ces normes : Décimales (Règle 9) Prix/Tarif avec 4 décimales. Quantité avec 3 décimales Montant avec 2 décimales, donc uniquement des centimes Taux de TVA en pourcentage avec 2 décimales Calcul du prix unitaire (Règle 8) Le prix net doit être égal au prix du prestataire moins le montant du ticket modérateur. "Net price (INV075) SHOULD equal gross price (INV077) less price discount (INV076) amount." Exemple : Si le tarif est de de l'heure, et que le ticket modérateur est de 10% à charge du bénéficiaire, le prix unitaire doit être exprimé en euro et sera choisi par le donneur d'ordre: Soit 1.98 pour le bénéficiaire et pour le donneur d'ordre Soit 1.97 pour le bénéficiaire et pour le donneur d'ordre /... 6

7 Calcul de la facture (Règle 2) Exemple 1 les arrondis ( avec montant maximum fixé dans l Arrêté de plan d aide à 300,00 euros avec la TVA calculée en dedans sur le montant pied de facture à deux décimales) Exemple d'arrondis sur une facture mensuelle pour un bénéficaire Exemple 1 Exemple 2 Exemple 3 1ère ligne détail prix unitaire (tarif N 1) 18, , ,0000 1ère ligne détail quantité 4,999 5,000 5,001 1ère ligne détail de prestation du mois 89,98 90,00 90,02 2ème ligne détail prix unitaire (tarif N 2) 21, , ,0000 2ème ligne détail quantité 9,999 10,000 10,001 2ème ligne détail de prestation du mois 209,98 210,00 210,02 3ème Ligne 3ème Ligne 3ème Ligne Montant total ou net de l'ensemble des prestations 299,96 300,00 300,04 dont Montant HT 272,69 272,73 272,76 dont TVA (10%) 27,27 27,27 27,28 Exemple 2 Quantité Prix unitaire Tx TVA Total Ligne Ligne facture 1 25,5 19,75 5,5 503,63 Ligne facture 2 12,5 19,75 5,5 246,88 Ligne facture 3 13,3 19,75 5,5 262,68 1 Somme des lignes détail sans TVA 1013,19 2 Somme des TVA 55,72 3 Arrondi des lignes détail 4 Total facture TTC Déjà payé (Ticket Modérateur) -0, ,89 100,00 6 A payer : , Changement de prise en charge Lors d un changement de prise en charge (ex : une révision de tarif), le principe retenu est de produire deux lignes séparées dans la facture correspondante au bénéficiaire. Pour les régularisations d Arrêté de prestations faites en anticipation (accord oral) par exemple sur le mois précédant alors que les droits n ont pas été ouverts dans le logiciel métier du CG. Les rapprochements sont difficiles à mettre en œuvre dans le logiciel métier (pour éviter les anomalies, l Arrêté doit être précis dans sa notification sur la date réelle et effective du début de prise en charge). 7

8 3 Notes particulières pour les développeurs, sur les mappings Order et Delivery Les questions posées jusqu'ici sur la facture sont les mêmes, celle-ci résultant du plan d'aide et des données de télépointage. 3.1 Mapping Order En-tête : o le champ «0..1» signifie qu il peut y avoir plusieurs valeurs pour ce champ ; il est donc facultatif. o Le champ nommé en-tête correspond à la version actuellement utilisée de la norme ESPPADOM Contexte générale o Numéro ou référence de transaction : il est affecté par les systèmes. Il est au début du SpecifiedTransactionID. C est la date au format «Ymdhis» de l exécution de la génération. o 4 e l. CommitteeDateTime : Date à laquelle la commission est réunie Identification du document o 2 e l. numéro de commande : il est généré (par l éditeur du CG) o 4 e l. état de la demande : il peut y avoir deleted, modified, created. o 5 e l. date du bon de commande : c est bien la date d émission, et pas la date de création. o 10 e l. date de début et de fin de validité : ce sont les bornes du plan d aide du bénéficiaire Accord entre les intervenants o 3 e l. référence du prestataire : c est un fichier du CG7 o Donneur d ordre : c est le département. Les CG peuvent avoir un SIRET, mais pas forcément. o Code pays : voici une liste du code de tous les pays o Cadre d intervention : le schemeid correspond à une référence personnelle et le schemeagencyname à un label. C est vrai partout où ces attributs sont utilisées. Il ne peut y avoir d espace dans le schemeid. Instructions de livraison o 2 e l. destinataire : l ID du bénéficiaire est toujours obligatoire, le SIRET est facultatif. o 10 e l. date de naissance : les dates sont au format américain. Si la date n est pas connue, laisser par défaut. o Nom du destinataire postal : comme son nom l indique, c est le nom du destinataire postal (qui peut différencier du nom du bénéficiaire) o GIR : il n existe pas dans le cadre d une intervention PCH, il est donc optionnel o Montant maximum prise en charge : le token indiqué correspond uniquement à la monnaie utilisée (Dollar, euro ) Détail de services produits o 3 e l. numéro de ligne de commande : c est le service. Il peut en effet y avoir plusieurs services, donc plusieurs lignes, mais il peut aussi n y avoir qu un service global, donc renseigné sur une seule ligne. o 12 e l. prix unitaire : c est celui convenu avec le prestataire 8

9 o o o Quantité plafond : Il peut y avoir un plafond à ne pas dépasser, il est renseigné là. Motif de l ajustement : C est une valeur qui doit être fixé à 30 ; et fixé à 77 pour le flux Invoice Code du service : ce n est pas forcément le même pour le comptable 3.2 Delivery Identification du document o 2 e l. numéro de bon de livraison : il est défini par le CG et il correspond à la prestation o Date du bon de livraison : c est la date à laquelle on l envoie (qui ne correspond pas forcément à la date de la commande, si le prestataire n est pas connecté) Information de livraison o Description de l événement : la listagencyname est le nom de la structure à laquelle le récepteur se réfère. 9