(57)【要約】【課題】規定数の注文を確実に受注すること。【解決手段】ワンオーダー制が利用される場合に、客の人数に基づいて定められたワンオーダーの数をワンオーダータスクとして部屋状態データ１３に記憶し、注文された商品がワンオーダーの対象であるか否かをメニューマスタ１３ｂを参照して判定し、注文されたワンオーダー対象商品の数をワンオーダー数として計数し、ワンオーダー数とワンオーダータスクとの比較によって必要な数の注文がなされたか否かを判定する。【選択図】      図１
2004302887.tif 000002
【特許請求の範囲】
【請求項１】
人数によって定まる所定数の注文を受注することを前提に提供されるサービスにおいて前記注文の数を管理する注文管理プログラムであって、
前記人数を取得する人数取得手順と、
前記注文の履歴を記憶し、該注文履歴と前記人数取得手順によって取得した人数とをもとに、前記所定数の注文を受注したか否かを監視する注文数監視手順と、
前記注文数監視手順による監視の結果、受注した注文数が前記所定数に満たない場合に警告を出力する警告手順と、
をコンピュータに実行させることを特徴とする注文管理プログラム。
【請求項２】
前記注文数監視手順は、所定時間間隔で該注文数の監視を繰り返すことを特徴とする請求項１に記載の注文管理プログラム。
【請求項３】
人数によって定まる所定数の注文を受注することを前提に提供されるサービスにおいて前記注文の数を管理する注文管理方法であって、
前記人数を取得する人数取得工程と、
前記注文の履歴を記憶し、該注文履歴と前記人数取得工程によって取得した人数とをもとに、前記所定数の注文を受注したか否かを監視する注文数監視工程と、
前記注文数監視工程による監視の結果、受注した注文数が前記所定数に満たない場合に警告を出力する警告工程と、
を含むことを特徴とする注文管理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、人数によって定まる所定数の注文を受注することを前提に提供されるサービスにおいて前記注文の数を管理する注文管理プログラムおよび注文管理方法に関し、特に、人数によって定まる所定数の注文を確実、かつ早期に受注することのできる注文管理プログラムおよび注文管理方法に関する。
【０００２】
【従来の技術】
近年、異なる種類のサービスを複合して提供するサービス形態が増加している。例えば、カラオケボックスでは、歌を歌う為の個室を提供し、楽曲を提供するとともに個室内での飲食物をも提供している。
【０００３】
このように異なる種類のサービスを提供する場合に、それぞれのサービスを一元的に管理するため、特許文献１に示されたクライアントサーバ型カラオケＬＡＮシステムでは、楽曲の選択と飲食物の注文とを同一の手順でおこなうシステムを構築している。
【０００４】
【特許文献１】
特開平１０−１６１６７０号公報
【０００５】
【発明が解決しようとする課題】
ところで、異なる種類のサービスを複合して提供する場合、必ずしもそれぞれのサービスで利益をあげる必要はなく、提供するサービス全体で利益をあげるように料金を設定する場合がある。たとえば、カラオケボックスでは、客の一人一人が飲食物を注文することを前提とし、個室の部屋代や、楽曲の提供料金を低めに設定することがある。
【０００６】
このように、客のそれぞれが最低一つの注文を行うことを義務付けた料金システムは、一般に「ワンオーダー制」と呼ばれる。また、ワンオーダー制に用いられるメニューを提供可能なメニューの一部、例えば飲み物に限定する場合（ワンドリンク制）もある。この場合であれば、客が注文した食べ物は、ワンオーダー制の数としてカウントされず、客のそれぞれは何らかの飲み物を注文することが義務付けられる。
【０００７】
このワンオーダー制は、総合的な料金の安さから、ユーザに広く受け入れられているものの、客の人数を把握し、人数分の注文を受けたことの確認をしなければならないという繁雑さがある。
【０００８】
従来、このワンオーダー制などにおける注文数の管理は、従業員に一任されており、自動化されていなかった。しかし、上述したように、この注文数の管理は非常に労力を必要とし、また、管理が十分になされていない場合には、必要な注文が足りないことを見過ごすという問題が生じていた。このような注文不足の見過ごしは、飲食物の料金で利益を確保するサービス形態において、大きな損失を生ずることとなる。
【０００９】
すなわち、従来の注文管理では、複合的なサービスにおける注文を自動的に管理することができず、結果として損失を発生するという問題点があった。そこで近年、このような複合的な注文管理を自動化し、必要な数の注文を確実、かつ早期に受注することのできる注文管理プログラムおよび注文管理方法が求められていた。
【００１０】
この発明は、上述した従来技術による問題点を解消するためになされたものであり、複合的な注文管理を自動化し、特に、人数によって定まる所定数の注文を確実、かつ早期に受注することのできる注文管理プログラムおよび注文管理方法を提供することを目的とする。
【００１１】
【課題を解決するための手段】
上述した課題を解決し、目的を達成するため、請求項１の発明に係る注文管理プログラムは、人数によって定まる所定数の注文を受注することを前提に提供されるサービスにおいて前記注文の数を管理する注文管理プログラムであって、前記人数を取得する人数取得手順と、前記注文の履歴を記憶し、該注文履歴と前記人数取得手順によって取得した人数とをもとに、前記所定数の注文を受注したか否かを監視する注文数監視手順と、前記注文数監視手順による監視の結果、受注した注文数が前記所定数に満たない場合に警告を出力する警告手順と、をコンピュータに実行させることを特徴とする。
【００１２】
この請求項１の発明によれば、注文管理プログラムは、注文履歴と人数とをもとに、人数によって定まる所定数の注文を受注したか否かを監視し、受注した注文数が所定数に満たない場合に警告を発する。
【００１３】
また、請求項２の発明に係る注文管理プログラムは、請求項１の発明において、前記注文数監視手順は、所定時間間隔で該注文数の監視を繰り返すことを特徴とする。
【００１４】
この請求項２の発明によれば、注文管理プログラムは、人数によって定まる所定数の注文を受注したか否かを所定時間間隔で監視し、受注した注文数が所定数に満たない場合に警告を発する。
【００１５】
また、請求項３の発明に係る注文管理方法は、人数によって定まる所定数の注文を受注することを前提に提供されるサービスにおいて前記注文の数を管理する注文管理方法であって、前記人数を取得する人数取得工程と、前記注文の履歴を記憶し、該注文履歴と前記人数取得工程によって取得した人数とをもとに、前記所定数の注文を受注したか否かを監視する注文数監視工程と、前記注文数監視工程による監視の結果、受注した注文数が前記所定数に満たない場合に警告を出力する警告工程と、を含むことを特徴とする。
【００１６】
この請求項３の発明によれば、注文管理方法は、注文履歴と人数とをもとに、人数によって定まる所定数の注文を受注したか否かを監視し、受注した注文数が所定数に満たない場合に警告を発する。
【００１７】
【発明の実施の形態】
以下に添付図面を参照し、この発明に係る注文管理プログラムおよび注文管理方法の好適な実施の形態として、カラオケボックス用の注文管理システムについて説明する。
【００１８】
図１は、本実施の形態にかかるカラオケボックス用の注文管理システムの概要構成を説明する概要構成図である。図１に示すように、注文管理システム１は、入力部１１、表示部１４、制御部１２および記憶部１３を有する。
【００１９】
ここで、入力部１１は、キーボードやマウスなどの入力デバイスであり、表示部１４は、液晶ディスプレイやＣＲＴなどの表示デバイスである。
【００２０】
また、制御部１２は、その内部に入室処理部２１、注文処理部２２、退室処理部２３を有する。入室処理部２１は、カラオケボックスに客が来た際に、使用する部屋、使用する人数、利用する料金コースなどを入力し、入室伝票を発行する処理をおこなう。また、注文処理部２２は、客から飲食物などの注文を受けた際に、注文内容を記憶部１３に格納するとともに、その注文内容を管理する処理をおこなう。さらに、退室処理部２３は、客が利用を終了した場合に、部屋の使用料金、楽曲の提供料金、および提供した飲食物の料金の合計金額を算出し、会計伝票を発行する処理などをおこなう。
【００２１】
より詳細には、注文処理部２２は、その内部に注文量監視部２２ａ、警告処理部２２ｂを有する。注文量監視部２２ａは、料金コースが「ワンオーダー制」である場合に、ワンオーダーに該当する注文数を監視し、部屋の利用人数と比較することで、義務付けられた数量の注文が済んでいるか否かを判定する。警告処理部２２ｂは、注文量監視部２２ａによる監視の結果、注文量が義務付けられた数量に達していない場合に、警告を発する処理をおこなう。この警告は、店舗の従業員に対して警告を表示し、従業員が客に対して督促をおこなうようにしても良いし、各部屋に設けたディスプレイに表示することとしても良い。
【００２２】
記憶部１３は、注文状態データ１３ａ、メニューマスタ１３ｂ、部屋マスタ１３ｃ、料金マスタ１３ｄおよび部屋状態データ１３ｅを記憶する。注文状態データ１３ａは、各部屋について、ワンオーダー制を利用しているか否か、ワンオーダーに該当するメニューをどれだけ注文したか、部屋を何人で利用しているか、を示すデータである。また、メニューマスタ１３ｂは、店舗で提供している品目に関する情報を示すデータであり、部屋マスタ１３ｃは、各部屋に関する情報を示すデータである。さらに料金マスタ１３ｄは、料金コースに関する情報を示すデータであり、部屋状態データ１３ｅは、各部屋の利用状況を示すデータである。
【００２３】
この記憶部１３に記憶する情報の具体例を図２に示す。図２（ａ）は、注文状態データ１３ａの具体例である。同図に示すように、注文状態データ１３ａは、「ルームＮｏ．」、「部屋名」、「ワンオーダー対象フラグ」、「オーダーカウンタ」、「人数」の各項目を有する。項目「ルームＮｏ．」は、各部屋に固有に割り当てた番号であり、部屋を特定するために使用する。項目「部屋名」は、部屋に与えられた名称を示す項目である。
【００２４】
一方、項目「ワンオーダー対象フラグ」は、その部屋の使用にあたり、ワンオーダー制を利用しているか否かを識別するためのフラグである。具体的には、部屋の使用に際し、ワンオーダー制を利用していれば項目「ワンオーダー対象フラグ」の値を「０」にセットし、ワンオーダー制を利用していなければ項目「ワンオーダー対象フラグ」の値を「１」にセットする。
【００２５】
さらに、項目「オーダーカウンタ」は、その部屋において注文されたワンオーダー対象メニューの数を示すデータである。また、項目「人数」は、その部屋における利用人数を示している。
【００２６】
図２（ｂ）は、メニューマスタ１３ｂの具体例である。同図に示すように、メニューマスタ１３ｂは、「メニューＮｏ．」、「メニュー名」、「単価」、「ワンオーダー対象フラグ」の各項目を有する。項目「メニューＮｏ．」は、各メニューに固有に割り当てた番号であり、メニューを特定するために使用する。項目「メニュー名」は、そのメニューの名称を示す項目であり、項目「単価」は、そのメニューの単価を示す項目である。
【００２７】
一方、項目「ワンオーダー対象フラグ」は、そのメニューがワンオーダーの対象であるか否かを識別するためのフラグである。具体的には、そのメニューがワンオーダーの対象であれば項目「ワンオーダー対象フラグ」の値を「０」にセットし、そのメニューがワンオーダーの対象でなければ「ワンオーダー対象フラグ」の値を「１」にセットする。
【００２８】
すなわち、ワンオーダー制を利用している客は、このワンオーダー対象フラグの値が「０」であるメニューから一品ずつ注文する必要がある。仮に、客が飲み物から一品ずつ注文するワンオーダー制（ワンドリンク制）であれば、メニューのうち飲み物に対するワンオーダー対象フラグの値が「０」、食べ物に対するワンオーダー対象フラグの値が「１」となっている。そのため、食べ物をどれだけ注文したとしてもワンオーダー制に規定された注文数を満たしたことにならず、飲み物を所定の数だけ注文しなければならないこととなる。
【００２９】
図２（ｃ）は、部屋マスタ１３ｃの具体例である。同図に示すように部屋マスタ１３ｃは、「ルームＮｏ．」、「部屋名」、「料金体系」の各項目を有する。項目「ルームＮｏ．」および「部屋名」は、注文状態データ１３ａと同様に、各部屋に固有に割り当てた番号と、部屋に与えられた名称とを示す項目である。
【００３０】
一方、項目「料金体系」は、その部屋の料金をどのように算出するかを示す項目である。カラオケボックスなどでは、部屋単位に料金を設定する場合と、利用人数によって料金を設定する場合があるので、その部屋をどちらの料金体系で利用しているのかをこの項目によって定めている。
【００３１】
図２（ｄ）は、料金マスタ１３ｄの具体例である。同図に示すように、料金マスタ１３ｄは、「ルームＮｏ．」、「料金」、「該当曜日」、「時間帯区分」の各項目を有する。項目「ルームＮｏ．」は、注文状態データ１３ａと同様に、各部屋に固有に割り当てた番号であり、部屋の特定に使用する。また、項目「料金」は、項目「該当曜日」および項目「時間帯区分」によって定まる料金を示す項目である。
【００３２】
カラオケボックスなどのように、曜日や時間帯によって来客数が大きく変動する業種では、曜日や時間帯によって異なる料金を設定している場合がある。例えば、平日は利用者数が少なく、休日は利用者数が多いので、平日の料金は休日の料金に比して低く設定されている。また、日中の利用者数は、夜間の利用者数に比して低く設定している。この料金マスタ１３ｄでは、この曜日および時間帯から、料金が定まるように設定している。なお、曜日および時間帯が同一であっても、複数の料金コースから所望の料金体系を選択できるように、曜日および時間帯に対して複数の料金を設定しても良い。
【００３３】
図２（ｅ）は、部屋状態データ１３ｅの具体例である。同図に示すように、部屋状態データ１３ｅは、「ルームＮｏ．」、「入室時間」、「退室予定時間」、「ワンオーダーノルマ」、「ワンオーダー数」、「人数」の各項目を有する。項目「ルームＮｏ．」は、注文状態データ１３ａと同様に、各部屋に固有に割り当てた番号であり、部屋の特定に使用する。項目「入室時間」は、客が入室した時間を示すデータであり、項目「退室予定時間」は、客が退室を予定している時間である。カラオケボックスなどでは、客が入室する際に利用時間を予め選択することが一般的である。退室予定時間は、利用者が入室時に選択した利用時間を入力することで、料金管理や、待ち時間の管理、退室時間が近づいた場合の警告などに使用できる。
【００３４】
また、項目「ワンオーダーノルマ」は、客が注文すべきワンオーダーの数量を示す値である。さらに、項目「ワンオーダー数」は、その部屋において注文されたワンオーダー対象メニューの数を示すデータであり、項目「人数」は、その部屋における利用人数を示している。すなわち、項目「ワンオーダー数」の値が項目「ワンオーダーノルマ」の値に満たなければ、その部屋の客は義務付けられたワンオーダーを未だ注文していないことが分かる。なお、項目「ワンオーダーノルマ」の値は項目「人数」によって定まり、その部屋の客の全員がワンオーダー制を用いて利用しているならば、項目「ワンオーダーノルマ」の値は項目「人数」の値と等しくなる。
【００３５】
つぎに、制御部１２における処理動作について説明する。図３は、入室処理部２１の処理動作を説明するフローチャートである。同図に示すように、新規に客が訪れたならば、入室処理部２１は、まず入室処理をおこなう（ステップＳ１０１）。この入室処理は、具体的には、客の人数、利用する部屋、入室時間、退室時間および料金コースを入力する処理である。
【００３６】
つぎに、入室処理部２１は、入力された料金コースがワンオーダー制を利用しているか否かを判定する（ステップＳ１０２）。入力された料金コースがワンオーダー制を利用していないならば（ステップＳ１０２，Ｎｏ）、入室処理部２１は、注文状態データ１３ａのワンオーダー対象フラグを「１」にセットし（ステップＳ１１０）、非ワンオーダー制での入室伝票を発行して（ステップＳ１１０）、処理を終了する。
【００３７】
一方、入力された料金コースがワンオーダー制を利用しているならば（ステップＳ１０２，Ｙｅｓ）、入室処理部２１は、注文状態データ１３ａのワンオーダー対象フラグを「０」にセットし（ステップＳ１０３）、ワンオーダー制での入室処理伝票を発行する（ステップＳ１０４）。その後、入室処理部２１は、部屋状態データ１３ｅのワンオーダーノルマに人数をセットするとともに、ワンオーダー数に「０」をセットする（ステップＳ１０５）。
【００３８】
その後、入室処理部２１は、その部屋のワンオーダー状態、すなわちワンオーダーノルマおよびワンオーダー数を表示部１４に表示して（ステップＳ１０６）処理を終了する。
【００３９】
つぎに、注文処理部２２の処理動作について説明する。図４は、注文処理部２２の処理動作を説明するフローチャートである。同図に示すように、ワンオーダー制で利用している部屋から新規に注文を受けたならば、注文処理部２２は、まず、発注元であるワンオーダー制で入室中の部屋を選択し（ステップＳ２０１）、注文された品（オーダー）を入力する（ステップＳ２０２）。
【００４０】
その後、注文処理部２２は、メニューマスタ１３ｂを参照し、注文された品がワンオーダーの対象であるか否か、すなわちワンオーダー対象フラグの値が「０」であるか否かを判定する（ステップＳ２０３）。
【００４１】
注文された品がワンオーダーの対象でなければ（ステップＳ２０３，Ｎｏ）、注文処理部２２は、通常メニューの販売処理をおこない（ステップＳ２１１）、注文された品を明細に追加して（ステップＳ２１２）、処理を終了する。
【００４２】
一方、注文された品がワンオーダーの対象であれば（ステップＳ２０３，Ｙｅｓ）、注文処理部２２は、ワンオーダー対象メニューの販売処理をおこない（ステップＳ２０４）、その後、注文量監視部２２ａによって部屋状態データ１３ｅのワンオーダー数がワンオーダーノルマ以上であるか否かを判定する（ステップＳ２０５）。
【００４３】
ワンオーダー数がワンオーダーノルマ以上である場合（ステップＳ２０５，Ｙｅｓ）、必要な数のワンオーダーを既に受けているので、その部屋のワンオーダーの状態は表示しない（ステップＳ２０６）。しかし、ワンオーダー数がワンオーダーノルマ未満である場合（ステップＳ２０５，Ｎｏ）、必要な数のワンオーダーを未だ受けていないので、警告処理部２２ｂによってその部屋から受けるべき残りのワンオーダー数を表示部１４に表示し、（ステップＳ２２１）、従業員に不足分の督促を促す。
【００４４】
ステップＳ２０６終了後、もしくはステップＳ２２１終了後、注文処理部２２は、今回受注した分だけワンオーダー数を加算して（ステップＳ２０７）、処理を終了する。なお、このステップＳ２０７の処理によってワンオーダー数がワンオーダーノルマを満たした場合には、その旨を表示部１４に表示することとしてもよい。
【００４５】
ところで、ワンオーダー数の監視は、新たに注文を受けた場合のみならず、定期的におこなうことが望ましい。そこで、注文処理部２２は、定期的に注文量の監視をおこなう処理を起動する。図５は、注文処理部２２の定期的な処理動作を説明するフローチャートである。同図に示すように、注文管理部２２は、まず、時刻情報および各部屋の入室時間を取得する（ステップＳ３０１）。つづいて、注文処理部２２は、各部屋の入室時間から所定時間が経過しているか否かを判定する（ステップＳ３０２）。
【００４６】
その後、注文量監視部２２ａが、入室時間から所定時間が経過している（ステップＳ３０２，Ｙｅｓ）部屋について、ワンオーダー数がワンオーダーノルマ未満であるか否かを判定する（ステップＳ３０３）。ワンオーダー数がワンオーダーノルマ未満である場合（ステップＳ３０３，Ｙｅｓ）、注文処理部２２は、警告処理部によってワンオーダーの販促を指示する警告を表示部１４に表示して（ステップＳ３０４）処理を終了する。
【００４７】
一方、入室時間から所定時間が経過していない場合（ステップＳ３０２，Ｎｏ）およびワンオーダー数がワンオーダーノルマを満たしている場合（ステップＳ３０３，Ｎｏ）、注文処理部２２は警告を表示せずに処理を終了する。
【００４８】
上述してきたように、本実施の形態にかかる注文管理システムでは、ワンオーダー制が利用される場合に、客の人数に基づいて定められたワンオーダーの数をワンオーダータスクとして部屋状態データ１３に記憶し、注文された商品がワンオーダーの対象であるか否かをメニューマスタ１３ｂを参照して判定し、注文されたワンオーダー対象商品の数をワンオーダー数として計数し、ワンオーダー数とワンオーダータスクとの比較によって必要な数の注文がなされたか否かを判定するので、ワンオーダーの数を自動的に管理することができ、もって必要な数の注文を確実に受注することができる。
【００４９】
また、ワンオーダー数とワンオーダータスクとの比較を定期的におこなうことにより、必要な数の注文を早期に受注することができる。ワンオーダーとして注文される商品が飲食物である場合、提供から消費までの時間がかかるので、客側としても注文は早期に完了することが望ましい。すなわち、必要な注文数を早期に受注することで、店舗側にとって利益を確保するという利点があると同時に、客側に飲食物を楽しむための十分な時間を提供できるという利点がある。
【００５０】
なお、本実施の形態に示した制御部１２における各処理部の機能を、物理的に独立した処理部として実現することで、注文管理に特化した注文管理装置を得ることができる。また、各処理部の機能をソフトウェアによって実現したならば、汎用コンピュータ上で実行可能な注文管理プログラムを得ることができる。
【００５１】
（付記１）人数によって定まる所定数の注文を受注することを前提に提供されるサービスにおいて前記注文の数を管理する注文管理プログラムであって、
前記人数を取得する人数取得手順と、
前記注文の履歴を記憶し、該注文履歴と前記人数取得手順によって取得した人数とをもとに、前記所定数の注文を受注したか否かを監視する注文数監視手順と、
前記注文数監視手順による監視の結果、受注した注文数が前記所定数に満たない場合に警告を出力する警告手順と、
をコンピュータに実行させることを特徴とする注文管理プログラム。
【００５２】
（付記２）前記注文数監視手順は、所定時間間隔で該注文数の監視を繰り返すことを特徴とする付記１に記載の注文管理プログラム。
【００５３】
（付記３）人数によって定まる所定数の注文を受注することを前提に提供されるサービスにおいて前記注文の数を管理する注文管理方法であって、
前記人数を取得する人数取得工程と、
前記注文の履歴を記憶し、該注文履歴と前記人数取得工程によって取得した人数とをもとに、前記所定数の注文を受注したか否かを監視する注文数監視工程と、
前記注文数監視工程による監視の結果、受注した注文数が前記所定数に満たない場合に警告を出力する警告工程と、
を含むことを特徴とする注文管理方法。
【００５４】
（付記４）前記注文数監視工程は、所定時間間隔で該注文数の監視を繰り返すことを特徴とする付記３に記載の注文管理方法。
【００５５】
（付記５）人数によって定まる所定数の注文を受注することを前提に提供されるサービスにおいて前記注文の数を管理する注文管理装置であって、
前記人数を取得する人数取得手段と、
前記注文の履歴を記憶し、該注文履歴と前記人数取得手段によって取得した人数とをもとに、前記所定数の注文を受注したか否かを監視する注文数監視手段と、
前記注文数監視手段による監視の結果、受注した注文数が前記所定数に満たない場合に警告を出力する警告手段と、
を備えたことを特徴とする注文管理装置。
【００５６】
（付記６）前記注文数監視手段は、所定時間間隔で該注文数の監視を繰り返すことを特徴とする付記５に記載の注文管理装置。
【００５７】
【発明の効果】
以上説明したように、請求項１の発明によれば、注文管理プログラムは、注文履歴と人数とをもとに、人数によって定まる所定数の注文を受注したか否かを監視し、受注した注文数が所定数に満たない場合に警告を発するので、注文数を自動的に管理し、人数によって定まる所定数の注文を確実に受注することができる注文管理プログラムが得られるという効果を奏する。
【００５８】
また、請求項２の発明によれば、注文管理プログラムは、人数によって定まる所定数の注文を受注したか否かを所定時間間隔で監視し、受注した注文数が所定数に満たない場合に警告を発するので、人数によって定まる所定数の注文を確実、かつ早期に受注することのできる注文管理プログラムが得られるという効果を奏する。
【００５９】
また、請求項３の発明によれば、注文管理方法は、注文履歴と人数とをもとに、人数によって定まる所定数の注文を受注したか否かを監視し、受注した注文数が所定数に満たない場合に警告を発するので、注文数を自動的に管理し、人数によって定まる所定数の注文を確実に受注することができる注文管理プログラムが得られるという効果を奏する。
【図面の簡単な説明】
【図１】本実施の形態にかかるカラオケボックス用の注文管理システムの概要構成を説明する概要構成図である。
【図２】図１に示した記憶部に記憶する情報の具体例を説明する説明図である。
【図３】図１に示した入室処理部の処理動作を説明するフローチャートである。
【図４】図１に示した注文処理部の処理動作を説明するフローチャートである。
【図５】図１に示した注文処理部の定期的な処理動作を説明するフローチャートである。
【符号の説明】
１    注文管理システム
１１    入力部
１２    制御部
１３    記憶部
１３ａ  注文状態データ
１３ｂ  メニューマスタ
１３ｃ  部屋マスタ
１３ｄ  料金マスタ
１３ｅ  部屋状態データ
１４    表示部
２１    入室処理部
２２    注文処理部
２２ａ  注文量監視部
２２ｂ  警告処理部
２３    退室処理部
【図１】
2004302887.tif 000003
【図２】
2004302887.tif 000004
【図３】
2004302887.tif 000005
【図４】
2004302887.tif 000006
【図５】
2004302887.tif 000007