WO2003054738A1 - Echange de catalogues electroniques entre entreprises - Google Patents

Echange de catalogues electroniques entre entreprises Download PDF

Info

Publication number
WO2003054738A1
WO2003054738A1 PCT/FR2002/004521 FR0204521W WO03054738A1 WO 2003054738 A1 WO2003054738 A1 WO 2003054738A1 FR 0204521 W FR0204521 W FR 0204521W WO 03054738 A1 WO03054738 A1 WO 03054738A1
Authority
WO
WIPO (PCT)
Prior art keywords
supplier
buyer
data
database
catalog
Prior art date
Application number
PCT/FR2002/004521
Other languages
English (en)
Inventor
Pierre Bregant-Belin
Matthieu Geerebaert
Original Assignee
France Telecom
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom filed Critical France Telecom
Priority to AU2002364868A priority Critical patent/AU2002364868A1/en
Publication of WO2003054738A1 publication Critical patent/WO2003054738A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions

Definitions

  • the present invention relates to relationships between companies on
  • the invention proposes a technique making it possible to adapt the information available from the Suppliers to the specific requirements of the customers (which will be called hereinafter in this document Buyers).
  • the technique proposed by the invention allows significantly lighter and faster updates, and thereby limiting the risk of error.
  • the solution proposed by the invention makes it possible to meet the need of the Buyers / Suppliers, by:
  • the invention provides a method of exchanging electronic catalogs between at least one Supplier and at least one Buyer, characterized in that, an electronic catalog being available from the Supplier in at least one first file format specific to the Supplier and having to be available from the Buyer in at least a second file format specific to the Buyer, the following steps are implemented:
  • the proposed method avoids doing the current implementations which are heavy and sources of errors.
  • This method can be used by companies wishing to set up an electronic catalog exchange system within the framework of a Supplier-Buyer relationship.
  • the extraction of data from a Supplier file and / or the reconstitution of a Buyer file from data stored in a Buyer database is (are) implemented at level d '' one or more servers with which the Supplier and / or the Purchaser are able to communicate via an internet interface to load and / or unload data files.
  • the Supplier and / or the Purchaser are able to communicate via an internet interface to load and / or unload data files.
  • Supplier defines attributes which are common to all Buyers and attributes which are specific to each of Buyers.
  • a Supplier defines codes and meanings of the currencies and units that it uses; to initialize his database, a Buyer defines codes and meanings of the currencies and units he wishes to use; and to initialize a Supplier / Buyer relationship, we define rules for correspondence between the defined codes and meanings for the Supplier database and the codes and meanings defined for the Buyer database.
  • the Supplier has the possibility in particular not to keep the updated data and to revert to the previous data.
  • the purchaser visualizes the modified data and validates it, the information relating to the validation by the Purchaser being retransmitted on the Supplier side.
  • the Supplier retrieves data dedicated to this purpose from data stored in the Supplier database.
  • files which constitute attachments which are transmitted by the Supplier are preferably copied for the Buyer, by renaming them.
  • the Supplier defines attributes of categorization of products and in that one defines links between these attributes of category and target categories of the Purchaser, so that each category of the Purchaser is filled with products to be in this target category.
  • the invention also provides a system for implementing exchanges of electronic catalogs between at least one Supplier and at least one Buyer, characterized in that, an electronic catalog being available from the Supplier in a first file format specific to the Supplier and must be available from the Buyer in a second file format specific to the Buyer, it includes: - a supplier side database, in which data corresponding to attributes chosen by the supplier as characterizing the information in its electronic catalog are stored, - means for extracting from an electronic catalog file
  • the processing means on the Supplier and / or Buyer side include servers with which the Supplier and / or the Buyer are able to communicate via an internet interface to upload / download files.
  • FIGS. 1 and 2 illustrate the system used on the supplier side and on the buyer side.
  • Supplier means a company which wishes to make available to one or more other companies (the Buyers) data on the goods or services it offers. Some of these data are common to all Buyers, others are specific to certain Buyers. The data made available by a Supplier are expressed according to a format, classification, etc. specific to this Supplier.
  • Buyer means a company that wishes to obtain data on goods or services offered by one or more other companies (Suppliers).
  • the data that a Buyer wishes to obtain must be obtained by respecting a format, classification, an order, etc. specific to this Buyer; he may for example want to obtain products aggregated within the same classification, and not sorted by Supplier.
  • General Supplier Catalog means all of the products offered by a Supplier and which can be selected by a given Buyer.
  • a general Supplier catalog is made up of data common to all Buyers, data that characterizes the product.
  • Supplier specific catalog means a set of products (from a Supplier) selected by a given Buyer.
  • a specific Supplier catalog is made up of common data, possibly supplemented by data specific to this Buyer.
  • a specific supplier catalog contains a subset of the product references present in the general supplier catalog.
  • Attachment electronic file generally in binary format, linked to one or more particular products, complementing the description of the product (s), and which cannot be easily transmitted in textual form (eg image file of the product , detailed product description file in Adobe Acrobat format).
  • the technique proposed by the invention is broken down into four main parts: - initialization of a Supplier,
  • B specify a set of additional information allowing the exchange of data, the declaration of right of access, etc. (e.g. company data sheet, people who will have access to the application or simply play a role in the exchange of data),
  • the information from this different information leads to the creation of a space dedicated to this Supplier and configured according to the information transmitted and allowing him to connect to the application via a web browser (logins - passwords) and to perform operations data I / O via input or file upload / download.
  • the types of views and reports generated can also be customized according to the needs of the Supplier. It should be noted in particular that when a Supplier already declared wishes to address another Buyer, only the information allowing to initiate this new exchange must be transmitted.
  • the types of views and reports generated can also be customized according to the needs of the Buyer.
  • a storage space is reserved and an output channel is configured: this is a specific channel which allows you to search for source attachments (transmitted by the Supplier), to copy, renaming them, in the storage space reserved for the Purchaser.
  • the Supplier has the version of its general catalog as well as the latest version of each specific catalog dedicated to each of its Buyers.
  • the Supplier launches differential analyzes of the modifications carried out compared to the latest versions of the catalogs: the references of the products whose data have been changed are extracted and an indication of the modification (Add, Modification, Deletion) is automatically added. If desired, a more complete report can also be consulted in order to facilitate its validation work: for each product reference, when data has been modified, the modified data are highlighted and the old data is recalled. It is also possible, for example, to indicate in this report that such price has been increased or decreased by such value (if the price data is not encrypted).
  • a differential analysis is available for data common to all Buyers, and another differential analysis for each specific Buyer catalog. The Supplier then verifies the data.
  • the Supplier also has, if necessary, export channels allowing him to recover the data present in his space for the purposes of internal exploitation (electronic file allowing him to synchronize in the event of online entry, for example).
  • the batches of data transmitted by the Suppliers are aggregated within the same catalog or remain separated by Supplier.
  • the Purchaser can then access one or more views allowing him to validate or refuse the proposed updates. These updates are described at least via a report (addition, modification, deletion), and, if necessary, with a report presenting more precisely the differences.
  • He is also sent one or more validation reports allowing him to have electronic documents recalling the proposed modifications, reports which he can complete locally, then load in his validation zone for updating the validation status.
  • it has another channel enabling it to obtain the electronic version of the validated data, in the required format, for production at home.
  • the complete catalog (s) of the Purchaser present in the Purchaser's space is (are) updated with all the products accepted. This, coupled with a backup process, allows, if necessary, to generate a full version of the catalog (s) for reloading on the the Purchaser, as is necessary at certain times (eg change of version of the tool).
  • the validation by a given Buyer is transmitted in the space of each Supplier concerned so as to keep him informed in real time of the validations carried out by the Buyer, this feedback is presented to the Supplier in the form of a view grouping together products accepted, refused or being validated, with a comments area in which the Buyer can give the reason for his refusal, in particular. This allows the Supplier to start, if necessary, to verify data relating to a refused product, for example.
  • the current version of the specific catalog is updated according to the data actually accepted by the Buyer, and the loading channel relating to the specific catalog of this Buyer is opened again for update by the Supplier.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Procédé d’échange de catalogues électroniques entre au moins un Fournisseur et au moins un Acheteur, caractérisé en ce que, un catalogue électronique étant disponible chez le Fournisseur sous au moins un premier format de fichier propre au Fournisseur et devant être disponible chez l’Acheteur sous au moins un second format de fichier propre à l’Acheteur, on met en oeuvre les étapes suivantes : on extrait d’un fichier de catalogue électronique Fournisseur des données correspondant à des attributs définis par celui-ci comme représentatif des informations de son catalogue et on stocke ces données dans une base de données Fournisseur, on transfert tout ou partie des données stockées dans ladite base vers une base de données Acheteur, en fonction de règles de correspondance définies entre des attributs de la base de données Fournisseur et des attributs de la base de données Acheteur, on traite les données ainsi transférées dans la base de données Acheteur et stockées dans celle-ci pour reconstituer un fichier de catalogue Acheteur.

