JP2007011860A - 電子商取引システム - Google Patents

Abstract

【課題】発注者に余計な労力やコストを課したり、発注者側の既存システムに大幅な改造を施したりすることなく導入可能な電子商取引システムを提供する。
【解決手段】電子商取引システムは、発注者側の発注システムに組み込まれる発注モジュールと、受注者側の受注システムとを備える。発注モジュールは、発注システムに入力された発注情報を読み込み、その発注情報と発注者識別子を含む発注データを生成し、発注データを受注システムに送信する。受注システムは、発注者毎に異なる個々の発注データの形式に対応した、複数種類の変換プログラムを格納する記憶手段と、受信した発注データの発注者識別子に基づいて、その発注データの形式に対応した変換プログラムを記憶手段から選択する変換プログラム選択手段と、選択された変換プログラムを用いて、発注データの発注情報を電子商取引システムにて受注処理可能な形式に変換する形式変換手段と、変換後の発注情報により受注処理を実行する受注手段と、を有する。
【選択図】図１

Description

本発明は、電子商取引システムに関する。

近年、企業間商取引（商品・資材の受発注など）の電子化を進める企業が増えてきている。インターネットや公衆回線などの電気通信回線を通じて商取引データを交換する仕組みは、ＥＤＩ（電子データ交換）とよばれる。ＥＤＩでは、発注者側の端末と受注者側の端末の間での円滑なデータ交換を実現するために、商取引データの形式を厳格に規格化・標準化することが前提となっている。例えば、商取引データには、発注者の識別情報、注文に係る商品や資材の品名・型番・注文数・単価などが含まれる。

特許文献１には、従来のＥＤＩシステム（電子商取引システム）が開示されている。
特開２００３−２０８３８２号公報

通常、どの企業も、商取引情報を社内管理するために、独自の社内システムを運用している。社内システムは社内の業務効率化を主目的として開発されるのが常であり、規格化・標準化された商取引データ（いわゆるＥＤＩフォーマット）に対応していないことがほとんどである。よって、そのような企業は、ＥＤＩシステムを導入するにあたって、ＥＤＩシステムと既存の社内システムを併用するか、ＥＤＩフォーマットの商取引データを入出力できるように既存の社内システムを改造するか、いずれかの選択をせまられる。

しかし、前者の場合は、２つのシステム間のデータの連携・整合をとるために、余計な手続や入出力作業が発生するし、ＥＤＩシステムの導入コストや設置コストが発生するという問題がある。また、後者の場合、ＥＤＩフォーマットに合わせて社内システムの大幅な改造を伴うケースがほとんどであり、一企業との取引のためだけに、そのような改造に伴うコストや労力を割くのは現実的でない。

一方で、多くの企業が集まり、これらのデータを共通に標準化・統一化する規格を開発し、システムの併用やデータの変換を少なくしようとする動きもある。しかし実際には、ＥＤＩの標準規格は業種や業界で複数存在するため、複数の異なる業界の企業と取引をする企業にとっては、システムの併用やデータの変換といった問題は依然として残っている。

このような作業負担増、コスト負担増が、ＥＤＩシステムの導入・普及を妨げる要因となっている。

加えて、イレギュラーな取引（特注品、特別価格など）が多いメーカーでは、以下のような問題もある。

従来のＥＤＩシステムでは、受発注処理の電子化及び完全自動化のために、全ての情報が漏れなく入力された完全なかたちの商取引データでなければ、受発注処理を実行できない仕組みになっている。商取引に関わる全ての情報が標準化されており、標準品を標準の手順で取引する、という理想的な環境においては、従来のＥＤＩシステムでも特に不都合はない。

しかしそうすると、特注品の注文や特別価格での提供などのイレギュラーな取引が発生したときに、従来のＥＤＩシステムでは対応できない。情報が未入力であったり、標準外の情報が入力された商取引データは、データエラーとして破棄されるからである。よって、イレギュラーな取引を行う場合には、従来通り、電話やファクシミリで受発注処理を進めざるを得なかった。

このような事情から、イレギュラーな取引が多いメーカーでは、ＥＤＩシステムの導入や効率的な運用が困難であった。

本発明は上記実情に鑑みてなされたものである。

本発明の第１の目的は、発注者に余計な労力やコストを課したり、発注者側の既存システムに大幅な改造を施したりすることなく導入可能な電子商取引システムを提供することにある。

本発明の第２の目的は、イレギュラーな取引にも柔軟に対応可能な電子商取引システムを提供することにある。

上記目的を達成するために本発明は、以下の構成を採用する。

本発明に係る電子商取引システムは、電気通信回線を通じて複数の発注者の発注システムとの間で商品の発注に関わるデータを交換するものであって、発注システムに組み込まれる発注モジュールと、受注者側の受注システムとを備える。発注モジュールは、発注システムに入力された発注情報を読み込み、その発注情報と当該発注者に固有の発注者識別子とを含む発注データを生成する発注データ生成手段と、発注データを受注システムに送信する発注データ送信手段と、を有する。受注システムは、発注者毎に異なる個々の発注データの形式に対応した、複数種類の変換プログラムを格納する記憶手段と、受信した発注データの発注者識別子に基づいて、その発注データの形式に対応した変換プログラムを記憶手段から選択する変換プログラム選択手段と、選択された変換プログラムを用いて、発注データの発注情報を電子商取引システムにて受注処理可能な形式に変換する形式変換手段と、変換後の発注情報により受注処理を実行する受注手段と、を有する。

この構成によれば、変換プログラムを介在させているので、従来のＥＤＩのようにデータ形式を厳格に規格化・標準化しておく必要がなく、どのような形式の商取引データにも柔軟に対応できる。また、発注システムからは、「発注者識別子」＋「（任意形式の）発注情報」からなる発注データを出力できれば足りる。よって、発注者が従来から運用していた既存システムに発注モジュールを組み込むだけで電子商取引に利用でき、発注者側でのシステム改造に要する労力・コストが最低限で済むとともに、発注者側での作業負担増・コスト増がない。なお、発注者識別子は、発注者を一意に特定できればどのような情報であってもよく、例えば、システム上で割り当てられたＩＤコード、発注者の電話番号、発注者の名称、発注システムのＩＤアドレスや電子メールアドレスなどが想定される。

また、受注システムが、発注者識別子に基づき自動的に適切な変換プログラムを選択するので、異なるデータ形式を採用する複数の発注者との間でのデータ交換を自動化・効率化できる。

しかも、新たな発注者を追加する場合、発注者識別子の登録と、その発注者に合わせた変換プログラムの追加だけで対応可能である、という利点もある。

ここで、受注手段が、発注情報に未入力の情報及び標準外の情報が含まれているか否かをチェックし、未入力の情報も標準外の情報も無い場合には発注情報に従って受注を確定し、未入力の情報又は標準外の情報が有る場合には、その情報を画面表示して受注者に情報の追加・訂正を促し、追加・訂正された情報に基づき受注を確定することが好ましい。

この構成によれば、発注情報の中に、未入力情報や標準外情報が含まれていても、エラーにならず、受注処理が実行される。言い換えれば、発注者識別子により発注者が特定できさえすれば、受注処理が実行される。よって、特注品の注文や特別価格での提供などのイレギュラーな取引にも柔軟に対応でき、電子商取引システムにて受注を一元管理することができる。

変換プログラムによる変換処理としては、例えば、テキストコードの変換、発注情報の項目の並べ替え、項目毎のデータ長の調整、及び、地域毎の日付形式の変換などがある。

これにより、ハードウェア又はソフトウェア的な互換性が無いシステム同士の間でも、円滑なデータ交換が可能となる。

なお、本発明は、上記手段の少なくとも一部を有する電子商取引システムとして捉えることができる。また、本発明は、上記処理の少なくとも一部を含む電子商取引方法、または、かかる方法を実現するための電子商取引プログラムとして捉えることもできる。上記手段および処理の各々は可能な限り互いに組み合わせて本発明を構成することができる。

本発明によれば、発注者に余計な労力やコストを課したり、発注者側の既存システムに大幅な改造を施したりすることなく導入可能な電子商取引システムを実現できる。また、イレギュラーな取引にも柔軟に対応可能な電子商取引システムを実現できる。よって、電子商取引の導入・普及を推進できるとともに、円滑な電子商取引の実現、並びに、商取引の迅速化・効率化を図ることができる。

以下に図面を参照して、この発明の好適な実施の形態を例示的に詳しく説明する。

（システム構成）
図１は、本発明の一実施形態に係る電子商取引システムの構成を示している。

この電子商取引システムは、概略、受注者（メーカーなど）側に設置される受注システム（受注サーバ１および基幹システム２）と、発注者（ユーザ、販売代理店、ＯＥＭ先など）の社内システムである発注システム３に組み込まれる発注モジュール４とから構成される。受注サーバ１は、ＬＡＮなどの電気通信回線５を介して受注者の社内基幹システム２と接続されている。また、受注サーバ１と各発注者の発注システム３との間はＷＡＮ（例えば、インターネット、一般公衆回線、専用線）などの電気通信回線６で接続されている。

この電子商取引システムは、電気通信回線６を通じて複数の発注者の発注システム３との間で商品の発注に関わるデータを交換可能である。なお、受発注情報の漏洩を防止するため、受注サーバ１と発注システム３との間は、ＶＰＮやダイヤルアップなどの安全性の高い接続方式を採用したり、暗号化などのセキュリティ対策をとったりすることが好ましい。

受注サーバ１、基幹システム２は、ＣＰＵ、メモリ、補助記憶装置、表示装置、入力装
置などを備える汎用的なコンピュータ（情報処理装置）により構成される。受注サーバ１は、その機能として、発注者特定部１０、データ形式変換部１１を備え、基幹システム２は、受注処理部１２を備える。これらの機能は補助記憶装置に格納されたプログラムがメモリに読み込まれ、ＣＰＵによって実行されることで実現される。

受注サーバ１の補助記憶装置内には、変換プログラム記憶部１３が設けられ、基幹システム２の補助記憶装置内にはデータベース１４と受発注データベース１５が設けられている。変換プログラム記憶部１３には、複数種類の変換プログラムＰ００１、Ｐ００２、・・・がそれぞれ発注者識別子「００１」、「００２」、・・・と関連付けられて格納されている。データベース１４には、顧客情報（発注者情報）、価格情報、在庫情報などの受注処理に関わる各種情報が格納されている。

基幹システム２は、受注者側の社内システムである。受注の確定したデータは基幹システム２の受発注データベース１５に登録される。基幹システム２では、社内的な進捗状況（日程計画）や在庫状況などが統括的に管理されている。

発注システム３は、発注者各々が独自に開発若しくは導入し運用している既存の社内システムを想定している。これもハードウェア的には、ＣＰＵ、メモリ、補助記憶装置、表示装置、入力装置などを備える汎用的なコンピュータ（情報処理装置）により構成されるが、ＯＳやアプリケーションなどのソフトウェアのレベルでは受注者や他の発注者のシステムとは互換性がないことが通例である。例えば、機能的な違いがあるのは勿論のこと、システム内で扱う情報の項目やそのデータ長、入出力可能なファイル形式、テキストコード（漢字コードや改行コード）、日付の形式などが異なる。

発注モジュール４は、発注システム３に組み込まれる（アドインされる）プログラムである。個々の発注者の発注システム３には、その仕様及び環境に合った発注モジュール４が組み込まれている。発注モジュール４は、その機能として、発注情報と発注者識別子とから発注データ７を生成する発注データ生成機能と、発注データ７を受注サーバ１に送信する発注データ送信機能とを有する。発注者識別子とは、受注者によって予め割り当てられた発注者の識別子であり、発注者毎に固有の値となっている。図１の例では、発注者Ａには「００１」が、発注者Ｂには「００２」が割り当てられている。

では次に、発注モジュール４の処理、及び、受注サーバ１の処理について詳しく説明する。

（発注モジュールの処理）
発注者側において発注システム３に入力された発注情報は、発注情報ＤＢに格納されている。発注情報に含まれる項目には、例えば、注文番号、担当者、品名、型番、数量、単価、納期などがある。この発注情報はあくまでも発注者側の仕様になっているため、発注情報の項目、データ形式などは受注者との間で統一されていない。発注モジュール４は受注者側での受注処理に必要な項目を適宜取捨選択し、発注データ７を作成する。

