JP7808977B2

JP7808977B2 - 注文管理装置及びプログラム

Info

Publication number: JP7808977B2
Application number: JP2022026075A
Authority: JP
Inventors: 浩志澁谷
Original assignee: Seiko Solutions Inc.
Current assignee: Seiko Solutions Inc.
Priority date: 2022-02-22
Filing date: 2022-02-22
Publication date: 2026-01-30
Anticipated expiration: 2042-02-22
Also published as: JP2023122398A

Description

本発明は、注文管理装置及びプログラムに関する。

近年、飲食店では、店内飲食の他に、デリバリー代行業者のサービスを使用することが増えている。デリバリー代行業者は、飲食店のメニューについて、デリバリー代行業者のｗｅｂサイトでユーザのスマートフォンなどから注文を受け付け、受け付けた注文のデータを飲食店と連携し、飲食店で調理が完了したメニューの配達を行うサービスを提供している。

また、飲食店では、複数のデリバリー代行業者と契約を行うことも多い。これらのデリバリー代行業者は、配達方法やサービスの内容に応じて、それぞれ価格を設定している。飲食店では、同じメニューでもデリバリー代行業者によって価格が違う場合もあり、デリバリー業者毎に、別のメニューコードを付与し、それぞれ別メニューとして管理している。そのため、あるメニューが品切れとなった場合には、連携する各デリバリー代行業者のメニューについてもそれぞれ品切れの処理を行う必要があり、店員の手間がかかっていた。

ここで、品切れの制御については、メニューに食材を対応付けた食材テーブルを設定し、在庫が切れた食材をキーワードとして食材テーブルを検索することで、複数のメニューを同時に品切れに設定して食券の発行を禁止するものがある（特許文献１）。

特開２０００－５７３８３号公報

しかし、先行文献のようにメニューに食材テーブルを対応付けた場合には、メニューの変更があった場合に、食材マスタとメニューマスタの２種類のマスタファイルを変更しなければならず、変更があった場合に、マスタ修正に手間がかってしまうとともに、品切れ操作は、食材マスタを変更するため、当該メニューを品切れとするには、食材を確認して、その食材を品切れにしなければならず、直感的に操作しにくいという問題があった。

そこで、本願発明は、上記の点に鑑みてなされたものであり、メニューが品切れとなった場合に、連携する他のメニューについても自動的に品切れとして処理することで、品切れの処理の負担を軽減することが可能な注文管理装置及びプログラムを提供することを目的とする。

第１の態様の注文管理装置は、第１メニューと、当該第１メニューに対応する在庫状況とを記憶する記憶部と、対応する前記第１メニューへのリンク情報が付与された第２メニューの注文を外部装置から受け付けた際に、注文された当該第２メニューの前記リンク情報から前記第１メニューに対応する在庫状況を確認する管理部と、を備える。

第１の態様の注文管理装置によれば、メニューが品切れとなった場合に、連携する他のメニューについても品切れとして処理することで、品切れの処理の負担を軽減することができる注文管理装置を提供することが可能となる。

また、第２の態様の注文管理装置は、前記管理部は、前記在庫状況を確認した結果、在庫がない場合は、前記第２メニューの在庫がない旨を前記外部装置に送信する。

第２の態様の注文管理装置によれば、在庫状況の確認結果を外部装置に出力することができる注文管理装置を提供することが可能となる。

また、第３の態様の注文管理装置は、前記在庫状況には、前記第１メニューで使用される食材の在庫状況を含む。

第３の態様の注文管理装置によれば、食材がなくなった場合に、共通の食材を使用する他のメニューについても品切れとして処理することで、食材がなくなった場合の処理の負担を軽減することができる注文管理装置を提供することが可能となる。

また、第４の態様の注文管理装置は、前記第２メニューには、共通の前記食材を使用する前記第１メニューへの前記リンク情報が付与される。