Description

ECHANGE DE CATALOGUES ELECTRONIQUES ENTRE ENTREPRISES
DOMAINE TECHNIQUE GENERAL ET ART ANTERIEUR
La présente invention concerne les relations entre entreprises sur
Internet, et plus particulièrement les échanges de catalogues électroniques dans le cadre d'une relation Acheteur - Fournisseur entreprises.
Dans le cadre des relations achats-ventes entre entreprises, de plus en plus d'acteurs souhaitent disposer de catalogues Fournisseurs électroniques.
On peut citer à titre d'exemple :
- l'entreprise qui dispose d'un système centralisé d'achats en ligne ('"e- procurement" selon la terminologie anglo-saxonne) et qui veut disposer des catalogues électroniques de ses Fournisseurs pour les mettre en ligne sur son système,
- la place de marché ou le site de vente en ligne qui souhaite mettre en ligne les catalogues des Fournisseurs.
A cet effet, l'invention propose une technique permettant d'adapter les informations disponibles chez les Fournisseurs aux exigences particulières des clients (que l'on nommera dans la suite de ce document Acheteurs).
A ce jour, il n'existe pas à la connaissance des inventeurs d'outils véritablement satisfaisants.
En particulier, on connaît des outils propriétaires propres à chaque Acheteur (ex. canal d'entrée d'un outil d'achat en ligne), mais ceux-ci requièrent un format d'entrée très spécifique. Pour adresser ce type d'outil, chaque Fournisseur doit donc retravailler ses données pour essayer de les mettre sous la forme requise. Il doit répéter ce travail spécifique pour chacun des Acheteurs équipé d'un tel type d'outil ; ce travail est d'autant plus ardu et non réutilisable que chaque Acheteur ne possède pas forcément le même outil voire simplement n'a pas instancié le même format d'entrée et les mêmes règles de mises à jour (même si l'outil est identique). On connaît également des boîtes à outils plus ou moins génériques (ex. Atomic Catalog de Collego racheté par MRO) ; toutefois celles-ci nécessitent elles aussi au cas par cas des adaptations importantes, des simulations manuelles de fonctionnalités, voire des traitements externes au logiciel.
Les procédés actuellement utilisés sont donc très lourds à mettre en œuvre et peu ou pas mutualisables.
PRESENTATION DE L'INVENTION.
La technique proposée par l'invention permet des mises à jour nettement plus légères et rapides, et limitant, ce faisant, les risques d'erreur.
Tant les Fournisseurs que les Acheteurs peuvent ainsi se concentrer sur la vente et l'achat.
Notamment, la solution proposée par l'invention permet de répondre au besoin des Acheteurs/Fournisseurs, en :
- limitant le travail à fournir notamment en le mutualisant et en l'automatisant, - faisant effectuer le travail au plus près de la source d'information,
- offrant un certain nombre de fonctionnalités ainsi qu'un flux de travail permettant de faciliter le travail de contrôle, de validation et d'échange des Fournisseurs et des Acheteurs.
A cet effet, l'invention propose un procédé d'échange de catalogues électroniques entre au moins un Fournisseur et au moins un Acheteur, caractérisé en ce que, un catalogue électronique étant disponible chez le Fournisseur sous au moins un premier format de fichier propre au Fournisseur et devant être disponible chez l'Acheteur sous au moins un second format de fichier propre à l'Acheteur, on met en œuvre les étapes suivantes :
- on extrait d'un fichier de catalogue électronique Fournisseur des données correspondant à des attributs définis par celui-ci comme représentatif des informations de son catalogue et on stocke ces données dans une base de données Fournisseur,
- on transfert tout ou partie des données stockées dans ladite base vers une base de données Acheteur, en fonction de règles de correspondance définies entre des attributs de la base de données Fournisseur et des attributs de la base de données Acheteur,
- on traite les données ainsi transférées dans la base de données Acheteur et stockées dans celle-ci pour reconstituer un fichier de catalogue Acheteur.
De cette façon, on dispose ainsi d'un traitement automatisé des échanges de catalogues électroniques entre sociétés qui permet à chaque partenaire de gérer ses données dans le format qu'il est habitué à manipuler et de mutualiser les données pour permettre une réutilisation facile.
La méthode proposée évite ce faisant les mises en œuvres actuelles qui sont lourdes et sources d'erreurs. Cette méthode peut être utilisée par les entreprises qui souhaitent mettre en place un système d'échange de catalogues électroniques dans le cadre d'une relation Fournisseurs-Acheteurs.
Avantageusement, notamment, l'extraction de données à partir d'un fichier Fournisseur et/ou la reconstitution d'un fichier Acheteur à partir de données stockées dans une base de données Acheteur est (sont) mise(s) en œuvre au niveau d'un ou plusieurs serveurs avec lesquels le Fournisseur et/ou l'Acheteur sont aptes à communiquer via une interface internet pour charger et/ou décharger des fichiers de données. De préférence également, pour initier sa base de données, le
Fournisseur définit pour celle-ci des attributs qui sont communs à tous les Acheteurs et des attributs qui sont spécifiques à chacun des Acheteurs.
Selon un mode de mise en œuvre avantageux, pour initialiser sa base de données, un Fournisseur définit des codes et significations des devises et unités qu'il utilise ; pour initialiser sa base de données, un Acheteur définit des codes et significations des devises et unités qu'il souhaite utiliser ; et pour initialiser une relation Fournisseur/Acheteur, on définit des règles de correspondance entre les codes et significations définis pour la base de données Fournisseur et les codes et significations définis pour la base de données Acheteur.
Pour mettre à jour un catalogue électronique, on extrait d'un nouveau fichier catalogue des données à stocker dans la base de données Fournisseur et/ou on charge dans la base de données Fournisseur uniquement les données modifiées et, avantageusement, on met en œuvre ensuite sur les données ainsi extraites ou chargées, ainsi que sur les données stockées dans la base de données Fournisseur une analyse différentielle pour mettre en évidence pour le Fournisseur les données mises à jour.
A la suite de cette mise en évidence, le Fournisseur a notamment la possibilité de ne pas conserver les données mises à jour et de revenir aux données préalables.
De préférence, lors d'une mise à jour, l'acheteur visualise les données modifiées et valide celles-ci, l'information relativement à la validation par l'Acheteur étant retransmise côté Fournisseur.
Avantageusement également, à des fins d'exploitation interne, le Fournisseur récupère sur des canaux dédiés à cet effet des données stockées dans la base de données Fournisseur. En outre, on recopie de préférence pour l'Acheteur, en les renommant, des fichiers qui constituent des pièces jointes qui sont transmises par le Fournisseur.
Avantageusement encore, le Fournisseur définit des attributs de catégorisation de produits et en ce qu'on définit des liens entre ces attributs de catégorie et des catégories cibles de l'Acheteur, de façon à ce que chaque catégorie de l'Acheteur soit remplit avec les produits devant se trouver dans cette catégorie cible.
L'invention propose également un système pour la mise en œuvre d'échanges de catalogues électroniques entre au moins un Fournisseur et au moins un Acheteur, caractérisé en ce que, un catalogue électronique étant disponible chez le Fournisseur sous un premier format de fichier propre au Fournisseur et devant être disponible chez l'Acheteur sous un second format de fichier propre à l'Acheteur, il comporte : - une base de données côté Fournisseur, dans laquelle sont stockées des données correspondant à des attributs choisis par le Fournisseur comme caractérisant les informations de son catalogue électronique, - des moyens pour extraire d'un fichier de catalogue électronique
Fournisseur des données correspondant à ces attributs,
- une base de données côté Acheteur dans laquelle sont stockées des données correspondant à des attributs définis par l'Acheteur comme correspondant aux informations dont il souhaite disposer dans son catalogue électronique,
- des moyens pour reconstituer à partir de données stockées dans ladite base un fichier de catalogue électronique Acheteur,
- des moyens pour transférer des données de la base de données Fournisseur à la base de données Acheteur. Dans un tel système, les moyens de traitement côté Fournisseur et/ou Acheteur comportent des serveurs avec lesquels le Fournisseur et/ou l'Acheteur sont aptes à communiquer via une interface internet pour charger/décharger des fichiers.
Comme on le comprend plus particulièrement à la lecture de la description qui suit, la méthode proposée permet
- demander aux Fournisseurs les données sur leurs produits dans un format et selon une organisation qui leur sont propres et auxquels ils sont donc habitués, et ce, de façon unique même si ce Fournisseur adresse plusieurs Acheteurs, - de faire traiter le maximum des données des Fournisseurs par ces derniers (saisie à la source) de manière à fiabiliser l'information,
- d'offrir tant aux Fournisseurs qu'aux Acheteurs un certain nombre de vues et de rapports ou fichiers électroniques sur leurs données afin de faciliter leur travail de contrôle et de validation des données, - de séparer les informations entre les différents Fournisseurs et Acheteurs afin d'interdire toute visualisation de données appartenant potentiellement à des sociétés concurrentes, - de réaliser une analyse différentielle sur les catalogues transmis par les Fournisseurs de manière à ce qu'ils puissent transmettre leurs données, au choix, de façon complète ou partielle,
- de définir des règles de conversion de format de fichier, de noms d'attributs, de catégories, de nom de fichiers et, une fois ces règles mises en place, d'automatiser les mises à jour ultérieures et les rendre reproductibles,
- d'avoir accès aux données via un simple navigateur web,
- proposer un identifiant unique interne pour chaque produit des différents Fournisseurs sur lequel on puisse se baser pour les mises à jour des données,
- de proposer un système de circuit de validation interne au Fournisseur, inter(ne à l'Acheteur, et entre Fournisseurs et Acheteurs (workflow) avec historisation, - de proposer à l'Acheteur un système de rechargement complet de catalogue.
PRESENTATION DES FIGURES
La description qui suit est purement illustrative et non limitative et doit être lue en regard des dessins annexés sur lesquels les figures 1 et 2 illustrent le système utilisé côté Fournisseur et côté Acheteur.
DESCRIPTION DETAILLEE.
1. Définitions.
Les définitions suivantes sont utilisées dans tout le présent texte :
• Fournisseur : on entend par Fournisseur une société qui souhaite mettre à la disposition d'une ou plusieurs autres sociétés (les Acheteurs) des données sur des biens ou services qu'elle propose. Certaines de ces données sont communes à tous les Acheteurs, d'autres sont spécifiques à certains Acheteurs. Les données mises à disposition par un Fournisseur sont exprimées selon un format, une classification, etc. spécifiques à ce Fournisseur.
" Acheteur : on entend par Acheteur une société qui souhaite obtenir des données sur des biens ou services proposés par une ou plusieurs autres sociétés (les Fournisseurs). Les données qu'un Acheteur souhaite obtenir doivent être obtenues en respectant un format, une classification, un ordre, etc. spécifiques à cet Acheteur ; il peut par exemple vouloir obtenir les produits agrégés au sein d'une même classification, et non pas triés par Fournisseur.
• Catalogue général Fournisseur : on entend par catalogue général Fournisseur l'ensemble des produits proposés par un Fournisseur et qui peuvent être retenus par un Acheteur donné. Un catalogue général Fournisseur est composé des données communes à tous les Acheteurs, données qui permettent de caractériser le produit.
• Catalogue spécifique Fournisseur : on entend par catalogue spécifique Fournisseur un ensemble de produits (d'un Fournisseur) retenus par un Acheteur donné. Un catalogue spécifique Fournisseur est composé des données communes complétées éventuellement par des données spécifiques à cet Acheteur. Un catalogue spécifique Fournisseur contient un sous-ensemble des références produit présentes dans le catalogue général Fournisseur.
• Pièce jointe : fichier électronique généralement de format binaire, lié à un ou plusieurs produits particuliers, venant compléter la description du (des) produit(s), et ne pouvant pas être facilement transmis sous une forme textuelle (ex. fichier image du produit, fichier de description détaillés du produit au format Adobe Acrobat).
La technique proposée par l'invention se décompose en quatre grandes parties : - initialisation d'un Fournisseur,
- initialisation d'un Acheteur,
- initialisation d'une relation Fournisseur-Acheteur,
- gestion des mises à jour des catalogues de produits.
2. Initialisation d'un Fournisseur.
Lorsqu'un Fournisseur souhaite adresser tout ou partie de son catalogue de produits à un ou plusieurs Acheteurs, il doit tout d'abord passer par une étape d'initialisation. Les opérations effectuées lors de cette étape consistent à renseigner les informations suivantes :
• choisir la forme sous laquelle il va transmettre les données de son catalogues. Il est proposé ici au Fournisseur de conserver ses habitudes : il indique notamment le nom et la nature des attributs qu'il peut mettre à disposition (ex. si pour lui la « description » de ses produits correspond à l'attribut « libellé » et non pas « description courte », il est libre de nommer l'attribut de cette manière : on n'impose pas de nom aux attributs), les différents codes et signification des devises et des unités qu'il a l'habitude d'utiliser, le format (ex. fichier Excel, fichier XML, fichier de base de données, ...) de fichier qu'il utilisera pour transmettre son catalogue de produits,
• indiquer, parmi les attributs précisés :
o celui (ou ceux) qui permet(tent) d'identifier de façon unique un produit,
o ceux qui sont communs à tous ses Acheteurs (ex. référence fabricant du produit, nom du produit, nom du fichier électronique donnant une image du produit, prix public du produit, unité de vente correspondant au prix public, délai moyen de mise à disposition) et ceux qui sont spécifiques à chacun de ses Acheteurs (ex. prix accordé à cet Acheteur, unité spécifique de vente correspondante), o celui (ou ceux) qui permet(tent) de définir de façon concise et non ambiguë chaque produit (ce(s) attribut(s) sera(ont) utilisé(s) pour accéder aux produits dans l'interface graphique présentant les produits sous une forme arborescente, par exemple un attribut représentant une description courte du produit peut être choisi ici),
o celui (ou ceux) qui représente(nt) un (des) niveau(x) hiérarchique(s) de catégorisation de produits (l'interface graphique permet d'afficher les produits répartis dans des catégories et sous-catégories sous une forme arborescente à n niveaux : ce qui est demandé ici est d'indiquer que sous tel nom d'attribut on trouvera tel niveau de telle catégorisation),
o celui qui contient la date de suppression éventuelle d'un produit du catalogue général du Fournisseur (le catalogue général d'un Fournisseur contient tous les produits que ce Fournisseur commercialise. Ce catalogue général est composé des données communes à tous les Acheteurs. Chacun de ces produits est ensuite destiné à tel ou tel Acheteur (données communes complétées alors par les données spécifiques)),
o ceux qui contiennent la date de suppression éventuelle d'un produit du catalogue dédié à chaque Acheteur de ce Fournisseur,
B préciser un ensemble d'informations complémentaires permettant les échanges de données, la déclaration de droit d'accès, etc. (ex. fiche signalétique de la société, des personnes qui vont avoir accès à l'application ou simplement jouer un rôle dans l'échange de données),
préciser le format attendu si le Fournisseur souhaite obtenir son catalogue sous une forme électronique (ex. le Fournisseur peut réaliser des saisies manuelles et vouloir obtenir un fichier électronique pour resynchroniser ses données en interne).
Les renseignements de ces différentes informations conduit à la création d'un espace dédié à ce Fournisseur et configuré selon les informations transmises et lui permettant de se connecter à l'application via un navigateur web (logins - mots de passe) et de faire des opérations d'E/S de données via de la saisie ou des chargements/déchargements de fichiers.
Le cas échéant, les types de vues et de rapports générés peuvent aussi être personnalisés selon les besoins du Fournisseur. On notera en particulier que lorsqu'un Fournisseur déjà déclaré souhaite adresser un autre Acheteur, seules les informations permettant d'initialiser ce nouvel échange doivent être transmises.
Enfin, pour ce qui concerne le cas spécial des pièces jointes, un espace de stockage est créé. Cet espace viendra accueillir les fichiers électroniques matérialisant ces pièces jointes, fichiers transmis par le
Fournisseur (ex. fichier image du produit, fichier de description détaillée du produit Adobe Acrobat).
3. Initialisation d'un Acheteur. Lorsqu'un Acheteur souhaite obtenir des données relatives à des produits commercialisés par un ou plusieurs Fournisseurs, il doit tout d'abord passer par une étape d'initialisation. Les opérations effectuées lors de cette étape consistent à renseigner les informations suivantes :
- choisir la forme sous laquelle il souhaite obtenir les données : il indique notamment le nom et la nature des attributs qu'il souhaite obtenir
(éventuellement leur valeur si celle-ci est constante), les différents codes et signification des devises et des unités qu'il souhaite manipuler, la liste exhaustive des classifications qu'il souhaite utiliser pour ventiler les produits qu'il souhaite obtenir, le format (ex. fichier Excel, fichier XML, fichier de base de données, ...) de fichier qu'il souhaite obtenir,
- préciser les règles éventuelles de nommage des pièces jointes (ex. photo de produit), si l'Acheteur souhaite leur donner un nom particulier, - préciser un ensemble d'informations complémentaires permettant les échanges de données, la déclaration de droits d'accès, etc. (ex. fiche signalétique de la société, des personnes qui vont avoir accès à l'application ou simplement jouer un rôle dans l'échange de données). La fourniture de ces différentes informations conduit à la création d'un espace dédié à cet Acheteur, espace configuré selon les informations transmises et lui permettant de se connecter à l'application via un navigateur web (logins - mots de passe) et de faire des opérations d'E/S de données via de la saisie ou des chargements/déchargements de fichiers. Notamment le canal de sortie qui permet à l'Acheteur d'obtenir le fichier des produits est paramétré afin de respecter les exigences de format précisées par l'Acheteur (ce paramétrage s'effectue actuellement via l'écriture d'une feuille de style XSL améliorée).
Le cas échéant, les types de vues et de rapports générés peuvent aussi être personnalisés selon les besoins de l'Acheteur.
Concernant le cas spécial des pièces jointes, un espace de stockage est réservé et un canal de sortie est paramétré : il s'agit d'un canal spécifique qui permet d'aller rechercher les pièces jointes source (transmises par le Fournisseur), de les recopier, en les renommant, dans l'espace de stockage réservé à l'Acheteur.
4. Initialisation d'une relation Fournisseur-Acheteur.
Une fois un Fournisseur et un Acheteur initialisés, il est nécessaire de mettre en place la relation éventuelle qui doit exister entre eux. Pour ce faire les informations suivantes sont nécessaires et les liens suivants doivent être mis en place :
- liens entre les attributs du Fournisseur et ceux de l'Acheteur (ex. pour chaque produit considéré, la donnée présente dans l'attribut Fournisseur « Libellé » devra se retrouver dans l'attribut Acheteur « Description »), - pour les attributs correspondant aux devises et aux unités, liens entre les codes Fournisseur et les codes Acheteur (ex. pour chaque produit considéré, le code devise « Franc » présent dans l'attribut Fournisseur « Devise » devra être transformée en code devise « FF » présent dans l'attribut Acheteur « CURRENCY »),
- pour chaque produit Fournisseur retenu par l'Acheteur, ajout d'un attribut spécifique contenant la classification cible choisie parmi les catégories disponibles chez l'Acheteur ; généralement, cette donnée sera mise en place par le Fournisseur à partir d'une liste de catégories possibles transmises par l'Acheteur. Cet attribut sera ajouté lors des mises à jour de catalogues, pour chaque nouveau produit destiné à un Acheteur donné, - liens entre les catégories cibles et l'attribut spécifique contenant la catégorie cible (de manière à ce que chaque catégorie de l'Acheteur soit remplie avec les produits devant se trouver dans cette catégorie cible),
- ajout d'attributs spécifiques à l'Acheteur et comportant une valeur donnée. L'ensemble de ces liens permet l'automatisation du passage de la
« vision Fournisseur » de certains produits d'un Fournisseur vers la « vision Acheteur » de ces mêmes produits.
5. Gestion des mises à jour des catalogues de produits. Une fois les Fournisseurs, les Acheteurs et les liens entre eux initialises, il est possible de gérer les différents catalogues et leurs mises à jour. Cette gestion se présente sous la forme de différentes étapes, à savoir :
- étape de test/validation Fournisseur - étape de transmission aux Acheteurs
- étape de test/validation Acheteur
- étape de retour d'information aux Fournisseurs
Nota : des procédures de sauvegarde déclenchées après les différentes étapes de validation permettent d'historiser les étapes et de pouvoir revenir également à des états antérieurs en cas de besoin.
5.1. Etape de test/validation Fournisseur. Le Fournisseur dispose de la version de son catalogue général ainsi que de la dernière version de chaque catalogue spécifique dédié à chacun de ses Acheteurs.
Nota : dans le cas d'un nouveau catalogue, les différents catalogues sont bien sûr vierges.
Dans un premier temps, il charge son catalogue général : il a la possibilité de charger le catalogue complet valide à cet instant donné, ou de charger uniquement les données qui ont été modifiées. Ce chargement a lieu via le canal qui a été paramétré lors de la phase d'initialisation, ce chargement peut aussi se faire ou être complété par la saisie de données sur l'interface web.
Dans un deuxième temps, il charge les données complémentaires correspondant à son (ses) catalogue(s) spécifique(s) destiné(s) à l'(aux) Acheteur(s). Pour le chargement il dispose des mêmes fonctionnalités que celles mentionnées dans le cas du catalogue général. Nota : les catalogues spécifiques sont formés en allant rechercher les données du catalogue général (unique) déjà présent et en complétant chaque référence produit avec les données spécifiques.
Lorsque des informations ont été chargées, le Fournisseur lance des analyses différentielles des modifications effectuées par rapport aux dernières versions des catalogues : les références des produits dont les données ont été changées sont extraites et une indication de la modification (Ajout, Modification, Suppression) est automatiquement ajoutée. S'il le souhaite, un rapport plus complet peut aussi être consulté de manière à faciliter son travail de validation : pour chaque référence produit, lorsque des données ont été modifiées, les données modifiées sont mises en évidence et l'ancienne donnée est rappelée. Il est également possible par exemple d'indiquer dans ce rapport que tel prix a été augmenté ou baissé de telle valeur (si la donnée prix n'est pas cryptée). Une analyse différentielle est disponible pour les données communes à tous les Acheteurs, et une autre analyse différentielle pour chaque catalogue spécifique Acheteur. Le Fournisseur vérifie alors les données. Il dispose, pour ce faire, de différentes vues lui permettant de visualiser ses données dans sa propre taxonomie ou dans la taxonomie cible d'un Acheteur donné. En effet, suite au paramétrage des règles de mapping de taxonomie, les données sont automatiquement converties dans la taxonomie souhaitée par chaque Acheteur.
Si certaines de ces données sont incorrectes, il peut recommencer son (ses) chargement(s) (procédure de rollback) ou modifier les données via l'interface web, puis relancer l'(les) analyse(s) différentielle(s). Le Fournisseur dispose aussi, le cas échéant, de canaux d'export lui permettant de récupérer les données présentes dans son espace à des fins d'exploitation interne (fichier électronique lui permettant de se synchroniser en cas de saisie en ligne, par exemple).
Lorsque les données sont correctes, il valide l'étape pour le catalogue général (le cas échéant) et pour chaque catalogue spécifique (le cas échéant).
Tout au long de cette étape, les règles suivantes sont vérifiées :
- les mises à jour ayant trait aux données communes à tous les Acheteurs sont ajoutées à la prochaine mise à jour du catalogue spécifique de chaque Acheteur ; ces mises à jour ne seront pas à valider par les Acheteurs : elles sont seulement transmises aux Acheteurs pour mise en ligne.
- un chargement ne peut pas se faire sur un catalogue spécifique si la mise à jour précédente n'a pas encore été validée par l'Acheteur correspondant. Nota : selon la taille et les besoins d'un Fournisseur, il est possible de mettre en place un circuit de validation (workfiow) interne au Fournisseur entre les différents utilisateurs du Fournisseur qui auront été paramétrés lors de l'étape d'initialisation, cela est utile pour les gros Fournisseurs qui doivent faire valider par exemple leur catalogue général par un service technique, et les prix accordés aux Acheteurs par un service commercial. 5.2. Etape de transmission aux Acheteurs. Les différentes mises à jour validées par les Fournisseurs sont regroupées par lots, par Acheteur et sont mises à disposition de chaque Acheteur concerné, au sein de son propre espace de données.
5.3. Etape de test/validation Acheteur.
Selon les informations qui ont été paramétrées lors de l'étape d'initialisation d'Acheteur, les lots de données transmises par les Fournisseurs sont agrégées au sein d'un même catalogue ou restent séparés par Fournisseur.
L'Acheteur peut alors accéder à une ou plusieurs vues lui permettant de valider ou de refuser les mises à jour proposées. Ces mises à jour sont décrites au minimum via un état (ajout, modification, suppression), et, le cas échéant, avec un rapport présentant plus précisément les différences.
Il lui est aussi transmis un ou plusieurs rapports de validation lui permettant de disposer de documents électroniques rappelant les modifications proposées, rapports qu'il peut compléter en local, puis charger dans sa zone de validation pour mise à jour de l'état de validation. Par ailleurs, au fur et à mesure de sa validation, il dispose d'un autre canal lui permettant d'obtenir la version électronique des données validées, au format requis, pour mise en production chez lui.
Enfin, il dispose aussi d'un autre canal lui permettant de lancer la recopie/renommage éventuel des pièces jointes : il peut alors avoir accès à ces fichiers électroniques libellés en accord avec les noms transmis dans le catalogue électronique. Généralement il les télécharge afin de les importer dans son outil.
Après la validation complète de chaque mise à jour, le(s) catalogue(s) complet(s) de l'Acheteur présent(s) dans l'espace de l'Acheteur, est (sont) mis à jour avec tous les produits acceptés. Cela, couplé à un processus de sauvegardes, permet, le cas échéant, de générer une version complète du (des) catalogue(s) pour rechargement sur l'outil de l'Acheteur, comme cela est nécessaire à certains moments (ex. changement de version de l'outil).
5.4. Etape de retour d'information aux Fournisseurs.
La validation par un Acheteur donné est transmise dans l'espace de chaque Fournisseur concerné de manière à le tenir informé en temps réel des validations effectuées par l'Acheteur, ce retour d'information est présenté au Fournisseur sous la forme d'une vue regroupant les produits acceptés, refusés ou en cours de validation, avec une zone de commentaires dans laquelle l'Acheteur peut donner la raison de son refus, notamment. Cela permet au Fournisseur de commencer, le cas échéant, à vérifier les données relatives à un produit refusé, par exemple.
Une fois que toute la mise à jour a été validée par un Acheteur donné, la version en cours du catalogue spécifique est mise à jour en fonction des données réellement acceptées par l'Acheteur, et le canal de chargement relatif au catalogue spécifique de cet Acheteur est à nouveau ouvert pour mise à jour par le Fournisseur.

Claims

REVENDICATIONS
1. Procédé d'échange de catalogues électroniques entre au moins un Fournisseur et au moins un Acheteur, caractérisé en ce que, un catalogue électronique étant disponible chez le Fournisseur sous au moins un premier format de fichier propre au Fournisseur et devant être disponible chez l'Acheteur sous au moins un second format de fichier propre à l'Acheteur, on met en œuvre les étapes suivantes : - on extrait d'un fichier de catalogue électronique Fournisseur des données correspondant à des attributs définis par celui-ci comme représentatif des informations de son catalogue et on stocke ces données dans une base de données Fournisseur,
- on transfert tout ou partie des données stockées dans ladite base vers une base de données Acheteur, en fonction de règles de correspondance définies entre des attributs de la base de données Fournisseur et des attributs de la base de données Acheteur,
- on traite les données ainsi transférées dans la base de données Acheteur et stockées dans celle-ci pour reconstituer un fichier de catalogue Acheteur.
2. Procédé selon la revendication 1 , caractérisé en ce que l'extraction de données à partir d'un fichier Fournisseur et/ou la reconstitution d'un fichier Acheteur à partir de données stockées dans une base de données Acheteur est (sont) mise(s) en œuvre au niveau d'un ou plusieurs serveurs avec lesquels le Fournisseur et/ou l'Acheteur sont aptes à communiquer via une interface internet pour charger et/ou décharger des fichiers de données.
3. Procédé selon l'une des revendications 1 ou 2, caractérisé en ce que pour initier sa base de données, le Fournisseur définit pour celle-ci des attributs qui sont communs à tous les Acheteurs et des attributs qui sont spécifiques à chacun des Acheteurs.
4. Procédé selon l'une des revendications précédentes, caractérisé en ce que pour initialiser sa base de données, un Fournisseur définit des codes et significations des devises et unités qu'il utilise, en ce que pour initialiser sa base de données, un Acheteur définit des codes et significations des devises et unités qu'il souhaite utiliser et en ce que pour initialiser une relation Fournisseur/Acheteur, on définit des règles de correspondance entre les codes et significations définis pour la base de données Fournisseur et les codes et significations définis pour la base de données Acheteur.
5. Procédé selon l'une des revendications précédentes, caractérisé en ce que pour mettre à jour un catalogue électronique, on extrait d'un nouveau fichier catalogue des données à stocker dans la base de données Fournisseur et/ou on charge dans la base de données Fournisseur uniquement les données modifiées et en ce que on met en œuvre ensuite sur les données ainsi extraites ou chargées, ainsi que sur les données stockées dans la base de données Fournisseur une analyse différentielle pour mettre en évidence pour le Fournisseur les données mises à jour.
6. Procédé selon la revendication 5, caractérisé en ce qu'à la suite de cette mise en évidence, le Fournisseur a la possibilité de ne pas conserver les données mises à jour et de revenir aux données préalables.
7. Procédé selon l'une des revendications 5 ou 6, caractérisé en ce que lors d'une mise à jour, l'acheteur visualise les données modifiées et valide celles-ci, l'information relativement à la validation par l'Acheteur étant retransmise côté Fournisseur.
8. Procédé selon l'une des revendications précédentes, caractérisé en ce que, à des fins d'exploitation interne, le Fournisseur récupère sur des canaux dédiés à cet effet des données stockées dans la base de données Fournisseur.
9. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'on recopie pour l'Acheteur, en les renommant, des fichiers qui constituent des pièces jointes qui sont transmises par le Fournisseur.
10. Procédé selon l'une des revendications précédentes, caractérisé en ce que le Fournisseur définit des attributs de catégorisation de produits et en ce qu'on définit des liens entre ces attributs de catégorie et des catégories cibles de l'Acheteur, de façon à ce que chaque catégorie de l'Acheteur soit remplit avec les produits devant se trouver dans cette catégorie cible.
11. Système pour la mise en œuvre d'échanges de catalogues électroniques entre au moins un Fournisseur et au moins un Acheteur, caractérisé en ce que, un catalogue électronique étant disponible chez le Fournisseur sous un premier format de fichier propre au Fournisseur et devant être disponible chez l'Acheteur sous un second format de fichier propre à l'Acheteur, il comporte :
- une base de données côté Fournisseur, dans laquelle sont stockées des données correspondant à des attributs choisis par le
Fournisseur comme caractérisant les informations de son catalogue électronique,
- des moyens pour extraire d'un fichier de catalogue électronique Fournisseur des données correspondant à ces attributs, - une base de données côté Acheteur dans laquelle sont stockées des données correspondant à des attributs définis par l'Acheteur comme correspondant aux informations dont il souhaite disposer dans son catalogue électronique,
- des moyens pour reconstituer à partir de données stockées dans ladite base un fichier de catalogue électronique Acheteur,
- des moyens pour transférer des données de la base de données Fournisseur à la base de données Acheteur.
12. Système selon la revendication 11 , caractérisé en ce que les moyens de traitement côté Fournisseur et/ou Acheteur comportent des serveurs avec lesquels le Fournisseur et/ou l'Acheteur sont aptes à communiquer via une interface internet pour charger/décharger des fichiers.
PCT/FR2002/004521 2001-12-21 2002-12-23 Echange de catalogues electroniques entre entreprises WO2003054738A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2002364868A AU2002364868A1 (en) 2001-12-21 2002-12-23 Electronic catalogue exchange between business organizations

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0116714A FR2834161B1 (fr) 2001-12-21 2001-12-21 Echange de catalogues electroniques entre entreprises
FR01/16714 2001-12-21

Publications (1)

Publication Number Publication Date
WO2003054738A1 true WO2003054738A1 (fr) 2003-07-03

Family

ID=8870872

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2002/004521 WO2003054738A1 (fr) 2001-12-21 2002-12-23 Echange de catalogues electroniques entre entreprises

Country Status (3)

Country Link
AU (1) AU2002364868A1 (fr)
FR (1) FR2834161B1 (fr)
WO (1) WO2003054738A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10839389B1 (en) * 2015-09-29 2020-11-17 BuyerQuest, Inc. System and method for updating and managing hosted catalogs in a procurement system

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001077885A1 (fr) * 2000-04-10 2001-10-18 Innovit Pty Ltd Catalogue electronique

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001077885A1 (fr) * 2000-04-10 2001-10-18 Innovit Pty Ltd Catalogue electronique

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
CHOY D M ET AL: "A distributed catalog for heterogeneous distributed database resources", PARALLEL AND DISTRIBUTED INFORMATION SYSTEMS, 1991., PROCEEDINGS OF THE FIRST INTERNATIONAL CONFERENCE ON MIAMI BEACH, FL, USA 4-6 DEC. 1991, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 4 December 1991 (1991-12-04), pages 236 - 244, XP010025430, ISBN: 0-8186-2295-4 *
DARUWALA A ET AL: "THE CONTEXT INTERCHANGE NETWORK PROTOTYPE", DATABASE APPLICATIONS SEMANTICS. PROCEEDINGS OF THE IFIP WG 2.6 WORKING CONFERENCE ON DATABASE APPLICATIONS SEMANTICS, XX, XX, 30 May 1995 (1995-05-30), pages 65 - 92, XP002041262 *
G. PIERRA ET AL: "Exchange of component data: The PLIB (ISO 13584) model, standard and tools.", PROCEEDINGS OF THE CALS EUROPE'98 CONFERENCE, 16 September 1998 (1998-09-16) - 18 September 1998 (1998-09-18), pages 160 - 176, XP002213455, Retrieved from the Internet <URL:http://www.plib.ensma.fr/plib/upload/CALSEUROPE_master.pdf> [retrieved on 20020910] *
LEE S-G ET AL: "Digital catalog library: a shared repository of online catalogs for electronic commerce", ADVANCE ISSUES OF E-COMMERCE AND WEB-BASED INFORMATION SYSTEMS, WECWIS, 1999. INTERNATIONAL CONFERENCE ON SANTA CLARA, CA, USA 8-9 APRIL 1999, PISCATAWAY, NJ, USA,IEEE, US, 8 April 1999 (1999-04-08), pages 84 - 86, XP010348777, ISBN: 0-7695-0334-9 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10839389B1 (en) * 2015-09-29 2020-11-17 BuyerQuest, Inc. System and method for updating and managing hosted catalogs in a procurement system
US20210065181A1 (en) * 2015-09-29 2021-03-04 BuyerQuest, Inc. System and method for updating and managing hosted catalogs in a procurement system
US11915239B2 (en) 2015-09-29 2024-02-27 BuyerQuest, Inc. System and method for updating and managing hosted catalogs in a procurement system

Also Published As

Publication number Publication date
FR2834161B1 (fr) 2009-12-25
AU2002364868A1 (en) 2003-07-09
FR2834161A1 (fr) 2003-06-27

Similar Documents

Publication Publication Date Title
EP0793171B1 (fr) Système de configuration de logiciels préconfigurés sur des systèmes ouverts en réseau dans un environnement distribué et procédé mis en oeuvre par un tel système
FR2888018A1 (fr) Procede et systeme de realisation d&#39;une base de donnees virtuelle a partir de sources de donnees presentant des schemas heterogenes
FR2738649A1 (fr) Procede de conversion d&#39;objets d&#39;un espace plat a un espace structure en classes
EP1739551A1 (fr) Procédé de traitement de données compatible avec un formalisme de modélisation d&#39;objets
EP2297681A1 (fr) Procede de gestion de donnees pour atelier oriente service collaboratif
WO2009147311A1 (fr) Procede de gestion de processus dans un atelier oriente service collaboratif
WO2003054738A1 (fr) Echange de catalogues electroniques entre entreprises
FR2931272A1 (fr) Procede d&#39;import export de donnees d&#39;une base de donnees
EP1763790A1 (fr) Procede et dispositif de recherche avec conservation personnalisee des resultats
BE1023607B1 (fr) Methode et systeme de collecte de documents numeriques a partir d’une pluralite de source
EP1280074A1 (fr) Utilisation d&#39;hyperliens dans un programme d&#39;une application d&#39;automatisme et station de programmation d&#39;une telle application
BE1024848B1 (fr) Méthode et système de contrôle de documents numériques
EP0685802A1 (fr) Système d&#39;information pour la consultation d&#39;informations centralisées en provenance d&#39;applications opérationnelles
EP1049971B1 (fr) Procede de commande d&#39;une fonction executable par des commandes specifiques a des logiciels differents
FR2778807A1 (fr) Procedure de depot de texte en ligne
EP1811373A1 (fr) Procédé de composition automatique de services web, produit de programme d&#39;ordinateur et système informatique de mise en oeuvre de ce procédé
WO2022096602A1 (fr) Procédé de mise à jour automatique de données d&#39;un utilisateur
FR3109829A1 (fr) Procédé de programmation informatique de n’importe quel lien entre deux entités représentant chacune sa liste d’entités et logiciel de programmation informatique mettant en œuvre ce procédé.
Moreira Discovering Meta-models of Low-code Applications
FR2943155A1 (fr) Procede et systeme collaboratif de modifications d&#39;applications numeriques en reseau
FR2822265A1 (fr) Outil d&#39;aide a la redaction de contrats
FR2835335A1 (fr) Procede et dispositif d&#39;edition, de conservation, de diffusion de documents
Rossa bi Bulletin Informatique, Janvier 2001= Information Bulletin, January 2001
FR2746532A1 (fr) Systeme de developpement et d&#39;execution d&#39;applications multimedias, procedes de developpement et de mise a jour de donnees correspondants
WO2012149977A1 (fr) Procede et systeme correspondant de generation d&#39;une application logicielle manipulant des donnees structurees.

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SC SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP