JP2004164146A

JP2004164146A - 商品受発注管理方法、装置及びプログラム

Info

Publication number: JP2004164146A
Application number: JP2002327676A
Authority: JP
Inventors: Hirobumi Hashimoto; 博文橋本; Shuichi Kawakita; 周一川北; Noriko Momoki; 典子桃木
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2002-11-12
Filing date: 2002-11-12
Publication date: 2004-06-10

Abstract

【課題】本発明は注文後の商品情報変更による、購買者の注文処理のやり直しを防止する方法および装置を提供することにある。
【解決手段】注文情報を登録するにあたり、同時に注文条件を登録する（ステップ１０１００）。また、商品情報の変更（ステップ１０３００）や、商品情報の有効期限終了を検査し（ステップ１０４００）、注文条件に従って注文情報を変更する（ステップ１０５００）。さらに、注文情報の変更結果を購買者および販売者へ通知する（ステップ１０５１１）。
【選択図】図２

Description

【０００１】
【発明の属する技術分野】
本発明は、商品の受発注を管理する方法、装置及びプログラムに関し、特に商品注文後に当該商品情報が変更された場合でも、注文条件に従って注文情報を自動的に変更する受発注管理方法、装置及びプログラムに関する。
【０００２】
【従来の技術】
インターネットの普及に伴い、購買者が販売者の公開している販売サイトにアクセスし、販売者が提供する商品情報の中から購入する商品を選択し、個数や送付先などの注文情報を指定し、販売者に対して注文を行う電子商取引が広く行われている。
【０００３】
特に最近では、仲介者が複数の販売者の商品情報を公開および販売するショッピングモール形式のサイトが多く見られるようになった。
【０００４】
例えば下記する特許文献１に示されるように、購買者は複数の販売者が提供する商品を比較検討しながらショッピングカートに投入し、予算を元に商品を取捨選択しながら購入商品を決定し、予約注文を行う。この時、予約注文に猶予期間を設けて、この猶予期間内であれば、注文内容を自由に変更できるようにし、購買者に商品の選択に余裕を持って十分検討できるようにしている。
【０００５】
下記の特許文献２には、ユーザからの注文に対して、その注文商品が在庫切れの場合、あるいはユーザの希望するサービスが提供不可の場合に、類似の商品やサービスをユーザに提示することが記載されている。
【０００６】
【特許文献１】
特開２００２−６３４３１号公報
【特許文献２】
特開２００２−９２４５９号公報
【０００７】
【発明が解決しようとする課題】
かかる従来の方法においては、次のような事項については配慮されていない。
【０００８】
すなわち、猶予期間内に予約注文した商品の販売が中止になった場合や、価格が変更になった場合には、予約注文の情報が無効になる可能性がある。
【０００９】
特に、企業間の商取引のように、予約注文の後に経理部門や資材部門の承認など社内の承認処理が必要な場合や、予約発注から確定発注までの期間が長い場合など、この間に商品情報が変更される可能性が高い。
【００１０】
そのような場合、販売者は変更された商品を注文している購買者に対して、連絡が必要となる場合がある。
【００１１】
また、購買者は商品情報の変更により、社内の承認処理のやり直しや、予約発注の変更が必要となり、手間がかかる。
【００１２】
本発明の目的は、商品情報が変更されて、注文情報が無効になった場合に、自動的に注文情報を変更する方法および装置を提供することにある。
【００１３】
また本発明の他の目的は、注文情報が無効になった場合や、注文情報が変更になった場合に、購買者および販売者に通知を行う方法および装置を提供することにある。
【００１４】
【課題を解決するための手段】
本発明は、受発注管理方法において、購買者が商品の注文情報登録時に、注文後に商品情報が変更された場合の注文情報の変更処理方法を定義した注文条件を同時に登録する。注文条件例としては、商品Ａの価格が３０００円以上に変更された場合は、商品Ｂに注文情報を変更する、商品Ｂが３０００円以下となった場合は、注文数量を５個へ増やすなどがある。このように、購買者が注文条件を注文情報作成時にあらかじめ定義することにより、購買者は注文後に商品情報が変更されても、注文情報を改めて変更する手間がかからなくなる。特に、注文後に経理部門や資材部門などの社内承認フローがある場合など、承認フローのやり直しを防ぐことが可能となる。
【００１５】
また、商品情報の有効期間を管理することにより、販売者は商品情報の改廃をあらかじめ定義できるだけでなく、購買者に商品情報の期限すなわち注文の有効期限をあらかじめ提示できることにより、商品情報変更の際に販売者から購買者への連絡を行う手間を防ぐことが可能となる。
【００１６】
また、注文情報の変更結果を販売者および購買者へ自動的に通知することにより、注文情報が無効になった際に販売者から購買者への連絡を行う手間を防ぐことが可能となる。
【００１７】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。
【００１８】
図１は、本発明の実施の形態を実現するための受発注管理サーバーのモジュール構成を含む受発注管理システムの全体構成図である。
【００１９】
まず、図１に示す受発注管理システムの全体構成図について説明する。
【００２０】
本実施形態の受発注管理システムは、受発注情報の管理を行なう受発注管理サーバー１００と、注文情報を入力する購買者端末２００と、注文情報を参照する販売者端末３００とが、通信ネットワーク４００で接続されたシステムである。なお、受発注管理サーバー１００、購買者端末２００および販売者端末３００に付随する入力装置、表示装置などを含む出力装置および通信装置など、一般の計算機に搭載されている装置に関し、その記載は図示省略している。
【００２１】
なお、本実施形態では、仲介者が管理する受発注管理サーバー１００において、１つ以上の販売者と１つ以上の購買者が取引を行なう例を元に説明を行なうが、販売者が販売者毎に独自に受発注管理サーバー１００を管理する構成にしても良い。
【００２２】
商品情報管理部１６０は、商品情報１１０のデーターの読み出しと更新を行なうものである。
【００２３】
商品情報１１０は、本実施形態において販売者から購買者へ販売される商品の情報を保存するものである。
【００２４】
注文情報管理部１７０は、注文情報１２０、注文条件１３０および更新結果１４０の各データーの読み出しと更新を行なうものである。
【００２５】
注文情報１２０は、購買者端末２００において作成された注文の情報の保存を行なうものである。
【００２６】
注文条件１３０は、注文情報管理部１７０によって注文情報１２０を変更する場合の条件および変更内容を保存するものである。また、注文情報１３０は購買者端末２００において注文情報作成時に同時に作成するものである。
【００２７】
更新結果１４０は、注文情報管理部１７０によって注文情報１２０を変更した結果を保存するものである。
【００２８】
図２は、本発明の実施の形態を示す処理フロー図である。
【００２９】
図３は、ステップ１０１００の詳細処理フロー図である。
【００３０】
図４は、ステップ１０５００の詳細処理フロー図である。
【００３１】
図５は、商品情報１１０のテーブル構成図である。
【００３２】
商品情報１１０は、商品ＩＤ１１１、改定番号１１２、単価１１３、販売者ＩＤ１１４、有効期間１１５で構成される。
【００３３】
商品ＩＤ１１１は、商品情報１１０において商品を一意に特定するための情報である。
【００３４】
改定番号１１２は、商品ＩＤ１１１が同一である商品の情報の改定履歴を管理する情報である。すなわち、同一商品において、単価などの商品情報が改定された際、改定前と改定後を識別するための情報である。
【００３５】
なお、本発明において改定番号１１２の採番方法は問題ではなく、どのような採番方法をとってもよい。重要な点は、商品ＩＤ１１１と改定番号１１２によって商品情報の改定履歴が一意に特定できることである。
【００３６】
単価１１３は、商品の単価を管理する情報である。
【００３７】
販売者ＩＤ１１４は、商品を販売する販売者を一意に特定する情報である。
【００３８】
有効期間１１５は、商品の販売期間であり、前記期間中に注文が確定すれば購入できることを示す情報である。
【００３９】
図６は、注文情報１２０のテーブル構成図である。
【００４０】
注文情報１２０は、注文ＩＤ１２１、商品ＩＤ１２２、改定番号１２３、販売者ＩＤ１２４、購買者ＩＤ１２５、単価１２６、数量１２７、状態１２８で構成される。
【００４１】
注文ＩＤ１２１は、注文情報１２０において、注文の情報を一意に識別する情報である。
【００４２】
商品ＩＤ１２２は、図５の商品ＩＤ１１１に、改定番号１２３は、図５の改定番号１１２にそれぞれ対応し、注文する商品の情報を一意に識別する情報である。
【００４３】
販売者ＩＤ１２４は、図５の販売者ＩＤ１１４に対応し、注文する商品の販売者を識別する情報である。
【００４４】
購買者ＩＤ１２５は、注文する商品の購買者を識別する情報である。
【００４５】
単価１２６は、図４の単価１１３に対応し、注文する商品の単価を保存するものである。
【００４６】
数量１２７は、商品の注文数量を保存するものである。
【００４７】
状態１２８は、注文の情報の処理状態を保存するものである。本実施例において、状態１２８は「注文受付」、「注文確定」、「注文代替」、「注文無効」、「注文取消」の５つの値をとることとする。「注文受付」は受発注管理サーバー１００が購買者端末２００から注文を受付けた状態を示す。「注文確定」は注文が確定して、注文情報の変更を受付けない状態を示す。「注文代替」は注文情報１３０を変更する場合の変更後の注文情報であることを示す。「注文無効」は商品情報１１０が変更されたり、有効期間１１５が終了したりして、販売していない商品を注文していることを示す。「注文取消」は注文を取り消したことを示している。
【００４８】
図７は、注文条件１３０のテーブル構成図である。
【００４９】
注文条件１３０は、条件ＩＤ１３１、注文ＩＤ１３２、商品ＩＤ１３３、条件１３４、操作１３５、代替注文ＩＤ１３６で構成される。
【００５０】
条件ＩＤ１３１は、注文条件１３０において、注文の条件を一意に識別する情報である。
【００５１】
注文ＩＤ１３２は、図６の注文ＩＤ１２１と対応し、注文情報１２０を一意に識別する情報である。
【００５２】
商品ＩＤ１３３は、図６の商品ＩＤ１２２と対応し、注文する商品情報１１０を一意に識別する情報である。
【００５３】
条件１３４は、注文条件を変更する場合の条件を保存するものである。本発明にて条件１３４に対し、特に記述方法を規定するものではないが、本実施例おいては「単価≦３０００」、「単価＞３０００」、「販売終了」を例に挙げている。「単価≦３０００」は、商品の単価が３０００円以下の場合を示している。「単価＞３０００」は、商品の単価が３０００円より大きい場合を示している。「販売終了」は、商品の販売が終了した場合を示している。
【００５４】
操作１３５は、注文条件を変更する場合の変更内容を保存するものである。
【００５５】
本発明にて操作１３５に対し、特に記述方法を規定するものではないが、本実施例おいては「継続」、「変更」、「取消」を例に挙げている。「継続」は、同一商品を購入することを示している。すなわち、改定番号１２３のみを販売中の商品に変更することを示している。「変更」は指定した注文情報へ変更することを示している。変更する注文情報は、代替注文ＩＤ１３６へ注文ＩＤ１２１を登録することで指定する。「取消」は、注文を取り消すことを示している。
【００５６】
図８は、更新結果１４０のテーブル構成図である。
【００５７】
更新結果１４０は、注文ＩＤ１４１、商品ＩＤ１４２、条件ＩＤ１４３、結果１４４で構成される。
【００５８】
注文ＩＤ１４１は、図６の注文ＩＤ１２１と、商品ＩＤ１４２は商品ＩＤ１２２対応し、どの注文情報１２０に対する更新結果１４０であるかを一意に識別する情報である。
【００５９】
条件ＩＤ１４３は、図７の条件ＩＤ１３１と対応し、注文条件１３０を一意に識別する情報である。
【００６０】
結果１４４は、条件ＩＤ１４３に対応する条件ＩＤ１３１の操作によって注文情報１２０が変更された結果を保存するものである。
【００６１】
図９は、注文情報作成時に購買者端末２００に表示される注文情報作成画面１０００の例である。
【００６２】
注文情報作成画面は、注文情報１１００、注文条件１２００で構成される。
【００６３】
注文情報１１００は、注文する商品の情報を指定するものである。
【００６４】
注文条件１２００は、前記１１００の注文情報に対する注文時の条件を指定するものであり、０個以上の条件定義１２１０〜１２ｍ０（ｍは０以上の任意の整数）で構成される。
【００６５】
さらに、条件定義１２１０〜１２ｍ０は、前記１１００で指定した商品の情報が変更された場合に、変更の内容に応じて注文情報を変更する条件および変更の内容を指定するものであり、商品ＩＤ１２１１、条件１２１２、操作１２１３、商品ＩＤ１２１４、改定番号１２１５、販売者ＩＤ１２１６、単価１２１７、数量１２１８で構成される。
【００６６】
商品ＩＤ１２１１は、商品ＩＤ１１０１に対応し、注文情報１１００で注文した商品の内、どの商品に対する条件定義かを指定するものである。
【００６７】
条件１２１２は、商品ＩＤ１１０１で指定した商品の変更の内容を定義するものであり、商品情報１１０の変更内容が条件１２１２と一致する場合に、操作１２１３を実行する。
【００６８】
本発明にて条件１２１２に対し、特に記述方法を規定するものではないが、本実施例おいては「単価≦３０００」、「単価＞３０００」、「販売終了」を例に挙げている。「単価≦３０００」は、商品の単価が３０００円以下の場合を示している。「単価＞３０００」は、商品の単価が３０００円より大きいの場合を示している。「販売終了」は、商品の販売が終了した場合を示している。
【００６９】
本発明にて操作１３１３対し、特に記述方法を規定するものではないが、本実施例おいては「継続」、「変更」、「取消」を例に挙げている。「継続」は、同一商品を購入することを示している。すなわち、改定番号１２３のみを販売中の商品に変更することを示している。「変更」は、商品ＩＤ１２１４、改定番号１２１５、販売者ＩＤ１２１６、単価１２１７、数量１２１８で指定した、代替の注文情報へ変更することを示している。「取消」は、注文を取り消すことを示している。
【００７０】
次に図１、図３、図４、図５、図６、図７、図８、図９を引用しながら、図２のフロー図に基づいて、本実施形態の処理動作を説明する。
【００７１】
ステップ１０１００の前に、まず購買者が購買者端末２００より受発注管理サーバー１００に対して、注文作成を依頼すると、商品情報管理部１６０は、商品情報１１０の情報を購買者端末２００へ送信する。購買者は送信された商品情報を元に、注文する商品を選択し、注文する数量など注文情報を指定する。また、購買者は同時に注文する商品の価格などの情報が変更された場合に、注文情報の変更条件および変更方法を定義する注文条件指定し、受発注サーバー１００へ送信する。
【００７２】
以下、図９の注文情報作成画面１０００の例を元に、ステップ１０１００の動作を具体的に説明する。
【００７３】
注文情報１１００では、商品ＩＤが００１、改定番号が５である商品を３個指定している。また、注文条件１２００では、条件定義１２１０として、商品ＩＤ１２１８が００１である商品の単価が３０００円以下に変更された場合、変更後の価格に変更して注文を継続することを示している。条件定義１２２０では、商品ＩＤ１２１８が００１である商品の単価が３０００円を超えた場合、商品ＩＤが００２、改定番号が３である商品を２個注文するよう注文情報を変更することを示している。条件定義１２ｍ０では、商品ＩＤ１２１８が００１である商品が販売終了になった場合、注文を取り消すことを示している。
【００７４】
ステップ１０１００では、購買者から受信した注文情報作成画面１０００の情報を、注文情報管理部１７０が注文情報１２０および注文条件１３０へ登録する。詳細は、図３の注文登録のフロー図を元に説明する。
【００７５】
ステップ１０１０１では、注文情報管理部１７０は、注文情報作成画面１０００の情報を購買者端末２００より受信し、注文情報１１００が有効かどうか、検査する。具体的には、商品情報情報管理部１６０を通じ商品情報１１０を検索し、商品ＩＤ１１０１、改定番号１１０２、販売者ＩＤ１１０３、単価１１０４が商品情報１１０の商品ＩＤ１１１、改定番号１１２、販売者ＩＤ１１４、単価１１３と一致するか、さらに有効期間１１５内であるかなどを確認する。注文情報１１００が有効である場合はステップ１０１０２へ、無効である場合はステップ１０１１４へ進み注文情報の登録を中止し終了する。
【００７６】
ステップ１０１０２では、注文情報管理部１７０は、注文情報１１００の商品ＩＤ毎に注文ＩＤを採番し、ステップ１０１０３へ進む。
【００７７】
ステップ１０１０３では、注文情報管理部１７０は、注文条件１２００が存在するかどうか確認する。注文条件１２００が存在した場合はステップ１０１０４へ進み、存在しない場合はステップ１０１１３へ進む。
【００７８】
ステップ１０１０４では、注文情報管理部１７０は、注文条件１２００の先頭の条件定義１２ｍ０（ｍは自然数）を読み込む。
【００７９】
ステップ１０１０５では、注文情報管理部１７０は、商品情報管理部１６０を通じ商品情報１１０を検索し、ステップ１０１０４で読み込んだ条件定義１２ｍ０（ｍは自然数）が有効かどうか確認する。具体的には条件１２１２において範囲設定が有効であるか、または商品ＩＤ１２１４、改定番号１２１５、販売者ＩＤ１２１６、単価１２１７が商品情報１１０の商品ＩＤ１１１、改定番号１１２、販売者ＩＤ１１４、単価１１３と一致するか、さらに有効期間１１５の範囲内であるかなどを確認する。有効である場合は、ステップ１０１０６へ進み、無効の場合はステップ１０１１４へ進み注文情報の登録を中止し終了する。
【００８０】
ステップ１０１０６では、注文情報管理部１７０は、条件定義１２ｍ０（ｍは自然数）に条件ＩＤを採番し、ステップ１０１０７へ進む。
【００８１】
ステップ１０１０７では、注文情報管理部１７０は、条件定義１２ｍ０（ｍは自然数）に代替注文情報である商品ＩＤ１２１４、改定番号１２１５、販売者ＩＤ１２１６、単価１２１７、数量１２１８が存在するか確認し、存在した場合は、ステップ１０１０８へ進み、存在しない場合は、ステップ１０１１０へ進む。
【００８２】
ステップ１０１０８では、注文情報管理部１７０は、代替の注文情報に対し注文ＩＤを採番し、ステップ１０１０９へ進む。
【００８３】
ステップ１０１０９では、注文情報管理部１７０は、代替の注文情報を注文情報１２０へ登録し、ステップ１０１１０へ進む。具体的には、ステップ１０１０８で採番した注文ＩＤを注文情報１２０の注文ＩＤ１２１へ、商品ＩＤ１２１４を商品ＩＤ１２２へ、改定番号１２１５を改定番号１２３へ、販売者ＩＤ１２１６を販売者ＩＤ１２４へ、購買者ＩＤを購買者ＩＤ１２５へ、単価１２１７を単価１２６へ、数量１２１８を数量１２７へ、状態１２８に「注文代替」をそれぞれ登録する。
【００８４】
ステップ１０１１０では、注文情報管理部１７０は、条件定義１２ｍ０（ｍは自然数）を注文条件１３０へ登録し、ステップ１０１１１へ進む。具体的には、ステップ１０１０６で採番した条件ＩＤを条件ＩＤ１３１へ、ステップ１０１０１で採番した注文ＩＤを注文ＩＤ１３２へ、商品ＩＤ１２１１を商品ＩＤ１３３へ、条件１２１２を条件１３４へ、操作１２１３を操作１３５へ登録する。さらに、ステップ１０１０８で代替注文ＩＤを採番している場合、代替注文ＩＤ１３６へ登録する。
【００８５】
ステップ１０１１１では、注文情報管理部１７０は、注文条件１２２０に次の条件定義１２ｍ０（ｍは自然数）が存在するか確認し、存在する場合はステップ１０１１２へ、存在しない場合はステップ１０１１３へ進む。
【００８６】
ステップ１０１１２では、注文情報管理部１７０は、注文条件１２２０の次の条件定義１２ｍ０（ｍは自然数）を読み込み、ステップ１０１０５へ進む。
【００８７】
ステップ１０１１３では、注文情報管理部１７０は、注文情報１１００を注文情報１２０へ登録し、ステップ１０２００へ進む。
【００８８】
具体的には、ステップ１０１０２で採番した注文ＩＤを注文ＩＤ１２１へ、商品ＩＤ１１０１を商品ＩＤ１２２へ、改定番号１１０２を改定番号１２３へ、単価１１０４を単価１１３へ、販売者ＩＤ１１０３を販売者ＩＤ１２４へ、購買者ＩＤを購買者ＩＤ１２５へ、単価１１０４を単価１２６へ、数量１１０５を数量１２７へ、状態１２８に「注文受付」をそれぞれ登録する。
【００８９】
ステップ１０１１４では、注文情報管理部１７０がステップ１０１０２で採番した注文ＩＤ、ステップ１０１０６で採番した条件ＩＤをすべて破棄し、登録を中止し、ステップ１０２００へ進む。
【００９０】
ここで、図２の処理フロー図に戻り、ステップ１０２００より説明を続ける。
【００９１】
ステップ１０２００では、注文情報管理部１０７はステップ１０１００において注文情報１２０の登録が成功したかを確認し、登録が成功していればステップ１０３００へ進み、登録が失敗していれば処理を終了する。
【００９２】
ステップ１０３００では、商品情報管理部１０６は販売者が販売者端末３００より商品情報管理部１０６を通じて商品情報１０１が変更されたかどうかを確認し、商品情報１０１が変更されていればステップ１０５００へ進み、変更されていなければステップ１０４００へ進む。
【００９３】
ステップ１０４００では、商品情報管理部１６０は商品情報１１０を検索し、有効期間１１５が終了した商品情報１１０が存在するか検索する。有効期間１１５を終了した商品が存在する場合は、ステップ１０５００へ進み、存在しない場合はステップ１０８００へ進む。
【００９４】
ステップ１０５００では、販売者による商品情報１１０の変更や、商品情報１１０の有効期限切れなどにより、無効になっている注文情報１２０が存在しないかを確認する。
【００９５】
詳細を図４の注文情報の有効性確認フロー図を元に説明する。
【００９６】
ステップ１０５０１では、注文情報管理部１７０は、先頭の注文情報１２０を読み込んで、ステップ１０５０２へ進む。
【００９７】
ステップ１０５０２では、注文情報管理部１７０は、読み込んだ注文情報１２０が変更可能であるかを確認する。具体的には、状態１２８が「注文確定」または「注文取消」である場合は、注文情報１２０は変更不可能であるので、ステップ１０５０８へ進み、状態１２８が「注文確定」または「注文取消」以外である場合は、注文情報１２０は変更可能であるので、ステップ１０５０３へ進む。
【００９８】
ステップ１０５０３では、注文情報管理部１７０は、注文情報１２０で注文している商品が有効期限内であるか確認する。具体的には、商品情報管理部１６０を通じて、商品ＩＤ１２２と商品ＩＤ１１１、改定番号１２３と改定番号１１２が一致する商品情報１１０を検索し、現在日時が当該商品情報１１０の有効期限１１５の範囲に含まれるかどうかを確認する。現在日時が有効期限１１０の範囲内である場合は、注文情報が有効であるので、ステップ１０５０８へ進み、現在日時が有効期限１１０の範囲外である場合は、注文情報が無効であるので、ステップ１０５０４へ進む。
【００９９】
ステップ１０５０４では、注文情報管理部１７０は、注文情報１２０に対する注文条件１３０が存在するかどうか確認する。具体的には、注文ＩＤ１２１と注文ＩＤ１３２、商品ＩＤ１２２と商品ＩＤ１３３が一致する注文条件１３３が存在するかを確認し、存在すればステップ１０５０５へ進み、存在しなければステップ１０５１０へ進む。
【０１００】
ステップ１０５０５では、注文情報管理部１７０は、ステップ１０５０４で検索した注文条件１３０の操作１３５が有効であるか確認し、有効であればステップ１０５０６へ進み、無効であればステップ１０５１０へ進む。無効な操作としては、販売を終了した商品に対する発注継続や、注文情報変更などがある。
【０１０１】
ステップ１０５０６では、注文情報管理部１７０は、操作１３５を実行し、ステップ１０５０７へ進む。
【０１０２】
具体的には、操作１３５が「継続」である場合、商品情報管理部１６０により商品ＩＤ１１１が商品ＩＤ１２２と一致し、かつ現在日時が有効期間１１５の範囲内にある商品情報１１０を検索し、注文情報１２０の改定番号１２３を前記検索結果の改定番号１１２へ変更する。
【０１０３】
また、操作１３５が「変更」である場合、注文情報管理部１７０は注文ＩＤ１３２でかつ商品ＩＤ１３３である注文情報１２０を、注文代替ＩＤ１３６である注文情報１２０へと変更する。
【０１０４】
さらに、操作１３５が「取消」である場合、注文情報管理部１７０は注文情報１３２でかつ商品ＩＤ１３３である注文情報１２０の状態１２８を注文取消とする。
【０１０５】
ステップ１０５０７では、注文情報管理部１７０は、ステップ１０５０６またはステップ１０５１０における注文情報１３０への操作１３５の実行結果として、注文ＩＤ１３２を注文ＩＤ１４１へ、商品ＩＤ１３３を商品ＩＤ１４２へ、条件ＩＤ１３１を条件ＩＤ１４３へ、実行結果を１４４へ保存し、ステップ１０５１１へ進む。
【０１０６】
図８は、ステップ１０５０７における更新結果１４０の登録例である。
【０１０７】
ステップ１０５１１では、注文情報管理部１７０は、更新結果１４０を購買者および販売者へ通知し、ステップ１０５０８へ進む。
【０１０８】
具体的には、注文ＩＤ１４１と注文ＩＤ１２１、商品ＩＤ１４２と商品ＩＤ１２２がそれぞれ一致する注文情報１２０を検索し、当該販売者ＩＤ１２４および購買者ＩＤ１２５に対して、更新結果１４０を通知する。
【０１０９】
通知の方法に関しては、購買者および販売者が受発注管理サーバー１００へアクセス時に画面に表示する方法や、更新実施時に購買者および販売者に電子メールによる通知する方法などがあるが、本発明において特に特定するものではない。
【０１１０】
ステップ１０５０８では、注文情報管理部１７０は、注文情報１３０に次の注文情報が存在するか検索し、存在した場合はステップ１０５０９へ進み、存在しない場合は処理を終了し、ステップ１０６００へ進む。
【０１１１】
ステップ１０５０９では、注文情報管理部１７０は、次の注文情報１３０を読み込み、ステップ１０５０２へ進む。
【０１１２】
ステップ１０５１０では、注文情報管理部１７０は、注文情報１２０の状態１２８を注文無効としステップ１０５０７へ進む。
【０１１３】
ここで、図２の処理フロー図に戻り、ステップ１０８００より説明を続ける。
【０１１４】
ステップ１０８００では、注文情報管理部１７０は、注文情報１３０に対する注文確定要求がきているか確認する。注文確定要求は、購入者が購入者端末２００を通じて注文情報管理部１７０へ行う場合や、また販売者が販売者端末３００を通じて注文情報管理部１７０へ行う場合があり、本実施例において注文確定要求の行い方は規定しない。
【０１１５】
注文情報管理部１７０は注文確定要求を受けると、注文情報１２０から該当する注文情報を検索し、状態１２８を注文確定へ変更し、処理を終了する。また、注文確定要求を受けていない場合は、ステップ１０９００へ進む。
【０１１６】
ステップ１０９００では、注文情報管理部は、購入者が購入者端末２００を通じて注文取消要求がきているか確認する。注文取消要求がきている場合は、処理を終了し、注文取消要求がきていない場合はステップ１０３００へ進む。
【０１１７】
本実施例において販売者と購買者の間に仲介者が入り、受発注管理サーバー１００運営するとしたが、販売者が単独で受発注管理サーバー１００運営することも可能である。
【０１１８】
しかし、本実施例の場合には、注文条件を販売者に通知せずに仲介者が管理することにより、販売者の不当な値上げを防ぐことが可能となる。具体的には、注文条件としてＡ商品が３０００円を超えた場合に注文取り消すといった条件を定義した場合、本条件を直接販売者へ通知した場合、販売者は本条件を確認し、３０００円へ不当に値上げし最大の利益を売ることも可能であるが、実施例に示すのように仲介者が受発注管理サーバー１００を運営した場合、注文条件を販売者に公開しないことにより、前記不当な値上げや購買者の予算の情報の流出を防ぐことが可能となる。尚、受発注管理サーバは、購買者側にあってもよいし、販売者側にあってもよいし、購買者と販売者を仲介する仲介者側にあってもよい。
【０１１９】
【発明の効果】
本発明によれば、商品の注文時に注文後の注文情報の変更手順をあらかじめ定義できるため、注文後の商品情報変更による販売者から購買者への通知や、購買者の注文処理のやり直しを防止し、これによって販売者と購買者の双方又は一方の負担を低減することが可能となる。
【図面の簡単な説明】
【図１】本発明の実施の形態を実現するための受発注管理サーバーのモジュール構成を含む受発注管理システムの全体構成図である。
【図２】本発明の実施の形態を示す処理フロー図である。
【図３】図２のステップ１０１００の詳細処理フロー図である。
【図４】図２のステップ１０５００の詳細処理フロー図である。
【図５】商品情報１１０のテーブル構成図である。
【図６】注文情報１２０のテーブル構成図である。
【図７】注文条件１３０のテーブル構成図である。
【図８】更新結果１４０のテーブル構成図である。
【図９】注文情報作成時に購買者端末２００に表示される注文情報作成画面１０００の例である。
【符号の説明】
１０１００…注文登録のステップ、１０２００…注文登録成功か否かのステップ、１０３００…商品情報変更か否かのステップ、１０４００…有効期限を終了した商品が存在するか否かのステップ、１０５００…注文情報の有効性確認のステップ、１０８００…注文確定か否かのステップ、１０９００…注文取消か否かのステップ。

Claims

商品の注文情報を登録する場合に、注文商品の商品情報が変更された場合の代替注文の条件を定めた注文条件を登録し、注文後に前記商品情報が変更されたことを検出し、変更された前記商品情報を含む注文情報を検索し、前記注文条件に従い注文情報を変更することを特徴とする受発注管理方法。
請求項１において、商品情報の有効期限を管理し、当該有効期限が終了した場合に前記有効期限が終了した商品情報を含む注文情報を検索し、前記注文条件に従い注文情報を変更することを特徴とする受発注管理方法。
請求項１および請求項２において、注文情報の変更結果を管理し、当該注文情報における販売者または購買者に対し変更結果を通知することを特徴とした受発注管理方法。
商品の注文情報と注文商品の商品情報が変更された場合の代替注文の条件を定めた注文条件を登録する手段と、前記注文情報に含まれる商品情報の有効性を検査する手段と、前記注文情報が無効になった場合に前記注文条件に従って前記注文情報を変更する手段と、前記注文情報の変更結果を管理する手段と、前記注文情報における販売者または購買者に対し変更結果を通知する手段とを有することを特徴とする受発注管理装置。