Le NOUVEL ACHAT

Aller au contenu | Aller au menu | Aller à la recherche

jeudi, avril 16 2015

Le NHS casse les frontières de l’eProcurement du monde de la santé

D’avril à mai 2015, le NHS ‘National Health Service » britannique lance un pilote à grande échelle servant de démonstrateur technologique de sa capacité à échanger et traiter de bout en bout les commandes, les avis d’expédition et la facturation électronique avec ses fournisseurs en utilisant le standard européen PEPPOL.
NHS eProcurement

Poursuivant son ambition de développer ses approvisionnements électroniques dans la conformité des standards européens, le NHS confirme le crédo d’une stratégie eProcurement publiée en mai 2014 (1) fondée à la fois sur PEPPOL et sur GS1. En démontrant la capacité des mécanismes PEPPOL et l’infrastructure de transport européenne à traiter de bout en bout les flux de commandes, des avis d’expédition et des factures électroniques, le NHS veut sensibiliser ses fournisseurs au choix technologique des standards et d’un modèle quatre coins garantissant leur indépendance. Le NHS ne cache pas non plus l’effet de levier escompté sur ses achats par la capacité du réseau européen à dégager des économies liées à l’interconnexion à grande échelle de ses fournisseurs (2). Pour le NHS la feuille de route consiste à :

  • Etablir l’échange de messages entre les points d'accès de PEPPOL en assurant la conformité des formats avec le standard PEPPOL BIS (3)
  • Publier une étude de cas spécifique montrant comment les processus PEPPOL peuvent s’intégrer dans l’environnement NHS et celui des fournisseurs ;
  • Mettre en place un annuaire centralisé des services et des entités du NHS (SMP, Service Metadata Publisher);
  • Proposer un ensemble de points d’accès PEPPOL parmi lesquels les partenaires de la NHS pourront choisir et finalement établir une autorité PEPPOL.

Ainsi que l’affirme Ger CLANCY d’IBM, "Le plus grand obstacle à une diffusion dite "virale" du commerce électronique est son coût et l'existence de normes concurrentes et incompatibles entres elles. Jusqu'à l'avènement de PEPPOL, le pouvoir de l’eProcurement était aux mains des grandes entreprises qui exigeaient de leurs fournisseurs de s'intégrer à leur système EDI et des opérateurs de services qui ont aussi largement profité de cette aubaine pour facturer des coûts techniques d’implémentation très élevés en maintenant la grande majorité des petites entreprises hors du marché de l'eProcurement , à moins d’y être contraintes par leur donneur d’ordre."


(1) NHS eProcurement strategy

(2) Vidéo de présentation IBM sur YouTube https://www.youtube.com/watch?v=q0G...

(3) PEPPOL BIS « Business Interoperability Specification »

mercredi, janvier 21 2015

The french eInvoicing Platform aims to ensure interoperability

secteurpublic.jpg

Intensive developments are being carried by AIFE, the french IT agency of the Ministry of finances on the technical specification of the next e-Invoicing platform CPP 2017 (1). In the course of discussions to define the common set of requirements, AIFE has re ensured the public sector and SME ‘s representatives as well that the enablement of several thousands of public authorities will be achieved through a single gateway able to transact several thousands of invoice in 2017.

When dealing with public procurement, interoperability is not only a matter of format and the post-award process little more than just empty words. By sending an invoice, a supplier claims for a payment, triggering several cascading processes in the accounting system of contracting authorities, involving reconciliation or external services such as public treasury.

Easing life of businesses generally goes hand in hand with securing the process to payment. This point was stressed by the act of enablement -article 1 (law of simplification) « By offering new services, such as online tracking ability of the processing status of invoices issued. ». The platform will therefore offer a monitoring of the invoice lifecycle, notifying several progression status to the sender.

Along with this status, the platform is expected to perform at least three levels of validation in entry. A technical validation applied to formats, syntax and cardinality ; a second level on the data structure such as checking if a field is not empty, absence of reference to order number if requested by the buyer, party identifiers etc. A third validation will be held by the recipient service itself.



For ensuring an appropriate routing , every public body will be identified by a National SIRET number with potentially an added extension for identifying the service. The directory of all CA’s is expected to be published and potentially electronically invoked.

For both populations of suppliers and buyers, CPP 2017, will provide three potential business interfaces, classic EDI, portal or service modes. Depending on their choice, any supplier will be able to access directly via the current CHORUS portal or a service provider. The first mode is expected to be enough technologically neutral to offer a solution at zero cost of entry.

The solution contemplates several structured (XML) or unstructured (PDF) formats in entry, each one reverting to the unique semantic pivotal format. Assuming conformance to the future EN core semantic model currently under development at the european level; the platform will accept two basic structured formats, one currently bound to UBL 2.0 and accepting PEPPOL invoices received from the European network another to CII UN/CEFACT, plus one specific to public sector internal exchanges (PES V2).

(1) CHORUS PORTAIL PRO

mardi, septembre 23 2014

Le NHS fonde sa stratégie eProcurement sur les standards GS1 et PEPPOL

NHS

« Nous avons assisté à de nombreuses initiatives visant à améliorer l’efficacité de l’e-procurement mais cette fois nous parlons de « business » et nous entendons bien produire des gains permettant de dégager plus d’argent sur le front de l’offre de soins. Pour nous assurer de gains durables et en augmentation, j’annonce que cette stratégie de gestion des approvisionnements électroniques reposera désormais sur la codification GS1 et sur PEPPOL comme standard d’échange de messages e-procurement avec l’ensemble des industries de santé et leurs activités de supply-chain »

C’est en ces termes que le Dr Dan Poulter parlementaire près le Secrétariat d’Etat à la Santé Britannique confirme la stratégie du NHS « National Health Service » en matière d’e-procurement (1) et qui pourrait se résumer à déployer le standard GS1 et PEPPOL pour l’e-procurement avec l’ensemble de ses fournisseurs .

Notre responsabilité dans le programme OpenPEPPOL en France nous permet de saluer la clairvoyance d'un choix pour lequel nous avons milité sans toujours réussir à nous faire entendre. Nous pensons que l’achat de produits de santé, certes complexe par l'ampleur des données et la sensibilité de certaines informations, ne procède pas en définitive d’un exotisme particulier par rapport à d'autres types d'achats. Partant de ce constat, il importe que les acteurs comprennent, n’en déplaise à certains, que se ranger comme le fait le NHS sous la bannière des standards Internationaux et européens constitue la seule voie possible pour déployer l’e-procurement avec le maximum d’efficacité.

Mettre en oeuvre des standards évite de développer des systèmes hétérogènes avec comme conséquences, la création de silos d’informations, l’impossibilité accrue d’échanger avec ses partenaires commerciaux qui n’utilisent rien de commun avec vous et encore moins entre eux. Cette interopérabilité s’exprime à plusieurs niveaux, sémantique (contenu des messages) , syntaxique (formats) et transport (connectivité) ; trois dimensions pour lesquelles le programme européen PEPPOL apporte une réponse globale.

De son côté, GS1 constitue un standard reconnu au plan international par la FDA en matière de données de santé. Véritable enjeu de traçabilité et de lutte contre la contrefaçon, l’identification unique du produit (UDI) implique que le fournisseur enregistre ses produits en un seul lieu (le datapool) auquel l’ensemble des abonnées GS1 peuvent accéder depuis le GDSN (Global Directory System Network).

Le pilote PEPPOL ou l’expérience française en matière de catalogue électronique

En conduisant deux expérimentations pilotes in 2012 avec UniHA (2) puis en juin 2014 sous l’égide de l’ARS île de France,nous avons démontré qu’un système reposant sur un échange de données e-catalogue selon PEPPOL et dans la conformité GS1 permettant des échanges entre les hôpitaux et leurs fournisseurs, était non seulement viable mais capable de produire sur le long terme une bonification du système de données et des gains appréciables pour l’ensemble des acteurs.

  • Nous avons développé un master data management system (MDM) capable de comparer et de corriger le référentiel hospitaliers avec les données issues de GS1. Comme le souligne la NHS « Le Master data donne une version précise et définitive de l’information produit. L’utilisation d’un master data est relativement limitée dans les achats ; il en résulte que le même produit peut présenter des codes différents entre fournisseurs… »
  • Nous avons fait en sorte que les données puissent alimenter les référentiels hospitaliers toujours en fonction de la capacité de traitement de chaque système de données ;
  • Nous avons envisagé la possibilité d’étendre la mise à disposition de ces données à d’autres systèmes de la sphère patient anticipant une vision élargie de la donnée indispensable à l'offre de soins ;
  • Nous avons intégré les données en provenance des marchés pour faciliter le traitement des allotissements et le chainage avec l’exécution post-attribution et les commandes ;
  • Nous avons disposé d’un point d’accès PEPPOL dialoguant avec un autre point d’accès tous deux interconnectés via le réseau PEPPOL validant ainsi le principe d’une connectivité globale préservant l’indépendance des acteurs ;
  • Nous avons préparé les prochaines étapes de l’e-procurement en permettant le bouclage des flux et le chaînage des données de commande avec la facture etc.

Parvenu à ce point, nous réalisons la convergence de notre démarche avec la NHS qui a bien perçu la complémentarité des standards et veut désormais l’inscrire dans l’agenda de ses fournisseurs.

« Cette stratégie implique que les principales normes requises des fournisseurs de la NHS et de leurs prestataires soient, GS1 (pour le codage des produits, l’identification d'emplacement et la synchronisation des données); PEPPOL (pour les commandes, les demandes de prix, les factures). L'adoption de ces normes permettra l'interopérabilité entre les fournisseurs et les prestataires de services du NHS sans qu’il soit nécessaire de changer leurs systèmes…. »

Alors, qu'en est-il chez nous ?


Si l’on suit la NHS, ce dont il est question ici n’est rien de moins que l’émergence d’une stratégie globale et coordonnée d’approvisionnement pour les hôpitaux.. Cette volonté n'est pas nouvelle mais comme le souligne le Health Service Journal d’avril 2014. (3) s

« Les efforts précédemment déployés par la NHS pour moderniser on e-Procurement ont été parcellaires en raison d’un manque de direction centrale »
Avec le déploiement généralisé des standards GS1 et PEPPOL, c'est bien d'un effort coordonné dont il s'agit. La perspective d'une stratégie d'ensemble de la filière en matière d'achat, fait frémir plus d’un fournisseur. Il ne faut pourtant pas sous-estimer l'importance d'une telle démarche pour tout notre système de santé; ce que le NHS résume à « Better procurement, better value, better care » (4). Ignorer l'urgence d'une telle stratégie pour nos hôpitaux, relèverait tout bonnement de la courte vue ou du combat d’arrière garde.

(1) stratégie e-procurement de la NHS [https://www.gov.uk/government/publications/nhs-e-procurement-strategy ]
(2) article "French healthcare goes digital" [http://www.peppol.eu/news/openpeppol-news-2013/french-healthcare-goes-digital-with-peppol-e-catalogues-1 ]

(3) Article du Health Service Journal [http://www.hsj.co.uk/home/innovation-and-efficiency/eprocurement/e-procurement-strategy-is-crucial-to-the-modern-nhs/5070247.article#.VCGAQsFOLIU ]
(4) "meilleurs achats, meilleure valeur, meilleur soin"

Au Mexique, la facturation électronique obligatoire pourrait constituer la parade contre la fraude

mexique

Le site de l’administration fiscale Mexicaine (1) prévient les entreprises "A compter du 1er avril 2014, le seul moyen valide de vérification fiscale est la facturation électronique"; ajoutant que le service de facture électronique (CFDI) est gratuit. En rendant obligatoire la facture électronique, l’autorité fiscale retire au fournisseur le droit de générer lui-même sa facture, s’il n’a pas préalablement téléchargé un récépissé fiscal signé électroniquement. Par ce dispositif, l’administration fiscale mexicaine rend obligatoire la déclaration préalable, un moyen habile et efficace de lutte contre la fraude.


Obligatoire pour les entreprises réalisant un chiffre de plus de 250 000 pesos (20 000 USD) la facture dématérialisée doit obligatoirement être accompagnée d’un récépissé fiscal CFDI (Comprodentes fiscales digitales por Internet) lui-même assorti d’un cachet électronique apposé à l’aide d’un certificat électronique CSD (Certificado de Sello Digital) émis par l’administration fiscale.

Tout cela pourrait paraître bien compliqué, s’il ne s’agissait avant tout d’authentifier la transaction par un cachet fiscal dont l’opposabilité « de jure » est fondée sur l’émission d’un certificat CSD contresigné par l’entreprise . Cette contre-signature est apposée en téléchargeant l’application SOLCEDI (Solicitud de certificado Digital) permettant de générer une signature électronique avancée FIEL (firma electronica avanzada) sur le récépissé fiscal.

Le traitement de la facture s’effectuera gratuitement par l’intermédiaire d’un prestataire (2) de validation. Le rôle du prestataire est d’opérer la validation technique du document, de vérifier que le CFDI correspond bien au CSD délivré par l’autorité et authentifiant l’entreprise pour finalement délivrer un récépissé fiscal (ou cachet). L’émetteur devra d'autre part disposer d’un archivage électronique permettant de conserver les CFDI au format XML et le cachet fiscal électronique sur son système pour une période minimale de 5 ans.

Le CFDI se compose d’un fichier primaire XML et d’un PDF généré automatiquement à partir du fichier primaire. Ce PDF devra être imprimé et joint obligatoirement au bordereau d’expédition des marchandises conformément à l’article 29a du code fiscal (Código Fiscal). Il fera figurer le code-barre (ou 2 D ?) comportant le numéro de série du CSD, une légende indiquant que c’est une représentation imprimée du récépissé fiscal électronique avec l’heure et la date d’émission.

La facture comportera un certain nombre de champs obligatoires. Si l’entreprise possède plus d’un établissement, l’adresse de celui ayant émis la facture devra figurer. Les éléments optionnels de nature non fiscale (informations commerciales) sont placées dans la section « Addenda » seulement après validation par les services fiscaux. Les informations complémentaires de type sectoriel (automobile, grande distribution etc.) seront spécifiées par la balise <complemento>. Le logiciel ou l’ERP du fournisseur devra intégrer les pré-requis techniques prévu à l’annexe technique 20 (3) , prévoir une extraction de données en vue d’une transformation du fichier au format XML 3.2. Il est dommage que le choix de format ne repose pas sur un standard international reconnu tel qu'UBL ou UN/CEFACT ce qui impose au fournisseur un "mapping" préalable des données et un travail d'intégration supplémentaire pour générer ce format. Il est à noté que les spécifications fonctionnelles attendues du prestataire portent à minima sur les aspects suivants :

  • La validation technique des CFDI (4)
  • Le traitement unitaire des CFDI hors « addenda » et « complemento »
  • l'acceptation des certificats CSD
  • la génération du document CFDI conformément à l’annexe 20 technique
  • la validation technique et la certification du document CFDI
  • la possibilité de consultation, de conservation, d’impression des CFDI durant 3 mois
  • l'envoi immédiat d'une copie du CFDI validé à l’administration fiscale

En conclusion, le dispositif mis en place par l’autorité fiscale mexicaine semble constituer une solution originale de parade contre la fraude en délivrant un cachet fiscal validant la facture avant même que celle-ci soit émise par le fournisseur. En découplant le traitement fiscal du processus de facturation, le dispositif stigmatise les deux statuts de la facture, celui d’original fiscal et celui de document commercial. Dissocier les deux, permettrait d’envisager un traitement différencié, comme la possibilité de capture de la TVA à la source.
Plusieurs remarques toutefois sur les inconvénients possibles du système. L’emploi systématique de la signature électronique, sujet amplement débattu, risque d’alourdir le traitement. La spécification technique prévoit un traitement unitaire des factures mais qu'en est-il d’un lot de factures ou d’une séquence de factures (traitement batch) ? Si une modification intervient sur la facture, l’annulation de cette dernière pour en émettre une nouvelle, semble plus délicate avec un tel processus ; la question des avoirs ne semble pas évoquée non plus. Certains fournisseurs ou secteur d’activité peuvent exiger l’ajout d’informations contextuelles et devront le faire en « addenda » après-coup, ce qui nécessite une réinjection de la facture après traitement fiscal dans l’ERP du fournisseur. Malgré ces inconvénients, la piste semble prometteuse et mériterait d’être examinée avec plus d’attention au niveau européen dans le contexte d’une nouvelle norme sur la facture électronique.

(1) Servicio de administracion tributaria (SAT) [http://www.sat.gob.mx/]
(2) A ce jour 67 PAC (Proveedores Autorizados de Certificacion) ont été référencés
(3) Annexo 20 de la ley del ISR

(4) Portail de vérification des CFDI [https://verificacfdi.facturaelectronica.sat.gob.mx/ ]

- page 7 de 24 -