第４の態様の注文管理装置によれば、食材がなくなった場合に、リンク情報を辿ることで共通の食材を使用する他のメニューについても品切れとして処理することができる注文管理装置を提供することが可能となる。

また、第５の態様の注文管理装置は、前記食材に対して在庫状況を確認した結果、在庫がない場合、前記第２メニューとともに、共通の当該食材を使用する注文を受け付けていない他の第２メニューについても、在庫がない旨を前記外部装置に送信する。

第５の態様の注文管理装置によれば、注文をする者に、在庫がない食材を使用する他のメニューについても、注文ができないことを報知することが可能となり、在庫がない食材を使用するメニューの代替メニューの選択を補助することができる注文管理装置を提供することが可能となる。

また、第６の態様の注文管理装置のプログラムは、コンピュータに、対応する第２メニューに対して関連づけたリンク情報が付与されている第１メニューと前記第１メニューに対応する在庫状況とを記憶する記憶部から、当該前記第１メニューと、当該前記在庫状況とを読み出す処理と、対応する前記第１メニューへのリンク情報が付与された第２メニューの注文を外部装置から前記第２メニューの注文を受け付けた際に、注文された当該第２メニューの前記リンク情報から前記第１メニューに対応する在庫状況を確認する処理を実行させる。

第６の態様の注文管理装置のプログラムによれば、メニューが品切れとなった場合に、連携する他のメニューについても品切れとして処理することで、品切れの処理の負担を軽減することができる注文管理装置のプログラムを提供することが可能となる。

本発明によれば、メニューが品切れとなった場合に、連携する他のメニューについても品切れとして処理することで、品切れの処理の負担を軽減することができる注文管理装置及びプログラムを提供することが可能となる。

本発明の実施の形態に係る注文管理システムの概略構成図である。本発明の実施の形態に係る注文管理装置の概略ブロック図である。本発明の実施の形態に係る注文管理装置の機能構成の例を示すブロック図である。本発明の実施の形態に係る注文管理装置に記憶されるメニュー情報テーブルの一例を説明するための説明図である。本発明の実施の形態に係る品切れテーブルの一例を説明するための説明図である。本発明の実施の形態に係るサーバに記憶されるメニュー情報テーブルの一例を説明するための説明図である。本発明の実施の形態に係る注文管理システムの動作の一例を示すシーケンス図である。本発明の実施の形態に係る注文受注処理の一例を示すフローチャートである。本発明の実施の形態に係るメニュー情報テーブルの他の一例を説明するための説明図である。本発明の実施の形態に係る食材の品切れテーブルの他の一例を説明するための説明図である。

以下、本発明の実施の形態の一例を、図面を参照しつつ説明する。なお、各図面において同一または等価な構成要素および部分には同一の参照符号を付与している。また、図面の寸法比率は、説明の都合上誇張されており、実際の比率とは異なる場合がある。

図１を用いて、本実施の形態に係る注文管理システム１０の一例を説明する。
図１は、本実施の形態に係る注文管理システム１０の概略構成の一例を示す図である。
図１に示すように、本実施の形態に係る注文管理システム１０は、飲食店などの店舗内に収容される店舗内システム２０と、店舗内システム２０とインターネット回線などを通じて接続されるデリバリー代行業者のサーバ４００とを備えている。デリバリー代行業者のサーバ４００は、ユーザのスマートフォン５００などからインターネット回線などを通じて飲食店のメニューの注文を受け付け、店舗内システム２０に受け付けた注文情報を送信する。ここで、本実施の形態では、デリバリー代行業者のサーバ４００が外部装置の一例である。また、デリバリー代行業者のサーバ４００は、当該店舗が契約しているデリバリー代行業者の数分のサーバ４００を備えている。

店舗内システム２０は、複数の注文端末装置１００と、注文管理装置２００と、プリンター３００とを備えている。なお、注文管理装置２００は、店舗内に収容される場合に限定されず、インターネット回線などを通じて注文端末装置１００、プリンター３００と接続されることにより、店舗外に設置されても良い。また、店舗内システム２０には、調理の際に参照する情報が表示されるディスプレイ装置などの他の装置を備えても良い。

注文端末装置１００は、店舗の店員が客からの注文を入力する際に使用する装置であり、本実施の形態では、スマートフォン型やタブレット型の端末装置である。注文端末装置１００は、例えば、無線ＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）などの無線通信により、注文管理装置２００と通信を行う。

注文管理装置２００は、本実施の形態では、注文端末装置１００やサーバ４００から入力された注文情報の管理や、注文情報に応じてプリンター３００にお客様伝票を印刷させる等の制御、後述するメニューの残数の確認などを行う。

プリンター３００は、会計の際に使用するお客様伝票などを印刷する装置である。プリンター３００は、有線ネットワークを介して注文管理装置２００と通信を行う。注文管理装置２００からプリンター３００に送信される情報は、お客様伝票を印字するための情報である伝票イメージ等である。なお、プリンター３００は、有線ネットワークを介して注文管理装置２００と通信を行う場合に限定されず、例えば、無線ＬＡＮ、インターネットなどの無線通信を介して注文管理装置２００と通信を行っても良い。

（注文管理装置２００）
図２は、本実施の形態に係る注文管理装置２００のブロック図である。
図２に示すように、本実施の形態に係る注文管理装置２００は、制御部２０１、記憶部２０２、通信部２０３、入力部２０４、表示部２０５、を備えている。
各構成は、バス２０６を介して相互に通信可能に接続されている。

制御部２０１は、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）を備え、各種プログラムを実行したり、注文管理装置２００の各部を制御したりする。すなわち、制御部２０１は、記憶部２０２に記録されているプログラムに基づいて、上記各構成の制御及び各種の演算処理を行う。

また、制御部２０１は、注文端末装置１００やサーバ４００から入力された注文情報等に基づき、伝票イメージを作成し、プリンター３００に印刷を指示する。

記憶部２０２は、ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）、ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）を備え、オペレーティングシステムを含む各種プログラム、情報を記憶する。
記憶部２０２として、例えば、ＨＤＤ（ＨａｒｄＤｉｓｋＤｒｉｖｅ）、ＳＳＤ（ＳｏｌｉｄＳｔａｔｅＤｒｉｖｅ）、フラッシュメモリ等が用いられる。

ここで、本実施の形態における記憶部２０２に記憶される情報としては、例えば、図４に示す注文可能なメニューに関するメニュー情報テーブルＭ１、図５に示す品切れテーブルＳ、などがある。

ここで、記憶部２０２に記憶されているプログラムは、注文管理装置２００に予めインストールされていても良い。また、プログラムは、不揮発性の記憶媒体に記憶して、又はネットワークを介して配布し、注文管理装置２００に適宜インストールすることで実現しても良い。なお、不揮発性の記憶媒体の例としては、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、及びＵＳＢメモリ、メモリカード等が想定される。

通信部２０３は、注文端末装置１００、プリンター３００、サーバ４００等の他の機器と通信するものであり、注文端末装置１００、プリンター３００、サーバ４００から受信した情報を、有線ネットワークを介して制御部２０１に出力し、又、制御部２０１から入力された入力情報を、無線ＬＡＮを介して注文端末装置１００、プリンター３００、サーバ４００に送信する。

入力部２０４は、キーボードや、マウス等のポインティングデバイスを含み、各種の入力を行うために使用される。

表示部２０５は、例えば、液晶ディスプレイであり、制御部２０１の制御に応じて各種の情報を表示する。
また、表示部２０５は、タッチパネル方式を採用して、入力部２０４として機能しても良い。

上記のプログラムを実行する際に、注文管理装置２００は、上記のハードウェア資源を用いて、各種の機能を実現する。
注文管理装置２００が実現する機能構成について説明する。
図３は、注文管理装置２００の制御部（ＣＰＵ）２０１の機能構成の例を示すブロック図である。

