(57)【要約】      （修正有）【課題】Ｂ２Ｂ取引における販売ＷＥＢの受注機能が有効に活用されていない状況を改善して、Ｂ２Ｃ取引用の販売ＷＥＢのように利用しやすい企業間受発注システムを提供する【解決手段】企業間受発注システムは、発注企業の購入希望者が受注企業の販売ＷＥＢサーバーに仮注文を行うと、受注企業から発注企業に対して仮注文を送信する第１の手段と、発注企業に仮注文が送信されると発注企業の購買担当者から受注企業に対して改めて注文を送信する第２の手段と、受注企業が注文を受信したら受注対応を行う第３の手段と、を具備する。【選択図】図１
2019220125.tif 000002
【特許請求の範囲】
【請求項１】
発注企業の購入希望者が受注企業に対して販売ＷＥＢサーバーを経由して仮注文を行うと、受注企業から発注企業に対して仮注文を送信する第１の手段と；
発注企業に仮注文が送信されると発注企業の購買担当者から受注企業に対して改めて注文を送信する第２の手段と；
受注企業が注文を受信したら受注対応を行う第３の手段と；
を具備していることを特徴とする企業間受発注システム。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明は、企業間での販売に伴うＷＥＢサーバーを経由して行う受発注の際の企業間受発注システムに関する。
【背景技術】
【０００２】  従来の企業間受発注システムは以下のような技術を利用して実用化されてきた。【０００３】  その一つは発注企業と受注企業の社内業務アプリケーションを特定の通信プロトコルを利用して１対１で接続する方式である。しかしこの方式では発注書と受注企業の社内業務アプリケーションが管理するデータ属性が異なるため、発注企業が取引データをそのまま送信しても、受注企業の業務アプリケーションはこれを理解することができない。【０００４】  上記の問題を解決するため第２のシステムが登場した。すなわち、業界ごとに共通のデータ属性仕様を業界標準として規定し、この業界標準を利用して発注企業は自社の取引データをこの業界標準データ属性仕様に変換して送信する。受注企業は受信した業界標準属性の取引データを自社の業務アプリケーションのデータ属性に再変換して取り込む。この方式は業界ＥＤＩ（Ｅｌｅｃｔｒｏｎｉｃ  Ｄａｔａ  Ｉｎｔｅｒｃｈａｎｇｅ）方式と呼ばれている。この方式は発注企業と受注企業にとってそれぞれデータ変換のための投資が必要となるため、大企業間取引にしか普及しなかったという問題がある。【０００５】  発注先が中小企業でも大きな投資をしないでデジタル取引データ交換を実現する手段として次に示す第３のシステムが実用化された。この方式は購買ＷＥＢ−ＥＤＩ方式と呼ばれており、発注企業が自社のホームページに購買ＷＥＢサイトを設けて、このサイトに注文データを表示し、受注企業はこのサイトへログインして自社への注文データを入手する。この方式の場合、受注者はブラウザさえあれば利用可能であるため、大企業と中小企業間取引の一部で利用されている。しかし発注企業の注文データが各社固有フォーマットで提供されたため、受注企業は注文デジタルデータをそのまま自社の販売管理システムへ入力することができず、紙印刷して手入力するなどの状況となっている。この結果ＦＡＸより不便との評価が定着し、一部の購買取引で利用されるに止まっている。【０００６】  この問題を解決するために、次に示す第４のシステムが実用化されている。このシステムでは発注企業と受注企業をＥＤＩプロバイダ経由で接続し、ＥＤＩプロバイダがデータ属性変換をサービスとして提供する方式である。発注企業と受注企業はＥＤＩプロバイダ接続機能を備えた業務アプリケーションを導入すれば、特別の投資をしなくても直ちに企業間取引のデジタルデータ化が可能になる。このシステムは電子メールの利便性を企業間デジタル取引に導入するとともに、電子メールの弱点である利用者の業務アプリケーションが直接デジタルデータ交換できない問題を解消した。この方式は共通ＥＤＩ方式と呼ばれており、データ変換サービスを提供するＥＤＩプロバイダを共通ＥＤＩプロバイダと呼んでいる。【０００７】  一方、デジタル販売の世界では、これらのＥＤＩ方式とは異なるインターネットを活用したデジタル販売システムが広く普及している。このシステムは企業‐ユーザー間（以下、Ｂ２Ｃという。）取引では、アマゾンや楽天のような大成功を収めている。この方式は受注企業がインターネット上に販売ＷＥＢを設けて電子カタログを公開し、このカタログより希望の商品を選択指定して注文すれば、決済まで完��できる。この方式は販売ＷＥＢ方式と呼ばれている。
【発明の開示】
【発明が解決しようとする課題】
【０００８】  しかしながら、上述の販売ＷＥＢ方式は企業間（以下、「Ｂ２Ｂ」という。）取引においてはあまり成功していない。Ｂ２Ｂ販売ＷＥＢの多くは受注入力機能だけでなく在庫確認機能や見積照会機能などのサービスを提供する画面を準備している。在庫確認や見積照会は高い頻度で利用されていて、ユーザー満足度も高い。これに対して、受注データは受注入力画面に入力されないで、ＦＡＸや電子メールなどのアナログな手段による受注が多数を占める状況が一般的に行われている。この理由はＢ２Ｂ取引では発注企業内の購入希望者と発注権限を有する購買担当者とが別異であるためである。購入希望者は販売ＷＥＢ画面で在庫や見積を確認しても自分で発注する権限がない。このため、発注企業内で購入希望者は購買依頼伝票を発注担当者に送付し、発注企業の購買管理システムへ注文データを登録することになる。また、受注企業の販売ＷＥＢと発注企業の購買システムは繋がっていないため、発注企業では注文データを受注企業の販売ＷＥＢに手入力することは面倒なので、購買担当者は発注企業の購買システムからＦＡＸで受注企業に対して注文書を送信することになる。この結果、受注企業の販売ＷＥＢは受注には利用されないことになり、そのために受１１０を手入力する状況となっている。
【発明が解決しようとする課題】
【０００９】  本発明は、Ｂ２Ｂ取引における販売ＷＥＢの受注機能が有効に活用されていない状況を改善して、Ｂ２Ｃ取引用の販売ＷＥＢのように利用しやすい企業間受発注システムを提供することを目的とする。
【課題を解決するための手段】
【００１０】  上記の課題を達成するために、本発明の企業間受発注システムにおいては、発注企業の購入希望者が受注企業の販売ＷＥＢサーバーに仮注文を行うと、受注企業から発注企業に対して仮注文が送信される第１の手段を具備している。また、仮注文の送信があると、発注企業の購買担当者から受注企業に対して改めて注文を送信する第２の手段を具備している。さらに、受注企業が注文を受信したら受注対応を行う第３の手段を具備している。【００１１】  上述の構成であれば、受注企業が発注企業に仮注文を送信することで、発注企業の購買担当者の注文可否判断を求めることができる。なお、発注を不可と判断したときには仮注文データのステータスをキャンセルに変更することができる。この場合、受注企業は発注企業の購買担当者からの発注取消返信があった場合、または一定期間内（例えば１日）の回答返信が無い場合は、仮注文ステータスを取消ステータスに変更することができる。
【発明の効果】
【００１２】  本発明の企業間受発注システムによれば、発注企業と受注企業における受発注の情報交換が容易になるので、発注企業においては購入希望者と購買担当者との間の業務の生産性が向上し、受注企業においては販売ＷＥＢの活用が可能になるとともに非効率な業務の解消が実現するので、Ｂ２Ｂ取引における販売ＷＥＢの受注機能が有効に活用されていない状況が改善されて、企業間における受発注の際のデータ交換がＢ２Ｃ取引用の販売ＷＥＢのように利用しやすくなるという効果を奏する。
【図面の簡単な説明】
【００１３】
【図１】本発明の企業間受発注システムの第１の実施形態を示すフローチャートである。
【図２】本発明の企業間受発注システムの第２の実施形態を示すフローチャートである。
【図３】本発明の企業間受発注システムの第３の実施形態を示すフローチャートである。
【図４】本発明の企業間受発注システムの第４の実施形態を示すフローチャートである。
【図５】本発明の企業間受発注システムの第５の実施形態を示すフローチャートである。
【図６】本発明の企業間受発注システムの第６の実施形態を示すフローチャートである。
【図７】本発明の企業間受発注システムの第７の実施形態を示すフローチャートである。
【発明を実施するための形態】
【００１４】  以下、本発明の実施の形態について詳細に説明する。
【００１５】  図１は本発明の第１の実施形態を示すフローチャートである。図の左側の縦長枠は発注企業を示し、右側の縦長枠は受注企業を示している。この受注企業は図において発注企業と離間して対峙している。そして、発注企業には購入希望者と購買担当者が上下に離間した位置に示され、さらに購買担当者の下に仮注文管理システム、購買システムおよび納品管理システムの各ブロックが上下に離間して配置されている。
【００１６】  受注企業は販売ＷＥＢサーバーと営業担当者が上下に離間した位置に示され、営業担当者の下に販売管理システムおよび納品管理システムのブロックが上下に離間して配置されている。
【００１７】  図示の実施形態においては、発注企業の購入希望者がＷＥＢ経由で受注企業の販売ＷＥＢサーバーにアクセスして、最初に▲１▼見積および在庫確認を行い、次に▲２▼仮注文を行った場合のプロセス処理の流れが矢印で示されている。すなわち、販売ＷＥＢサーバーに受注企業から▲２▼仮注文が入力されると、販売ＷＥＢサーバーから▲２▼仮注文が販売管理システムに対して通知される。そして、販売管理システムから発注企業の仮注文管理システムに▲３▼仮注文送信が行われる。その結果、発注企業の購買担当者が上述の▲２▼仮注文について注文可否判断を行うことができる。
【００１８】  そうして、購買担当者は受信した仮注文データに判断したステータスを付して▲４▼注文を受注企業に通信する。すなわち、発注してよいと判断された仮注文データは、ステータスを▲４▼注文に変更して発注企業に返信し、併せて自企業の購買システムへ注文を入力する。
【００１９】  受注企業においては、発注企業の購買担当者から注文データが正規注文として返信されたら、販売システ管理システムに登録されている仮注文ステータスを受注ステータスに変更して通常の受注プロセスへ移行する。
【００２０】  これに対して、購買担当者が発注を不可とした場合、仮注文データはステータスをキャンセルに変更して受注企業に通信する。
【００２１】  そして、発注企業の購買担当者から発注取消返信があった場合、または一定期間、例えば１日の回答返信がない場合には、受注企業は仮注文ステータスを取消ステータスに変更する。
【００２２】  なお、本実施形態において、発注企業に購買担当者が設けられていない場合には、発注担当者の上司や専任担当者を購買担当者に代えて上述の購買担当者の役割を担うように対応することもできる。
【００２３】  前記通常の受注プロセスにおいては、注文があると販売システムから在庫管理システムに出荷指示が行われて発注企業に向けて出荷される。発注企業では納品がなされると、納品管理システムに納品が登録される。
【００２４】  図２は本発明の第２の実施形態を示すフローチャートである。図１との対比において、発注企業の仮注文管理システムと受注企業の販売管理システムとの間が共通ＥＤＩプロバイダを介して接続されている点で異なる。なお、図１との共通部分については説明を省略する。
【００２５】  共通ＥＤＩプロバイダは、発注企業の仮注文管理システムと受注企業の販売管理システムとの間に介在して、受注企業から発注企業への仮注文送信および発注企業から受注企業への注文に対して、それぞれデジタルデータ変換サービスを提供する。
【００２６】  図３は本発明の第３の実施形態を示すフローチャートである。図１に示す本発明の第１の実施形態との対比において、受注企業は販売管理システムの前段に営業担当者が操作する仮注文管理システムを備えている点で異なる。販売ＷＥＢサーバーが仮注文管理システムを介して販売管理システムに接続し、発注企業と受注企業がそれぞれの仮注文管理システムの間で▲３▼仮注文送信および▲４▼注文または取消が通信されるように構成されている。
【００２７】  図４は本発明の第４の実施形態を示す実施形態である。本実施形態は第３の実施形態との対比において、受注企業の仮注文管理システムから共通ＥＤＩプロバイダを介して発注企業の仮注文管理システムに▲３▼仮注文送信が行われる点で相違している。また、発注企業から受注企業に対して行う▲４▼注文または取消も共通ＥＤＩプロバイダを介して通信される。
【００２８】  図５は本発明の第５の実施形態を示すフローチャートである。本実施形態は単一の発注企業から共通ＥＤＩプロバイダを経由して複数の受注企業（なお、図５においては３企業）の仮注文管理システムに対して一括した送受信を行えるように構成されている。このため、発注企業において発注企業と複数の受注企業との間の取引データ交換が一元的に管理可能になる。すなわち、共通ＥＤＩプロバイダが複数の受注企業の送信データを共通フォーマットにして発注企業へ提供するサービスを行うことができる。一方、発注企業は複数の受注企業との取引を単一の仮注文管理システムを導入すればよい。第５の実施形態によれば、発注企業の生産性が向上する効果が得られる。また、第５の実施形態においては発注企業内の複数の購買希望者が同時的に複数の受注企業に対して見積請求および仮注文を行うことができる。
【００２９】  図６は本発明の第６の実施形態を示すフローチャートである。本実施形態は複数の発注企業が共通ＥＤＩプロバイダを経由して単一の受注企業に通信することができるように構成されている。上記共通ＥＤＩプロバイダが複数の発注企業に向けて共通ＥＤＩを行うように構成されている。
【００３０】  第６の実施形態によれば、複数の発注企業の送信データを共通フォーマットにして受注企業へ提供するサービスを行うことができる。すなわち、複数の発注企業ではそれぞれの購入希望者が個別に受注企業の販売ＷＥＢサーバーにアクセスして見積を求めて仮注文を行うことができ、受注企業は共通ＥＤＩプロバイダによる販売の一元管理が可能になる。
【００３１】  図７は本発明の第７の実施形態を示すフローチャートである。本実施形態はそれぞれ複数の発注企業と受注企業が共通ＥＤＩプロバイダを経由して相互に受発注を通信することができるように構成されている。また、上記共通ＥＤＩプロバイダは図示を省略している他の共通ＥＤＩプロバイダと通信可能なように構成することができる。
【００３２】  第７の実施形態によれば、各受注企業の販売ＷＥＢが互いに異なっていたとしても共通ＥＤＩプロバイダを共同利用することで任意所望の受注企業と発注企業との間で発注企業と受注企業の仮注文管理システムを経由して所望の仮注文および注文を行うことができる。
【００３３】  また、本実施形態によれば、発注企業は共通ＥＤＩプロバイダとの間で一括した送受信を行うことで総ての受注企業との間の取引データ交換が一元的に管理可能になり、受発注に係る生産性が向上する効果が得られる。
【００３４】  そうして、本実施形態によれば、それぞれ複数の発注企業と受注企業が共同利用できるＢ２Ｂ販売プラットフォームを実現することができる。
【符号の説明】▲１▼…見積・在庫確認、▲２▼…仮注文、▲３▼…仮注文送信、▲４▼…注文または取消、▲５▼…出荷指示、▲６▼…出荷
【書類名】図面
【書類名】特許請求の範囲
【書類名】要約書
【書類名】図面
【図１】
2019220125.tif 000003
【図２】
2019220125.tif 000004
【図３】
2019220125.tif 000005
【図４】
2019220125.tif 000006
【図５】
2019220125.tif 000007
【図６】
2019220125.tif 000008
【図７】
2019220125.tif 000009
【手続補正書】
【提出日】平成30年12月25日(2018.12.25)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、企業間での販売に伴うＷＥＢサーバーを経由して行う受発注の際の企業間受発注システムに関する。
【背景技術】
【０００２】
従来の企業間受発注システムは以下のような技術を利用して実用化されてきた。
【０００３】
その一つは発注企業と受注企業の社内業務アプリケーションを特定の通信プロトコルを利用して１対１で接続する方式である。しかしこの方式では発注書と受注企業の社内業務アプリケーションが管理するデータ属性が異なるため、発注企業が取引データをそのまま送信しても、受注企業の業務アプリケーションはこれを理解することができない。
【０００４】
上記の問題を解決するため第２のシステムが登場した。すなわち、業界ごとに共通のデータ属性仕様を業界標準として規定し、この業界標準を利用して発注企業は自社の取引データをこの業界標準データ属性仕様に変換して送信する。受注企業は受信した業界標準属性の取引データを自社の業務アプリケーションのデータ属性に再変換して取り込む。この方式は業界EDI（Electronic Data Interchange）方式と呼ばれている。この方式は発注企業と受注企業にとってそれぞれデータ変換のための投資が必要となるため、大企業間取引にしか普及しなかったという問題がある。
【０００５】
発注先が中小企業でも大きな投資をしないでデジタル取引データ交換を実現する手段として次に示す第３のシステムが実用化された。この方式は購買WEB-EDI方式と呼ばれており、発注企業が自社のホームページに購買WEBサイトを設けて、このサイトに注文データを表示し、受注企業はこのサイトへログインして自社への注文データを入手する。この方式の場合、受注者はブラウザさえあれば利用可能であるため、大企業と中小企業間取引の一部で利用されている。しかし発注企業の注文データが各社固有フォーマットで提供されたため、受注企業は注文デジタルデータをそのまま自社の販売管理システムへ入力することができず、紙印刷して手入力するなどの状況となっている。この結果FAXより不便との評価が定着し、一部の購買取引で利用されるに止まっている。
【０００６】
この問題を解決するために、次に示す第４のシステムが実用化されている。このシステムでは発注企業と受注企業をEDIプロバイダ経由で接続し、EDIプロバイダがデータ属性変換をサービスとして提供する方式である。発注企業と受注企業はEDIプロバイダ接続機能を備えた業務アプリケーションを導入すれば、特別の投資をしなくても直ちに企業間取引のデジタルデータ化が可能になる。このシステムは電子メールの利便性を企業間デジタル取引に導入するとともに、電子メールの弱点である利用者の業務アプリケーションが直接デジタルデータ交換できない問題を解消した。この方式は共通EDI方式と呼ばれており、データ変換サービスを提供するEDIプロバイダを共通EDIプロバイダと呼んでいる。
【０００７】
一方、デジタル販売の世界では、これらのEDI方式とは異なるインターネットを活用したデジタル販売システムが広く普及している。このシステムは企業‐ユーザー間（以下、Ｂ２Ｃという。）取引では、アマゾンや楽天のような大成功を収めている。この方式は受注企業がインターネット上に販売WEBを設けて電子カタログを公開し、このカタログより希望の商品を選択指定して注文すれば、決済まで完了できる。この方式は販売WEB方式と呼ばれている。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、上述の販売WEB方式は企業間（以下、「Ｂ２Ｂ」という。）取引においてはあまり成功していない。Ｂ２Ｂ販売WEBの多くは受注入力機能だけでなく在庫確認機能や見積照会機能などのサービスを提供する画面を準備している。在庫確認や見積照会は高い頻度で利用されていて、ユーザー満足度も高い。これに対して、受注データは受注入力画面に入力されないで、FAXや電子メールなどのアナログな手段による受注が多数を占める状況が一般的に行われている。この理由はＢ２Ｂ取引では発注企業内の購入希望者と発注権限を有する購買担当者とが別異であるためである。購入希望者は販売WEB画面で在庫や見積を確認しても自分で発注する権限がない。このため、発注企業内で購入希望者は購買依頼伝票を発注担当者に送付し、発注企業の購買管理システムへ注文データを登録することになる。また、受注企業の販売WEBと発注企業の購買システムは繋がっていないため、発注企業では注文データを受注企業の販売WEBに手入力することは面倒なので、購買担当者は発注企業の購買システムからFAXで受注企業に対して注文書を送信することになる。この結果、受注企業の販売WEBは受注には利用されないことになり、そのために受注企業はFAXなどのアナログ注文データを受信し、内部の販売管理システムへ注文データを手入力する状況となっている。
【０００９】
本発明は、Ｂ２Ｂ取引における販売WEBの受注機能が有効に活用されていない状況を改善して、Ｂ２Ｃ取引用の販売WEBのように利用しやすい企業間受発注システムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記の課題を達成するために、本発明の企業間受発注システムにおいては、発注企業の購入希望者が受注企業の販売WEBサーバーに仮注文を行うと、受注企業から発注企業に対して仮注文が送信される第1の手段を具備している。また、仮注文の送信があると、発注企業の購買担当者から受注企業に対して改めて注文を送信する第２の手段を具備している。さらに、受注企業が注文を受信したら受注対応を行う第３の手段を具備している。
【００１１】
上述の構成であれば、受注企業が発注企業に仮注文を送信することで、発注企業の購買担当者の注文可否判断を求めることができる。なお、発注を不可と判断したときには仮注文データのステータスを取消に変更することができる。この場合、受注企業は発注企業の購買担当者からの発注取消返信があった場合、または一定期間内（例えば１日）の回答返信が無い場合は、仮注文ステータスを取消ステータスに変更することができる。
【発明の効果】
【００１２】
本発明の企業間受発注システムによれば、発注企業と受注企業における受発注の情報交換が容易になるので、発注企業においては購入希望者と購買担当者との間の業務の生産性が向上し、受注企業においては販売WEBの活用が可能になるとともに非効率な業務の解消が実現するので、Ｂ２Ｂ取引における販売WEBの受注機能が有効に活用されていない状況が改善されて、企業間における受発注の際のデータ交換がＢ２Ｃ取引用の販売WEBのように利用しやすくなるという効果を奏する。
【図面の簡単な説明】
【００１３】
【図１】本発明の企業間受発注システムの第１の実施形態を示すフローチャートである。
【図２】本発明の企業間受発注システムの第２の実施形態を示すフローチャートである。
【図３】本発明の企業間受発注システムの第３の実施形態を示すフローチャートである。
【図４】本発明の企業間受発注システムの第４の実施形態を示すフローチャートである。
【図５】本発明の企業間受発注システムの第５の実施形態を示すフローチャートである。
【図６】本発明の企業間受発注システムの第６の実施形態を示すフローチャートである。
【図７】本発明の企業間受発注システムの第７の実施形態を示すフローチャートである。
【発明を実施するための形態】
【００１４】
以下、本発明の実施の形態について詳細に説明する。
【００１５】
図１は本発明の第１の実施形態を示すフローチャートである。図の左側の縦長枠は発注企業を示し、右側の縦長枠は受注企業を示している。この受注企業は図において発注企業と離間して対峙している。そして、発注企業には購入希望者と購買担当者が上下に離間した位置に示され、さらに購買担当者の下に仮注文管理システム、購買システムおよび納品管理システムの各ブロックが上下に離間して配置されている。
【００１６】
受注企業は販売WEBサーバーと営業担当者が上下に離間した位置に示され、営業担当者の下に販売管理システムおよび在庫システムのブロックが上下に離間して配置されている。
【００１７】
図示の実施形態においては、発注企業の購入希望者がWEB経由で受注企業の販売WEBサーバーにアクセスして、最初に（丸で囲んだ数字１）見積および在庫確認を行い、次に（丸で囲んだ数字２）仮注文を行った場合のプロセス処理の流れが点線の矢印で示されている。すなわち、受注企業から受注企業の販売WEBサーバーに対して（丸で囲んだ数字２）仮注文が入力されると、受注企業では販売WEBサーバーから販売管理システムに（丸で囲んだ数字２）仮注文が通知される。そして、受注企業の販売管理システムから発注企業の仮注文管理システムに対して（丸で囲んだ数字３）仮注文送信が行われる。以上の流れが本発明の第１の手段に相当する。上記仮注文送信の結果、発注企業では購買担当者が上述の（丸で囲んだ数字２）仮注文について注文可否判断を行うことができる。
【００１８】
そうして、発注企業の購買担当者は受信した仮注文データについて判断したステータスを付して（丸で囲んだ数字４）注文を受注企業に通信する。すなわち、発注してよいと判断された仮注文データについては、ステータスを（丸で囲んだ数字４）注文に変更して受注企業に返信する。併せて自企業の購買システムに注文を入力する。以上の注文の流れが本発明の第２の手段に相当する。
【００１９】
受注企業においては、発注企業の購買担当者から注文データが正規の注文として返信されたら、販売管理システムに登録されている仮注文ステータスを受注ステータスに変更して通常の受注プロセスへ移行する。以上の受注の流れが本発明の第３の手段に相当する。
【００２０】
これに対して、購買担当者が発注を不可とした場合、仮注文データはステータスを取消に変更して受注企業に返信する。
【００２１】
そして、発注企業の購買担当者から発注の取消の返信があった場合、または一定期間、例えば１日の間に回答返信がない場合には、受注企業は仮注文ステータスを取消ステータスに変更する。
【００２２】
なお、本実施形態において、発注企業に購買担当者が設けられていない場合には、発注担当者の上司や専任担当者を購買担当者に代えて上述の購買担当者の役割を担うように対応することもできる。
【００２３】
前記通常の受注プロセスにおいては、受注企業に注文があると販売システムから在庫管理システムに出荷指示が行われて発注企業に向けて出荷される。発注企業では納品がなされると、納品管理システムに納品が登録される。
【００２４】
図２は本発明の第２の実施形態を示すフローチャートである。図１との対比において、発注企業の仮注文管理システムと受注企業の販売管理システムとの間が共通EDIプロバイダを介して接続されている点で異なる。なお、図１との共通部分については説明を省略する。
【００２５】
共通EDIプロバイダは、発注企業の仮注文管理システムと受注企業の販売管理システムとの間に介在して、受注企業から発注企業への仮注文送信および発注企業から受注企業への注文に対して、それぞれデジタルデータ変換サービスを提供する。
【００２６】
図３は本発明の第３の実施形態を示すフローチャートである。図１に示す本発明の第１の実施形態との対比において、受注企業には営業担当者と販売管理システムとの間に仮注文管理システムが設けられているとともに販売WEBサーバーが上記仮注文管理システムを介して販売管理システムに接続し、発注企業と受注企業がそれぞれの仮注文管理システムの間で（丸で囲んだ数字３）仮注文送信および（丸で囲んだ数字４）注文または取消が通信されるように構成されている。
【００２７】
図４は本発明の第４の実施形態を示す実施形態である。本実施形態は第３の実施形態との対比において、受注企業の仮注文管理システムから共通EDIプロバイダを介して発注企業の仮注文管理システムに（丸で囲んだ数字４）仮注文送信が行われる点で相違している。また、発注企業から受注企業に対して行う（丸で囲んだ数字４）注文または取消もEDIプロバイダを介して通信される。
【００２８】
図５は本発明の第５の実施形態を示すフローチャートである。本実施形態は単一の発注企業から共通EDIプロバイダを経由して複数の受注企業（なお、図５においては３企業）の仮注文管理システムに対して一括した送受信を行えるように構成されている。このため、発注企業において発注企業と複数の受注企業との間の取引データ交換が一元的に管理可能になる。すなわち、共通EDIプロバイダが複数の受注企業の送信データを共通フォーマットにして発注企業へ提供するサービスを行うことができる。一方、発注企業は複数の受注企業との取引を単一の仮注文管理システムを導入すればよい。
【００２９】
第５の実施形態によれば、発注企業の生産性が向上する効果が得られる。また、第５の実施形態においては発注企業内の複数の購買希望者が同時的に複数の受注企業に対して見積請求および仮注文を行うことができる。
【００３０】
図６は本発明の第６の実施形態を示すフローチャートである。本実施形態は複数の発注企業が共通EDIプロバイダを経由して単一の受注企業に通信することができるように構成されている。上記共通EDIプロバイダが複数の発注企業に向けて共通EDIを行うように構成されている。
【００３１】
第６の実施形態によれば、複数の発注企業の送信データを共通フォーマットにして受注企業へ提供するサービスを行うことができる。すなわち、複数の発注企業ではそれぞれの購入希望者が個別に受注企業の販売WEBサーバーにアクセスして見積を求めて仮注文を行うことができ、受注企業の共通EDIプロバイダによる販売の一元管理が可能になる。
【００３２】
図７は本発明の第７の実施形態を示すフローチャートである。本実施形態はそれぞれ複数の発注企業と受注企業が共通EDIプロバイダを経由して相互に受発注を通信することができるように構成されている。また、上記共通EDIプロバイダは図示を省略している他の共通EDIプロバイダと通信可能なように構成することができる。
【００３３】
第７の実施形態によれば、各受注企業の販売WEBが互いに異なっていたとしても共通EDIプロバイダを共有することで任意所望の受注企業と発注企業との間で受注企業の仮注文管理システムを経由して所望の仮注文および注文を所望に行うことができる。
【００３４】
また、本実施形態によれば、発注企業は共通EDIプロバイダとの間で一括した送受信を行うことで総ての受注企業との間の取引データ交換が一元的に管理可能になるので、受発注に係る生産性が向上する効果が得られる。
【００３５】
そうして、本実施形態によれば、それぞれ複数の発注企業と受注企業が共同利用できるＢ２Ｂ販売プラットフォームを実現することができる。
【符号の説明】
【００３６】
（丸で囲んだ数字１）…見積・在庫確認、（丸で囲んだ数字２）…仮注文、（丸で囲んだ数字３）…仮注文送信、（丸で囲んだ数字４）…注文または取消、（丸で囲んだ数字５）…出荷指示、（丸で囲んだ数字６）…出荷