図２は、発注モジュール４の処理の流れを示すフローチャートである。このフローチャートに沿って発注モジュール４の処理の流れを説明する。

発注モジュール４が提供する発注画面において発注処理の開始命令が入力されると、発注モジュール４は発注システム３の発注情報ＤＢから該当する発注情報を読み込む（ステップＳ１０）。そして、読み込んだ発注情報から必要な情報を選び出し、発注データ７を生成する（ステップＳ１１）。このとき、発注モジュール４は、予め記憶している発注者識別子を発注データ７に含める。なお、発注データ７の形式は任意である。例えば、カンマやスペースで各項目がセパレートされたＣＳＶ形式のデータ、項目名（タグ）とその内容が列挙されたマークアップ形式のデータなどが好ましい。もちろんバイナリ形式のデータでもよい。

次に、発注モジュール４は受注サーバ１に接続する（ステップＳ１２）。セキュリティの観点から、発注者識別子とパスワードによる認証などを行うことが好ましい。そして、発注モジュール４は発注データ７を受注サーバ１に送信した後（ステップＳ１３）、接続を切断し発注処理を終了する。

（受注サーバの処理）
図３は、受注サーバと受注者の基幹システムの処理の流れを示すフローチャートである。このフローチャートに沿って、発注データ７の受信から受注確定までの処理の流れを説明する。

受注サーバ１が発注モジュール４から発注データ７を受信すると（ステップＳ２０）、まず発注者特定部１０が発注データ７に含まれる発注者識別子を調べることにより、発注者を特定する（ステップＳ２１）。そして、発注者特定部１０は、発注者識別子に基づいて、変換プログラム記憶部１３の中から、当該発注者の発注データの形式に対応した変換プログラムを選択する。例えば、発注者識別子が「００１」であったら、変換プログラムＰ００１が選択される。なお、もし発注データ７に発注者識別子が含まれていなかった場合には、データエラーとして処理が中断される。

次に、データ形式変換部１１が、変換プログラム記憶部１３から選択された変換プログラムＰ００１を読み込む（ステップＳ２２）。そして、その変換プログラムＰ００１を用いて、発注データ７に含まれる発注情報を電子商取引システムにて受注処理可能な形式に変換する（ステップＳ２３）。具体的には、変換プログラムは、テキストコード（漢字コード、改行コードなど）の変換、発注情報の項目の並べ替え、項目毎のデータ長の調整を行う。また、地域により日付形式が異なる場合には、その形式変換を行う。ただし、発注データ７の形式と受注処理可能な形式とが一致している部分が存在する場合には、その一致する部分の変換処理は行う必要がない。なお、発注データ７の項目が足りないときは、変換後のデータではその項目は空欄（未入力）とされる。発注者の名称、住所、配送先などの既知の顧客情報や正式な品名・型番などの商品情報に関しては、データ形式変換部１１が自動的に補完することも好ましい。

次に、受注処理部１２が、変換後の発注情報に未入力の情報や標準外（規定外）の情報が含まれているか否かをチェックする（ステップＳ２４）。

未入力の情報とは、発注データ７に項目自体が含まれておらず変換処理の際に追加された項目、あるいは、発注データ７に項目はあるが項目の内容が空欄であった項目のことである。例えば、特注品などでは発注時に型番や単価が不明な場合があり、発注側での入力ができないため、未入力のまま発注が行われるのである。

標準外の情報とは、（項目内容が入力されてはいるが）通常の受注処理として扱うべきでない情報をいう。例えば、所定の制限数量を超える数量が発注されたり、単価が予め契約している価格と異なっていたり、在庫状況からみて希望納期を満足できそうになかったり、特別価格での提供について社内稟議中であった場合などには、標準外として扱われる。受注者の基幹システム２のデータベース１４には、顧客情報、顧客毎の価格情報（通常価格、ＯＥＭ価格、特別割引価格、特注価格など）、在庫情報などが格納されており、受注処理部１２はデータベース１４を参照しながら、標準外か否かの判断を行う。

未入力の情報も標準外の情報も無かった場合には（ステップＳ２４；なし）、受注処理部１２は変換後の発注情報に従って受注を確定する（ステップＳ２７）。受注確定後は、その発注情報は基幹システム２に登録される。

未入力の情報又は標準外の情報が１つでも存在した場合には、受注を確定することができないため、その発注に関しては「受注未確定」というステイタスに設定され、以下に述べる発注情報の追加・訂正処理にまわされる（ステップＳ２４；あり）。

（発注情報の追加・訂正処理）
受注処理部１２は、表示装置に情報訂正画面を表示する（ステップＳ２５）。図４は、情報訂正画面の一例である。情報訂正画面には、受注未確定となった発注情報の各項目の内容が表示されるとともに、受注未確定となった理由を含む（つまり、未入力又は標準外であった）項目を反転表示される。これにより、ユーザ（受注者側のオペレータ）に対して発注情報の追加・訂正を促す。例えば図４の例では、受注単価が未入力であったために受注未確定状態となっており、受注単価の項目が反転表示され、且つ、「価格が入力されていません」というメッセージが表示されている。

ユーザは、キーボードやマウスなどの入力装置を操作し、情報訂正画面上で発注情報を入力することができる。ここで入力すべき情報は、社内的な規定値でもよいが、この発注の社内担当者に連絡を取ったり、発注者に連絡を取ることで確認することも好ましい。

追加・訂正により完全な形の発注情報が得られたら（ステップＳ２６）、受注処理部１２は、追加・訂正された発注情報に基づき受注確定処理を実行する（ステップＳ２７）。

以上述べた本実施形態の電子商取引システムによれば、変換プログラムを介在させているので、従来のＥＤＩのようにデータ形式を厳格に規格化・標準化しておく必要がなく、どのような形式の商取引データにも柔軟に対応できる。また、発注システム３からは、「発注者識別子」＋「（任意形式の）発注情報」からなる発注データ７を出力できれば足りる。よって、発注者が従来から運用していた既存システム（発注システム３）に発注モジュール４を組み込むだけで電子商取引に利用でき、発注者側でのシステム改造に要する労力・コストが最低限で済むとともに、発注者側での作業負担増・コスト増がない。

また、受注サーバ１が、発注者識別子に基づき自動的に適切な変換プログラムを選択するので、異なるデータ形式を採用する複数の発注者との間でのデータ交換を自動化・効率化できる。

しかも、新たな発注者を追加する場合、発注者識別子の登録と、その発注者に合わせた変換プログラムの追加だけで対応可能である、という利点もある。

さらに、発注情報の中に、未入力情報や標準外情報が含まれていても、エラーにならず、受注処理が実行される。言い換えれば、発注者識別子により発注者が特定できさえすれば、受注処理が実行される。よって、特注品の注文や特別価格での提供などのイレギュラーな取引にも柔軟に対応でき、電子商取引システムにて受注を一元管理することができる。

従って、本実施形態の電子商取引システムは、発注者に余計な労力やコストを課したり、発注者側の既存システムに大幅な改造を施したりすることなく導入可能であるとともに、イレギュラーな取引にも柔軟に対応可能である。それ故、電子商取引の導入・普及を推進できるとともに、円滑な電子商取引の実現、並びに、商取引の迅速化・効率化を図ることができる。

なお、上記実施形態は本発明の一具体例を例示したものにすぎない。本発明の範囲は上記実施形態に限られるものではなく、その技術思想の範囲内で種々の変形が可能である。

たとえば、上記実施形態では、受注サーバ１が発注データを受信するたびに受注処理を実行しているが、受信した発注データを一時的に蓄えておき、１０分おきなど一定時間ごとに受注処理をバッチ処理するようにしても構わない。

また、電子商取引システムの付加的な機能として、Ｗｅｂ画面を利用した発注データの入力や、Ｗｅｂ画面での在庫照会・発注情報照会・納品書や請求書のデータダウンロードなどを設けることも好ましい。

本発明の一実施形態に係る電子商取引システムの構成を示す図。 発注モジュールの処理の流れを示すフローチャート。 受注システムの処理の流れを示すフローチャート。 情報訂正画面の一例を示す図。

符号の説明

１ 受注サーバ
２ 基幹システム
３ 発注システム
４ 発注モジュール
５ 電気通信回線
６ 電気通信回線
７ 発注データ
１０ 発注者特定部
１１ データ形式変換部
１２ 受注処理部
１３ 変換プログラム記憶部
１４ データベース
１５ 受発注データベース

Claims (6)

1. 電気通信回線を通じて複数の発注者の発注システムとの間で商品の発注に関わるデータを交換可能な電子商取引システムであって、
   前記発注システムに組み込まれる発注モジュールと、
   受注者側の受注システムとを備え、
   前記発注モジュールは、
   前記発注システムに入力された発注情報を読み込み、その発注情報と当該発注者に固有の発注者識別子とを含む発注データを生成する発注データ生成手段と、
   前記発注データを前記受注システムに送信する発注データ送信手段と、を有し、
   前記受注システムは、
   発注者毎に異なる個々の発注データの形式に対応した、複数種類の変換プログラムを格納する記憶手段と、
   受信した発注データの発注者識別子に基づいて、その発注データの形式に対応した変換プログラムを前記記憶手段から選択する変換プログラム選択手段と、
   選択された変換プログラムを用いて、前記発注データの発注情報を電子商取引システムにて受注処理可能な形式に変換する形式変換手段と、
   変換後の発注情報により受注処理を実行する受注手段と、を有する
   ことを特徴とする電子商取引システム。
2. 前記受注手段は、
   前記発注情報に未入力の情報及び標準外の情報が含まれているか否かをチェックし、
   未入力の情報も標準外の情報も無い場合には、前記発注情報に従って受注を確定し、
   未入力の情報又は標準外の情報が有る場合には、その情報を画面表示して受注者に情報の追加・訂正を促し、追加・訂正された情報に基づき受注を確定する
   ことを特徴とする請求項１に記載の電子商取引システム。
3. 前記変換プログラムによる変換処理は、テキストコードの変換、発注情報の項目の並べ替え、項目毎のデータ長の調整、及び、地域毎の日付形式の変換の少なくとも１つの処理を含むことを特徴とする請求項１又は２に記載の電子商取引システム。
4. 電気通信回線を通じて複数の発注者の発注システムとの間で商品の発注に関わるデータを交換可能な電子商取引プログラムであって、
   前記発注システムに組み込まれる発注モジュールと、
   受注者側の情報処理装置にて実行される受注プログラムとを備え、
   前記発注モジュールは、前記発注システムに、
   前記発注システムに入力された発注情報を読み込み、その発注情報と当該発注者に固有の発注者識別子とを含む発注データを生成する処理と、
   前記発注データを前記情報処理装置に送信する処理と、を実行させ、
   前記受注プログラムは、発注者毎に異なる個々の発注データの形式に対応した、複数種類の変換プログラムを有し、
   前記受注プログラムは、前記情報処理装置に、
   受信した発注データの発注者識別子に基づいて、その発注データの形式に対応した変換プログラムを選択する処理と、
   選択された変換プログラムを用いて、前記発注データの発注情報を受注処理可能な形式に変換する処理と、
   変換後の発注情報により受注処理を実行する処理と、を実行させる
   ことを特徴とする電子商取引プログラム。
5. 前記受注プログラムは、前記情報処理装置に、
   前記発注情報に未入力の情報及び標準外の情報が含まれているか否かをチェックする処理と、
   未入力の情報も標準外の情報も無い場合には、前記発注情報に従って受注を確定し、
   未入力の情報又は標準外の情報が有る場合には、その情報を画面表示して受注者に情報の追加・訂正を促し、追加・訂正された情報に基づき受注を確定する処理と、を実行させることを特徴とする請求項４に記載の電子商取引プログラム。
6. 前記変換プログラムによる変換処理は、テキストコードの変換、発注情報の項目の並べ替え、項目毎のデータ長の調整、及び、地域毎の日付形式の変換の少なくとも１つの処理を含むことを特徴とする請求項４又は５に記載の電子商取引プログラム。

Images