| VendrEDI |  |
lettre de Claude Chiaramonti | ||
| sur les
données de l'échange électronique |
||||
| Numéro 93 22 avril 2005 | ||||
|
B2B en Seeburger :
|
Point sur la"démat"
|
|
|
de l'EDI aux Services Web
|
EDI ou signature électronique
|
|
Spécialisée dans
l'intégration pour le B2B, la
socié-té mondiale d'origine allemande Seeburger est bien implantée dans
l'EDI en Europe, en particulier pour l'automobile et la
distribution. Mais Seeburger est aussi pionnier en Europe pour le
recours aux Services Web (SW) : faisant partie
des leaders en Europe, son produit-phare, Business
Integration Server (BIS) décline ainsi toute la
gamme technique de l'intégration du B2B pour être
un lien souple entre réseaux, applications et partenaires
commer-ciaux. Couvrant aussi la vente en ligne, les sites
d'enchères et les places de marché. Sans oublier la
position privilégiée de Seeburger pour
"l'ouverture" de tous les ERP : son
accord avec SAP, en
parti-culier, est la confirmation d'un partenariat
réussi permettant aux entreprises utilisant toujours SAP R/3,
comme à celles migrant vers SAP XI, d'intégrer leur B2B
en EDI, Web EDI, EDIINT ou XML et Services Web. Aussi bien en RVA
point à point qu'en Intranet, Extranet et sur Internet
ouvert.
A noter une fonctionnalité "Paper to
ERP" qui permet de saisir par lecture automatique multilingue
les données des commandes et factures, que les entreprises
recoivent encore majoritairement en papier ou par fax. En les
vérifiant par rapport aux données figurant déjà
dans l'ERP. Avec le complément d'une fonction ouverte,
BIS:Digital Invoice, s'adaptant aux
différentes législations euro-péennes pour
la dématérialisation de la facture.
Le convertisseur XML de BIS permet de traiter
tous les formats, depuis les messages Edifact (pour E.Leclerc
notamment) EANCOM ou Ansi X12, les formats VDA/Odette pour
l'automobile européenne, les données de CAO (sous le
format de l'automobile française Galia) etc. Avec une offre déjà en
place, individuelle, ou liée à SAP etc. pour l'emploi de
la saisie des données et de leur suivi en RFID.
Pour plus de 6000 clients dans le
monde, Seeburger et son BIS traitent bien au total de toutes
les formes d'intégration d'application à application, en
interne (A2A) comme en externe (B2B), quelquesoient les
plates-formes, les systèmes d'exploitation ou
d'appli-cation, depuis l'EDI communautaire traditionnel
jusqu'à un portail de Services Web offerts aux tiers avec
SOAP. Avec une déclinaison épousant les scénarios de
business sectoriels.
|
En EDI, le message facture Edifact INVOIC
est sans doute encore le plus utilisé. Et la
dématériali-sation de la facture s'est d'abord mise en
place dans les grandes entreprises participant à des
commu-nautés EDI. C'est d'ailleurs à la demande de Galia,
association EDI de l'automobile française, que la DGI a
étudié une 1ère validation juridique de la
facture électronique de type EDI (données
structu-rées). Depuis 2001, et une Directive
Européenne, s'est ajoutée la possibilité d'une
facture "document", avec signature électronique, proposée
par des sociétés comme Adesium. Et on parle de "démat fiscale",
quand la DGI ne demande plus de confir-mation papier pour
vérifier la TVA.
Où en est-on ? L'electronic business
group (ebg), qui rassemble les grandes entreprises
françaises et s'étend en Europe, a réalisé, il
y a quelques mois, un Livre Blanc pour les décideurs,
très complet, avec des témoignages. Deskom, qui vient de présenter
avec Influe une
offre européenne de
facturation électronique, a collaboré à ce Livre
Blanc où sont étudiés les obstacles à une
généralisation qui procurerait à tous des
économies. Ces obstacles résident tout d'abord dans
l'hétérogénéité des systèmes.
Côté fournisseurs "sortant" des factures comme
côté acheteurs les "entrant", il faut pouvoir offrir la
gamme des options et des formats. Cf aussi le site
dédié de GS1 France (Gencod EAN).
Pourtant, les données de la facture
sont bien déjà enregistrées au moment des commandes,
avec des modifications, le cas échéant, lors des
livraisons. Et c'est la livraison qui crée les droits à
paiement, la facture étant surtout là pour
prouver une assiette TVA etc. commune au vendeur et
à l'acheteur.
Autrement dit, la facture électronique
devrait être la cerise sur le gâteau de la supply
chain et figurer, tout naturellement en
conclusion d'un e-business. Et Edifact ne
s'étant pas généralisé, et en étant
resté, pour l'essentiel, aux messages isolés, c'est donc
aux Services Web et à BPEL qu'on peut penser pour, un de ces
jours peut-être, "orchestrer" l'extension de la
"démat" à ceux qui passent
à l'e-business en dehors d'une comm
unauté EDI. En
acceptant les factures électroniques signées des
"isolés", ou en lisant automatiquement (cf.
ci-contre) les factures papier des "anti-TIC" ! |
 |
Pour que "le message passe" il faut être d'accord
sur le sens des données Petit
Glossaire du B2Bfr
|
|
"e-domotique" et SW
|
|
Langage commun :
|
|
à partir de
l'e-construction
|
|
mapping, fusion ou CORE ?
|
|
L'industrie du bâtiment a, elle aussi,
ses langages métiers XML du B2B, comme ifcXML et aecXML (architecture,
engineering and construction). L'objectif de l'IAI
(International Alliance for Interoperability) est ainsi de
ne plus revoir de Tour de Babel, en organisant l'information des
métiers autour d'un
modèle partagé. A côté de ces
propositions très US, l'Europe a lancé bcXML, puis a
adopté des CWA (CEN Workshop Agreement) pour
l'
e-construction avec un
framework qui fait référence notamment aux
normes ISO.
Mais il ne s'agit pas de s'en
tenir au cycle de vie d'une construction, mais de
préparer le facilities management
et même "l'e-domotique", promise à un grand
avenir. La domotique comprend déjà la
possibilité d'actionner à distance les appareillages
gérant les locaux professionnels et d'habitation. On peut
ainsi lancer de loin une cuisson, régler le chauffage etc. De
plus, la domotique peut "avertir" automatiquement en cas
d'intrusion non prévue. Cette
"télé-surveillance" est en passe de
s'étendre à la gestion des équipements de toute
sorte, air conditionné etc. D'où, devant
l'importance du mar-ché, la "co-existence", surtout aux
USA, de trop de consortiums et standards. A citer,
l'ASHRAE et son BACnet, CABA et son oBIX, transféré à Oasis,
ainsi que LonMark ou le projet SIMA du NIST, AEX ou
OPC lié à des
produits Microsoft.
La tendance est d'affirmer le rôle des Services Web (SW) comme
vital pour le futur des Integrated and Intelligent
Buildings, pour la IT convergence de l'industrie des
HVAC/R (heating, ventilation, air conditioning,
refrigeration). En effet, le problème des capteurs
étant résolu, les SW semblent bien adaptés pour
fournir des formats standardisés réutilisables, à la
fois pour des messages d'alerte et pour les réglages en
retour. Par exemple pour éteindre automatiquement la
lumière dans une salle d'aéroport quand aucun vol n'y est
prévu. Ou pour la surveillance à domicile des
personnes handicapées ou très âgées,
proposée avec des SW par l'
Université de Trente
(Italie). Encore faut-il qu'il y ait eu d'abord convergence vers des standards en la
matière, pour que l'interopérabilité entre des
systèmes le plus souvent hétérogènes soit
garantie !
Et après "l'e-construction" et
"l'e-domotique", même le B2C peut être concerné ! Il
se peut que les réfrigérateurs enregistrent un jour
la sortie de la moindre bière pour en passer comman
de, si nécessaire. En SW, ou
encore Edifact, tant que ce sera toujours le
format utilisé par le supermarché du coin ! |
Le côté eXtensible de XML
conduit à des langages métiers collant bien au terrain.
Mais cela présente un risque, celui que des domaines
contigus aient chacun leur langage, avec la possibilité
d'incompré-hensions réciproques. Pour éviter ce
risque deux solutions : 1/ "mapper" les langages deux
à deux s'il y a des échanges électroniques entre eux
; 2/ tenter de fusionner toutes les données des
langages. Mais cette dernière solution ne peut gommer les
diffi-cultés sémantiques pratiques, lorsque plusieurs
termes différents désignent la même chose, ou que le
même concept a plusieurs libellés. Il faudra
bien garder tous les termes et libellés dans un
registry, avec quand même du
mapping entre eux !
Les autorités fédérales US en
font l'expérience. Un XML Federal Registry des
données administratives doit être ainsi
préparé par les
Départements de la Justice et de l'Intérieur
US. La solution était de se baser
sur GJXML, langage du Justice Department,
ayant déjà fédéré plus de 200
utilisateurs, de l'échelon local à l'échelon
fédéral. Mais tout en gardant le modèle de
GJXML, le Justice XML Data Model, mieux valait
tenir compte des core-data-types du
HSD (Homeland Security Department). D'où le
NIEM, National Information Exchange Model,
censé pouvoir ensuite être utilisé dans les
autres secteurs de l'administration US.
Problème : le HSD avait déjà
participé il y a quelque temps à une initiative
semblable, cette fois animée par la FEMA (Federal
Emergency Management Agency) appartenant pourtant au même
secteur de la sécurité ! Et
chacun de se demander comment deux initiatives visant
à la data interoperability vont donner l'exemple
! Autre doublon, l'initiative Justice-HSD est
baptisée
CORE (Collaboration
on Objects for Reuse and Exchange) et reprend
donc le sigle d'un autre CORE
(Component Orga-nization and Registration Environment), un
réper-toire fédéral en ligne de composants
business de l'Enterprise Architecture...
L'objectif peut bien être de take the
core data elements pour un seul glossaire XML
fédéral, dis-suadant d'autres agences de s'en
bâtir un : on voit qu'en fait les doublons persistent dès
le départ ! C'est que "l'information, c'est le
pouvoir" est toujours vrai, avec XML, et avec des agences US qui ne
veulent rien perdre de leurs prérogatives ! La sagesse est
peut-être de s'en tenir au mapping entre langages
métiers XML ! Et de se con
tenter des quelques données
intersectorielles "neutres" pour un Core XML
registry, du genre date de naissance ou
adresse. |
| Ce numéro 93 de VendrEDI a été adressé à 1370 abonnés Pour écrire |
| Tous les numéros de VendrEDI peuvent être téléchargés à http://www.actimum.com/acvendredi.htm |