図３に示すように、注文管理装置２００は、機能構成として、受付部２１０、送信部２２０、管理部２３０を有する。各機能構成は、制御部（ＣＰＵ）２０１が記憶部２０２に記憶されたプログラムを読み出し、実行することにより実現される。

（受付部２１０）
受付部２１０は、注文端末装置１００や、デリバリー代行業者のサーバ４００から送信された、注文された料理、当該料理の注文数量、などからなる注文情報を受け付けるものである。

（送信部２２０）
送信部２２０は、デリバリー代行業者のサーバ４００に、受け付けた注文情報について、受注か品切れかの返信をする。

（管理部２３０）
管理部２３０は、対応する店内用のメニューへのリンク情報が付与されたデリバリー用のメニューの注文をデリバリー代行業者のサーバ４００から受け付けた際に、注文された当該デリバリー用のメニューのリンク情報から店内用のメニューに対応する在庫状況を確認する。
また、管理部２３０は、在庫状況を確認した結果、在庫がない場合は、送信部２２０を用いて、在庫がない旨をデリバリー代行業者のサーバ４００に送信する。

（サーバ４００）
また、デリバリー代行業者のサーバ４００には、図６に示す当該デリバリー代行業者で注文することが可能なメニューに関するメニュー情報テーブルＭ２などが記憶される。本例では、デリバリー代行業者Ａ社のサーバ４００に記憶しているメニュー情報テーブルＭ２の例を示している。

図４～図６を用いて、注文管理装置２００に記憶されるメニュー情報テーブルＭ１と品切れテーブルＳとデリバリー代行業者のサーバ４００に記憶しているメニュー情報テーブルＭ２について説明する。

図４は、注文管理装置２００に記憶されるメニュー情報テーブルＭ１の一例である。注文管理装置２００に記憶されるメニュー情報テーブルＭ１には、図４に示すように、店内用のメニューと、デリバリー用のメニューとが記憶される。ここで、店内用のメニューが第１メニューの一例であり、デリバリー用のメニューが第２メニューの一例である。

注文管理装置２００に記憶されるメニュー情報テーブルＭ１には、図４に示すように、メニューを識別するためのメニューコードと、メニュー名、単価、リンクメニューコードが記載されている。リンクメニューコードは、デリバリー用のメニューに付与され、対応する店内用のメニューへの関連づけを示すリンク情報である。本例では、メニューコード「１００１」のデリバリー用のメニューの「Ａ社用ハンバーグ」、メニューコード「２００１」の「Ｂ社用ハンバーグ」、メニューコード「３００１」の「Ｃ社用ハンバーグ」について、メニューコード「０００１」の店内用のメニューの「ハンバーグ」へのリンク情報が付与されている。同様に、メニューコード「１００２」のデリバリー用のメニューの「Ａ社用ビーフシチュー」、メニューコード「２００２」の「Ｂ社用ビーフシチュー」、メニューコード「３００２」の「Ｃ社用ビーフシチュー」について、メニューコード「０００２」の店内用のメニューの「ビーフシチュー」へのリンク情報が付与されている。なお、リンク情報が付与されるデリバリー用のメニューと、対応する店内用のメニューとは、同じメニュー名のものに限定されず、他のメニュー名のものであってもよい。例えば、メニュー「ハンバーグ」について、店内用メニューの具体的な名称が「ハンバーグ」で、「Ａ社用ハンバーグ」の具体的な名称が「特製ハンバーグ」、「Ｂ社用ハンバーグ」の具体的な名称が「ハンバーグ」、のように、同じメニュー名でも異なるメニュー名でもよい。

図５は、注文管理装置２００に記憶される品切れテーブルＳの一例である。注文管理装置２００に記憶される品切れテーブルＳには、図５に示すように、店内用のメニューについて、在庫状況として残数が記憶される。ここで、図５に示す残数「０」は品切れ状態を示し、「１０」は残数が「１０」であることを示し、「９９９９」は残数の設定がない、すなわち、品切れが管理されていないメニューであることを示す。また、品切れテーブルＳへの残数の入力は、注文管理装置２００の入力部２０４を用いたり、注文端末装置１００を用いたりすることで行われる。

なお、品切れテーブルＳをメニュー情報テーブルＭ１とは別に設ける場合に限定されず、メニュー情報テーブルＭ１の項目を増やし、「残数」についても合わせて記憶するようにしてもよい。

また、図６を用いて、デリバリー代行業者のサーバ４００に記憶されるメニュー情報テーブルＭ２について説明する。図６に示すように、サーバ４００には、店内用のメニューのうち、当該デリバリー代行業者のメニューが記憶される。本例では、デリバリー代行業者Ａ社のサーバ４００に記憶しているメニュー情報テーブルＭ２について示している。そのため、かかるメニュー情報テーブルＭ２には、注文管理装置２００に記憶しているメニュー情報テーブルＭ１のうち、デリバリー（Ａ社）用のメニューと同じメニューが記憶されている。なお、デリバリー代行業者のサーバ４００に、当該デリバリー代行業者のメニューを記憶せず、注文管理装置２００に記憶して、当該注文管理装置２００に記憶しているデリバリー代行業者のメニューをデリバリー代行業者のサーバ４００の表示部に表示して、ユーザからの注文を受け付けるようにしてもよい。

次に、図７を用いて注文管理システム１０の作用について説明する。図７は、注文管理システム１０の動作の一例を示すシーケンス図である。

ステップＳ１００において、料理を注文するユーザは、自身のスマートフォン５００などの端末を用いてデリバリー代行業者のサーバ４００のｗｅｂサイトにアクセスし、注文を行う。かかる注文を受け付けたサーバ４００のＣＰＵは、ステップＳ１０２において、受け付けた注文データを注文管理装置２００に送信する。

注文データを受け付けた注文管理装置２００の制御部２０１は、品切れテーブルＳを参照し、品切れか否かを判断し、サーバ４００に、品切れか受注完了かの返信を行う。かかる返信を受け付けたサーバ４００のＣＰＵは、ユーザの端末に品切れか受注完了かの返信を行う。なお、品切れテーブルＳを参照した品切れか否かの判断は、注文管理装置２００の制御部２０１が行う場合に限定されず、デリバリー代行業者のサーバ４００が注文管理装置２００に記憶されている品切れテーブルＳを参照して品切れか否を判断するようにしてもよい。また、注文管理装置２００に記憶されている品切れテーブルＳのコピーをデリバリー代行業者のサーバ４００に記憶し、デリバリー代行業者のサーバ４００が当該コピーの品切れテーブルＳを参照して品切れか否を判断するようにしてもよい。

次に、図８を用いて本実施の形態における注文管理装置２００の作用について説明する。図８は、注文管理装置２００による注文受注処理の流れを示すフローチャートである。制御部２０１が記憶部２０２からプログラムを読み出して、展開して実行することにより、当該処理が行なわれる。

ステップＳ２００において、制御部２０１のＣＰＵ（受付部２１０）により、メニューの注文を受け付けたか否かが判定される。すなわち、ユーザがスマートフォン５００などを用いて、デリバリー代行業者のサーバ４００、例えばデリバリー代行業者Ａ社のサーバ４００に接続し、当該サーバ４００を介してＡ社用のメニューの注文をしたかが判定される。メニューの注文を受け付けていないと判定された場合は処理を終了する。一方、メニューの注文を受け付けたと判定された場合は、次のステップＳ２０２に進む。

ステップＳ２０２において、制御部２０１のＣＰＵ（管理部２３０）により、注文されたメニューが品切れか否かが判定される。すなわち、制御部２０１はメニュー情報テーブルＭ１から、注文されたＡ社用のメニューに関連付けられたメニューのリンク情報から対応する店内用のメニューのメニューコードを取得し、取得したメニューコードの品切れテーブルＳを参照して残数が「０」でないかを判定する。具体的には、制御部２０１のＣＰＵ（管理部２３０）は、デリバリー代行業者Ａ社のメニューコード「１００１」の「Ａ社用ハンバーグ」が１個注文された場合は、メニュー情報テーブルＭ１からメニューコード「１００１」の「Ａ社用ハンバーグ」のリンクメニューコードに記載されている店内用のメニューのメニューコード「０００１」を取得する。そして、取得したメニューコード「０００１」の品切れテーブルＳの残数が「０」でないかを判定する。品切れであると判定された場合は、次のステップＳ２０４に進む。

ステップＳ２０４において、制御部２０１のＣＰＵ（送信部２２０）は、デリバリー代行業者Ａ社のサーバ４００に対し、品切れである旨の返信を行う。そして、処理を終了する。

一方、上述したステップＳ２０２で、品切れであると判定されない場合は、ステップＳ２０６に進み、制御部２０１のＣＰＵ（送信部２２０）は、デリバリー代行業者Ａ社のサーバ４００に対し、受注が完了した旨の返信を行う。そして、処理を終了する。
なお、受注のタイミングで、品切れテーブルＳに記憶された各メニューコードに対応する残数を、受注数だけカウントダウンさせて、残数を更新するようにしてもよい。

本実施の形態によれば、メニューが品切れとなった場合に、対応する他のメニューについても品切れとして処理することで、品切れの処理の負担を軽減することができる注文管理装置２００及びプログラムを提供することが可能となる。すなわち、店内用のメニューの在庫状況のみ管理すればよく、デリバリー用のメニューの在庫状況を管理する必要がないようにすることが可能となる。特に、デリバリー代行業者が複数ある場合に、デリバリー代行業者毎に品切れの処理をする場合の処理の負担の軽減に有効である。

なお、本発明は、上述した実施の形態に限定されるものではなく、その趣旨を逸脱しない限りにおいて、上述したもの以外に種々の変更を行うことが可能である。

上述した実施の形態では、メニュー自体が品切れであるか否かを判定したか、メニュー自体の品切れの他に、又は、メニュー自体の品切れに加え、食材となるメニューが品切れであるか否かを判定し、当該判定結果から、共通する食材を使用する派生メニューが注文可能であるか否かを判定するようにしてもよい。例えば、詳しくは後述するが、食材となるメニュー「ハンバーグ」が品切れである場合は、共通の「ハンバーグ」を使用する派生メニュー「チーズハンバーグ」も品切れであると判定する。なお、食材となるメニューが品切れであるか否かを判定する場合に限定されず、牛肉やキャベツなど、メニューの食材自体が品切れであるか否かを判定するようにしてもよい。例えば、牛肉が品切れである場合は、牛肉を使用するメニューを品切れであると判定するようにしてもよい。

図９は、注文管理装置２００に記憶しているメニュー情報テーブルＭ３の一例である。メニュー情報テーブルＭ３には、食材メニューと、派生メニューとが記憶される。ここで、食材メニューが第１メニューの一例であり、派生メニューが第２メニューの一例である。

メニュー情報テーブルＭ３には、図９に示すように、メニューを識別するためのメニューコードと、メニュー名、単価、リンクメニューコードが記載されている。リンクメニューコードは、共通する食材が複数ある場合に対応するため複数のリンクメニューコードが入力可能にされている。ここで、リンクメニューコードは、派生メニューに付与され、共通する食材メニューへの関連づけを示すリンク情報である。本例では、メニューコード「９００２」の派生メニューの「チーズハンバーグ」について、メニューコード「０１０１」の食材メニューの「ハンバーグ」へのリンク情報が付与されている。同様に、メニューコード「９００３」の派生メニューの「ハンバーグ＆エビフライ」について、メニューコード「０１０１」の食材メニューの「ハンバーグ」と「０１０２」の「エビフライ」へのリンク情報が付与されている。

図１０は、注文管理装置２００に記憶している品切れテーブルＳ２の一例である。注文管理装置２００に記憶される品切れテーブルＳ２には、図１０に示すように、食材メニューについて、在庫状況として残数が記憶される。ここで、図１０に示す残数「０」は品切れ状態を示し、「１０」は残数が「１０」であることを示し、「９９９９」は残数の設定がない、すなわち、品切れが管理されていないメニューであることを示す。

例えば、メニューコード「９００３」の「ハンバーグ＆エビフライ」が１個注文された場合は、注文管理装置２００の制御部２０１は、メニュー情報テーブルＭ３から当該「ハンバーグ＆エビフライ」のリンクメニューコードに記載されている食材メニューのメニューコード「０１０１」と「０１０２」を取得する。そして、取得したメニューコード「０１０１」「０１０２」の品切れテーブルＳの残数が「０」でないかを判定する。図１０に示す品切れテーブルＳの例では、メニューコード「０１０２」は残数「１０」であるため、品切れではないが、メニューコード「０１０１」が残数「０」であるため、注文管理装置２００の制御部２０１は、「ハンバーグ＆エビフライ」は品切れであると判定する。
なお、この例の場合、メニューコード「０１０１」の残数が「０」であるということが分かるため、「ハンバーグ＆エビフライ」の注文したユーザが操作する端末に対して、メニューコード「０１０１」である「ハンバーグ」と、リンクメニューコードに「０１０１」を含む派生メニューとに対し品切れが発生している旨、通知するようにしてもよい。すなわち、メニューコード「０１０１」である「ハンバーグ」を含むメニューコード「９００２」の「チーズハンバーグ」などについても品切れが発生していることを、料理を注文するユーザに通知して、他の品切れメニューについても知らせるようにして、品切れしているメニューの代替メニューの選択を補助するようにしてもよい。

本変形例によれば、食材がなくなった場合に、リンク情報を辿ることで共通の食材を使用する他のメニューについても品切れとして処理することができる注文管理装置２００及びプログラムを提供することが可能となる。

１０注文管理システム
１００注文端末装置
２００注文管理装置
２０１制御部
２０２記憶部
２０３通信部
２０４入力部
２０５表示部
２０６バス
３００プリンター
４００サーバ
Ｍメニュー情報テーブル
Ｓ品切れテーブル

Claims

第１メニューと、当該第１メニューに対応する在庫状況とを記憶する記憶部と、
対応する前記第１メニューへのリンク情報が付与された第２メニューの注文を外部装置から受け付けた際に、注文された当該第２メニューの前記リンク情報から前記第１メニューに対応する在庫状況を確認し、前記在庫状況を確認した結果、在庫がない場合は、前記第２メニューの在庫がない旨を前記外部装置に送信する管理部と、
を備える注文管理装置。
前記在庫状況には、前記第１メニューで使用される食材の在庫状況を含む請求項１に記載の注文管理装置。
前記第２メニューには、共通の前記食材を使用する前記第１メニューへの前記リンク情報が付与される請求項２に記載の注文管理装置。
前記食材に対して在庫状況を確認した結果、在庫がない場合、前記第２メニューとともに、共通の当該食材を使用する注文を受け付けていない他の第２メニューについても、在庫がない旨を前記外部装置に送信する請求項２又は３に記載の注文管理装置。
コンピュータに、
第１メニューと前記第１メニューに対応する在庫状況とを記憶する記憶部から、当該第１メニューと、当該在庫状況とを読み出す処理と、
対応する前記第１メニューへのリンク情報が付与された第２メニューの注文を外部装置から受け付けた際に、注文された当該第２メニューの前記リンク情報から前記第１メニューに対応する在庫状況を確認し、前記在庫状況を確認した結果、在庫がない場合は、前記第２メニューの在庫がない旨を前記外部装置に送信する処理を実行させるためのプログラム。