订购系统的制作方法

专利名称：订购系统的制作方法
技术领域：
本发明涉及一种订购系统，该系统用于在商店中例如餐馆中接受订单，尤其涉及一种订购系统，该系统适用于例如公司员工自助餐厅这样的自助方式的餐馆。
在各种类型的餐馆中，象员工自助餐厅和学生自助餐厅这样的餐馆经常采用自助方式。不仅这些自助餐厅，所有采取自助方式的餐馆通常事先在架子上放置已经做好的食物，就餐者可以从架子上选择他们喜欢的食物，然后在出纳员处付帐。
因此在这种餐馆中需要预先准备一定数量的食物。另外，为了扩大食物的选择范围，需要准备多种不同种类的食物。
另外，在其他类型的餐馆中，在消费者走入餐馆并决定点什么之后再准备食物。但是即使在这种情况下，也必须事先准备烹饪食物。另外，当食物不能在单独的服务区准备时必须事先准备多个食物区。
另外，不管餐馆是什么方式，必须事先订购配料。并且最好将订购的配料量限制在所需的最低程度。
因此餐馆的一个通常的问题是很难预测在某天或某个时间段内来餐馆就餐的顾客数量。当一个餐馆运行了很多年之后，其管理者可以单凭经验的方法预测将要来餐馆就餐的大约人数，但是根据一个月份中的某一天，一个星期中的某一天，那天的天气，节日和事件及其他条件，客人的准确数量将相对地改变。另外，客人各自的一时的兴致使得不太可能进行预测。因此在很多情况下前来就餐的顾客的实际数量将与预测的顾客数不相同。
预测前来餐馆就餐的顾客的数量对于决定为那天准备的食物份数和订购的配料量是一个极其重要的因素。对于采取自助方式的餐馆来说这种预先的准备尤为重要，并且要做到适当地调整要准备的食物的份数使之与顾客的数量相符合是困难的。
尽管食物份数和订购的配料量是根据预测的顾客数量来确定的，当预测的顾客数量与实际的顾客数量不同时，在经营餐馆的过程中将产生下列问题。注意此处假设食物份数和订购的配料量是根据预测的顾客数量来确定的。
(1)顾客的数量多于预测数在这种情况下，食物份数和订购的配料量极有可能不足。当没有充足的食物时，就不可能为后来的顾客服务。如果经常出现食物数量不充足的情况。餐馆就会“赢得”不能提供充足食物的声誉。
(2)顾客的数量少于预测数在这种情况下，所购买的配料和做好的食物极有可能浪费。尤其是不能保存的新鲜食物和任何剩下的食物都必须扔掉。
另外，尤其是采取自助方式的餐馆中，当顾客到达时必须能够立即得到他们想要的食物。由于这个原因，完全有必要进行预先烹饪。然而尽管有可能要将未烹饪的配料放到第二天，这种预先烹饪的食物却无法保藏，因此必须在同一天内将其消耗掉。因此有时必须扔掉剩下的做好的食物。
对于餐馆来讲扔掉食物是一种损失。扔掉的越多餐馆的负担越重。另外，如果不断地扔掉大量的已预先做好的食物，餐馆将“赢得”是一个浪费食物的地方的声誉。这也将对餐馆的总的声誉带来问题。
即使过剩的配料可以保藏，必须对储藏设备进行投资。另外除非订购的配料量总是与所需求的量相等，考虑到储藏等的花费，餐馆将承担更多的花费和损失。由于这个原因，事先订购的配料量和准备的食物份数最好越少越好。
另一方面，由于这是一个服务行业，必须避免出现去餐馆的顾客得不到服务这种情况。因此在这种情况下，必须增加事先订购的配料量和准备的食物份数，使之多于预测量一定的百分数。
这样，订购的配料量和准备的食物份数成为经营餐馆的最大问题。
考虑到上述问题，本发明的一个目的在于提供一种可以有效地订购配料和准备食物的订购系统。
本发明另一个目的在于提供一种订购系统，它使得可以自动地计算和修改应订购的配料量和应做的食物数量。
注意不用说自动地计算和修改订购的商品的数量等的效果或事先掌握某一天所需的最少的商品数量的能力也可以应用于除餐馆之外的商店或邮购销售、电话购物及在线销售方面，但以下对于本发明的解释将以一个自助餐厅系统为例进行说明。
为到达上述目的，根据本发明的订购系统，通过一个网络连接具有菜单文件和配料文件等的自助餐厅服务器和顾客所使用的终端PC，顾客从终端PC访问自助餐厅服务器并发出定单。顾客根据从菜单文件所读取的与自助餐厅的菜单相关的信息选择他们想要的食物。根据来自于顾客的定单顺序修改与那天要烹饪的食物及其数量及要订购的配料相关的信息。
通过以下参照附图对优选实施例的描述，本发明上述目的和特点将更加清楚。其中

图1是根据本发明的一个实施例的自助餐厅系统的视图。
图2是自助餐厅侧系统配置视图。
图3是一个菜单文件的配置视图。
图4是一个配料文件的配置视图。
图5是一个定单接收文件的配置视图。
图6是一个配料订购文件的配置视图。
图7是一个食物文件的配置视图。
图8是一个个人设置文件的配置视图。
图9是一个终端的配置视图。
图10是一个终端的内部配置方框图。
图11是一个接收设备/管理终端的内部配置方框图。
图12是一个柜台终端的内部配置方框图。
图13是一个厨房终端的内部配置方框图。
图14是顾客进行订购的操作的处理程序的流程图。
图15是当使用打印机发布优惠卷时的处理的视图。
图16是当将订购的内容写入顾客卡上时的处理的视图。
图17A和17B是当制作定单时终端和餐馆服务器侧处理程序的流程图的第一部分。
图18是当制作定单时终端和餐馆服务器侧处理程序的流程图的第二部分。
图19是一个初始菜单屏幕的显示例子的视图。
图20是一个日本食物菜单表格显示例子的视图。
图21是一个所选菜单详细的屏幕显示例子的视图。
图22是一个定单表格的显示例子和其中的项目的例子的视图。
图23是一个确认屏幕的显示例子的视图。
图24是当设置密码时自助餐厅系统的处理程序的流程图的第一部分。
图25A和25B是当设置密码时自助餐厅系统的处理程序的流程图的第二部分。
图26是密码设置的初始屏幕显示例子的视图。
图27是一个新设置的屏幕显示例子的视图。
图28是一个确认新设置的屏幕显示例子的视图。
图29是一个更改密码的屏幕显示例子的视图的第一部分。
图30是一个更改密码的屏幕显示例子的视图的第二部分。
图31是在接收到一个定单之后在自助餐厅服务器侧所执行的处理程序的流程图。
图32是在最后期限和最后期限之前在自助餐厅服务器侧所执行的处理程序的流程图。
图33A和33B是当取消一个定单时自助餐厅系统的处理程序的流程图。
图34是当在厨房终端上显示信息时处理程序的流程图。
图35是在厨房终端上显示的一个屏幕的例子的视图。
图36是显示某一菜单的信息的厨房终端的显示屏幕的例子的视图。
图37是剩下的未做的食物份数的显示屏幕的例子的视图。
图38是一个检查交货的屏幕显示例子的视图。
图39是一个厨房终端的键盘例子的视图。
图40是当顾客到达自助餐厅时一个处理程序的流程图。
图41是一个顾客指南显示例子的视图。
图42是当检查配料时一个处理程序的流程图。
图43是当自助餐厅满员时一个消息显示的例子的视图。
下面将参考附图描述本发明的实施例。
为了达到上述目的，本发明提供了一种订购系统，具有一个自助餐厅服务器和一个由自助餐厅的顾客所操作的终端，自助餐厅和终端通过一条传输线路相互连接。其中自助餐厅服务器具有一个菜单文件，用于存储关于由自助餐厅所提供的菜单的信息，一个配料文件，用于存储存储在菜单文件中的菜单的每一项所需的配料的名称与数量，一个接收文件，用于存储与顾客所订购的菜单上的项目相关的信息，一个配料总计文件，用于根据顾客的定单总计每种配料所需的用量；及一个食物文件，用于存储如下信息，即在某段时间内必须制作的菜单项目，其数量，及制作这些菜单项目所需的配料。
在所述自助餐厅服务器，与每种配料的供应商相关的信息可以存储在所述配料总计文件中。
所述自助餐厅服务器可以通过一条传输线路与供应商处的终端相连；供应商的终端标识信息可以存储在所述配料总计文件中；并且可以根据在所述自助餐厅服务器订购配料时的所述终端标识信息，通过传输线路将定单信息传输到供应商终端。
另外自助餐厅服务器中，设置接受顾客定单的截止期限，并在过了截止期限后根据配料总计文件的信息订购配料。
在接收文件中存储如下信息，即，顾客所订购的菜单项目的名称及其数量，就餐时间，付款方法和特殊要求。
在所述食物文件中可以存储已经准备好的菜单项目的数量。
根据显示在屏幕上的已经准备好的菜单项目的数量和未做食物的数量计算未做食物的数量。
在所述食物文件中可以为菜单中的每一项存储与未做食物数量相关的信息。
在所述食物文件中可以为每种配料设置用于标识供应商是否已经为其发货的标记。
在所述配料文件中可以为每种配料设置用于标识供应商是否已经为其发货的标记。
在所述菜单文件中可以为每一项存储照片信息。
本发明还提供一种安装在自助餐厅中的数据处理装置，具有一个菜单文件，用于存储关于由自助餐厅所提供的菜单的信息；一个配料文件，用于存储存储在菜单文件中的菜单的每一项所必须的配料名称和用量；一个接收文件，用于存储与从所示终端所接收的由顾客所订购的菜单上的项目相关的信息；一个配料总计文件，用于根据顾客的定单总计每种配料所需的用量；及一个食物文件，用于存储如下信息，即在某段时间内必须制作的菜单项目，其数量，及制作这些菜单项目所需的配料。
所述数据处理装置可以与一个订购终端相连，顾客从该订购终端输入他或她的定单内容；及根据所述订购终端的操作接受顾客的定单。
本发明进一步通过一种用于从顾客接收定单的订购系统，具有一个供顾客输入定单内容的终端；一个用于从所述终端接收定单输入的服务器，所述服务器具有一个产品文件，用于存储与可以由顾客订购的产品相关的信息及一个定单文件，用于存储包括顾客所选择的产品的定单内容。
订购系统中所述服务器进一步具有一个定单文件，其中存储与产品及每个产品的供应商相关的信息。
在订购系统中，所述服务器进一步具有一个文件，其中设置了一个检查标志，用于标识向一个供应商订购的产品是否已经发货。
定单文件可以存储由一个顾客所要求的特殊要求。
本发明还提供一种用于接收顾客定单的订购系统中的订购方法，包括显示与可以在一个订购终端订购的产品相关的信息；根据来自于订购终端对产品的选择更改存储与在接收终端终端定单内容相关的信息的定单文件的内容。
本发明还提供一种用于接收顾客定单的订购系统中的订购方法，包括显示可以在订购终端上订购的产品列表屏幕，顾客从该订购终端输入定单内容；显示根据顾客对产品的选择在订购终端上输入定单内容的定单表格屏幕；显示响应于来自于定单表格屏幕的定单内容的输入使顾客确认通过订购终端所输入的定单内容的确认屏幕；在顾客确认显示在确认屏幕上的内容后接受定单。
当显示产品列表时可以首先显示可以由顾客订购的产品大类列表屏幕；及显示属于由顾客从大类列表屏幕上所选择的大类产品的小类产品列表屏幕。
最后，本发明还提供一种用于接收来自于订购终端的顾客产品定单的订购系统，包括当已经输入来自于顾客的定单时，判定接收定单截止期限是否已过；当截止期限未过时，接受顾客定单；当截止期限已过时，在订购终端上显示标识截止期限已过的消息，并且不接受定单。
现在参照本发明的具体实施例，图1是本发明的一个实施例中自助餐厅系统的系统配置的视图。这里尤其要解释一个员工自助餐厅的应用实例，当然本发明还可以自然的应用于其他类型的餐馆，以及不同类型的订购系统例如邮购、电话购物及在线销售等中。
总的来说，根据本实施例的自助餐厅系统具有一个自助餐厅服务器、一个自助餐厅终端、至少一个位于顾客(即员工)侧的终端和一个员工服务器。自助餐厅服务器、终端服务器和员工服务器通过网络相互连接。员工服务器具有一个员工数据库(DB)和一个工资数据库。当一个人在员工自助餐厅用餐并通过从其工资中扣除而付帐时，与帐单相对应的金额从记录在员工服务器中的工资帐户中扣除。
这里，在员工自助餐厅等的情况下可以使用LAN等，但是当希望让大量的不熟悉的顾客光顾自助餐厅时，可以采用当前流行的因特网等。
图2进一步详细地示出了自助餐厅侧配置的视图。在图2的例子中，自助餐厅侧具有自助餐厅服务器，厨房终端及柜台终端。注意自助餐厅侧的终端不限于这些，可以提供其他终端或将图2中所示的各终端的功能合并到一个终端中。自助餐厅侧的配置可以根据自助餐厅的规模等进行适当改变。
自助餐厅服务器具有各种文件。下面将解释这些文件。
图3是用于解释菜单文件的配置的视图。图3(A)是一个大分类文件；图3(B)是一个小分类文件。
可以由自助餐厅提供的菜单信息存储在菜单文件中，当顾客订购时参考该菜单文件。
大分类文件存储可以由自助餐厅提供的菜单内容的大类。在图3(A)的例子中，设置了“西餐”、“日式饭菜”、“中餐”、“盖浇饭”等。
图3(B)的例子中所示的小分类文件的组成是使得其可以与大分类文件相关联。小分类文件为每个大分类存储与菜单中的项目的名称、价格及卡路里相关的信息组。图3(B)的例子示出了当在大分类文件中选择了“盖浇饭”时作为链接的目的地的“盖浇饭”的小分类文件。
另外，尽管图3未详细示出细节，菜单文件也为小分类文件的菜单中的每一项存储一幅照片。菜单的各项目的照片在顾客终端上显示并用于可视地查看菜单内容。
图4是解释配料文件的配置的视图。配料文件为菜单中的每一项存储做菜所需的配料的名称及其用量。
例如，图4的例子示出了日本菜“猪排米饭”。其中存储了180cc米饭、100g猪肉、1/4个洋葱及一个鸡蛋。这示出了用于准备一份“猪排米饭”所需的配料及其用量。另外，在要求“大份”的情况下，设置一个信息标识增加用量10％(未示出)。
在配料文件中可以为菜单中的每一项设置例如为“大份”增加的用量这样的可选信息(用“198cc米饭”或“增加10％”来记录)。例如，当选择“大份”时，也可以统一地和自动地增加配料文件中的用量。在前一种情况下增加的用量必须存储在配料文件中，而在后一种情况下，仅设置正常的用量即可，但必须计算增加的用量。
另外，在前一种情况下，也可以改变菜单中的每一项的大份或每个配料的用量。例如也可以设置用量使得仅增加米饭用量10％而不增加其他用量。另外，当菜单中还有不能作为大份提供的项目时，也可以向菜单文件中增加信息“没有大份”，从而提供友好的顾客服务。与此相反，在后一种情况下，由于配料文件的结构变得简单可以说尤其适用于在自助餐厅服务器侧没有足够的资金的情况等。
图5是解释定单接收文件的配置的视图。在定单接收文件中，存储了用于标识顾客的信息(由于使用员工自助餐厅作为例子图5中为员工编号)、就餐日期，所定食物及其数量、选项(大份等特殊要求)及其数量及付款方法。
这里，如果是员工自助餐厅，帐单基本上可以通过从工资中扣除帐单金额来支付。即使在员工自助餐厅的情况下，也有可能出现外部人员前去就餐的情况。由于不能从这种人员的工资中扣除帐单金额，因此必须可以以现金、预支卡、IC卡(电子货币)等的形式来付款。进而，当在自助餐厅用餐时员工也可以选择不从工资中扣除帐单费用。在图5所示的定单接收文件中，存储了付款方法信息及定单内容以处理定单。
在订购时指定付款方法。稍后将解释该指定方法的细节。作为付款的方法，除了该方法外也可以用信用卡支付。
另外，在会员制的商店情况下，事先在商店侧登记顾客的姓名。这就象在员工自助餐厅例子的情况下员工和自助餐厅之间的关系。这样，当去商店的人们可以指定时(换句话说当不需考虑随意走入的顾客时)，也可以统一地为每个顾客设置付款方法。当顾客可以指定并且付款方法可以指定时，也可以从定单接收文件中删去与付款方法相关的信息设置域。
图6是当自助餐厅订购配料时所使用的一个配料订购文件。在该配料订购文件中存储了与自助餐厅所订购的配料相关的信息，订购数量及供应商，而与菜单无关。
稍后将解释更新配料订购文件内容的详细方法，但是简要地说，通过参考存储在定单接收文件中的所订购的菜单中的项目的数量及存储在配料文件中的菜单中每一项所需的每种配料的量，顺序地更新配料量。然后自助餐厅侧将存储在配料订购文件中的订购数量发送给供应商。
此处，例如当订购洋葱时，可能订购的洋葱不可能少于一个。在该例子中，当存储在配料订购文件中的某种配料的量出现小数值时，该小数值自动地向上舍入到一个通常的单位数量。在洋葱的例子中，根据订购的数量和存储在配料文件中所需量计算出的所需的洋葱数量是一个小于1的小数，总计的数量自动地向上舍入为1。
另外，作为供应商信息，在图6中记录了供应商名称。这里，当供应商也有由网络连接的终端时，可以使用这些终端。由于这个原因，为了处理这种情况，可以为每个供应商存储电子邮件地址等，在订购时可以参考它们，并通过网络将订购信息自动地发送给供应商。当然，并不是所有的供应商都通过网络连接，在该例中，电话和传真号码等可以与供应商的名称记录在一起。
另外，在域“发货日期”中，设置了订购的配料何时发货的计划日期。该“发货日期”信息也可以用于检查配料是否已经发货。即在配料应该发货的日期，在那天通过参考配料订购文件读取计划要发货的配料信息(配料名称)。接着确认是否每个配料都已发货。
图7示出食物文件。它存储了在某一天(示例中是1月13日)必须做的菜单中的食物项目所需量及烹饪它们所需的配料和将它们相互关联起来后所需的量。另外食物文件中可以设置配料的发货日期(计划日期)及标识配料实际上是否发货的检查位。注意也可以在不同的文件中存储发货日期和检查位，可选择地，由于配料订购文件和食物文件部分重叠可以仅设置一个。
存储在食物文件中的信息发送给厨房终端和柜台终端，在那里，屏幕上显示烹饪所需的信息。以厨房为例，那天必须烹饪的菜单上的项目，其量及配料量等可以显示在厨房终端上。因此在烹饪时瞥一眼就可以确认做什么及做多少。另外在食物文件中设置了输入已经准备好的那天所需要的食物数量的域。该域用于为厨房获取已经做好的食物数量信息及还必须做多少的信息。
根据菜单中的项目，可能同时不能做好所有订购的数量。因此，这时必须烹饪的项目分为几部分。如果厨房终端上显示多少食物已经做好或还需做多少食物的信息，则对经营自助餐厅是非常有效的。因此食物文件存储上述信息并且厨房终端显示已经做好的食物数量或显示信息时还未做的食物数量。
另外，当有特殊要求(选项)例如要求大份时，该信息也设置在食物文件。尽管图7中未示出，也可以独立于所有所需的食物数量将大份的量和其他选项写入食物文件中(也可以是包括的数目)。因此，可以在厨房终端上显示什么选项需要做及做多少以更容易理解并减少烹饪等时的错误。
图8示出个人设置文件。在图8的例子中，为每个顾客成对地设置员工编号和密码。这些用于当顾客订购时比较被输入的密码，并被设计为不能被顾客操作所看到。
在图8中，假设不为每个顾客特定付款方法。但是如果顾客可以象上面所解释的会员制的商店中那样可以特定，则付款方法也可以特定。这样，在个人设置文件中设置了用于记录付款方法的域。另外，当不管象仅接收现金付款的情况下的顾客而使付款方法成为统一的时，可以不在有些文件中设置与付款方法相关的信息。
在本实施例中这些文件设置在自助餐厅服务器中。注意也可以修改为示于图中的文件内容合并在一个文件中。
图9是终端侧的配置的例子的视图。近年来，越来越多的个人计算机安装在工作地。因此这些平常的个人计算机等也可以用作终端。另外，当然也可以使用专门的终端来进行订购。此处个人计算机通常都配备有打印机。另外它们还可以与IC卡阅读器或写入器(表示为R/W)相连。当顾客订购时，也可以使用这些打印机和R/W。
当顾客订购时，通过使用安装在顾客的工作地处的打印机可以发布一个餐卷。通过使用平常的打印机，不需麻烦地提供专门的新打印机来打印餐卷(尽管也可以安装它们)。
另外，近年来，作为雇佣的证据，已经使用了ID卡(磁卡或IC卡)。因此当在自助餐厅就餐时可以考虑使用这种卡。尤其是，IC卡具有大的存储容量，因此如果将定单的内容写在IC卡上而不是餐卷上。就不需使用打印机打印餐卷。
图10是一个终端的内部部分的配置的方框图。该终端具有用于执行处理的CPU，与网络通信时使用的通信控制单元，存储各种类型的程序的存储器，并且在订购时输入的内容也暂时保存，一个显示器，一个打印机，一个用于输入信息的键盘和一个卡R/W。
图11是自助餐厅侧接收终端/管理终端的配置的视图。一个通常的个人计算机也可用作为这种终端。该终端与图10所示的终端具有相同的配置。在图11的情况下，省略了打印机和R/W的说明。这是由于仅说明用于实现功能的最小配置，而独立于本实施例。当然根据需要也可以提供这些装置。
图12是安装在自助餐厅的每个柜台上的柜台终端的配置的视图。柜台终端可以是通常的个人计算机等，或者考虑到顾客来到自助餐厅时必须操作终端而为了为顾客带来方便可以是专门的终端。
柜台终端具有一个显示器或卡R/W。员工的ID卡可以插入卡R/W。当员工所订购的内容被写入他的ID卡时，根据从IC卡中读取的定单内容，与由那个顾客所订购的菜单中的项目相关的信息(例如菜单中项目的名称，数量和位置)显示在显示器上。可选择地，柜台终端可以参照自助餐厅服务器，读取将ID卡插入卡R/W中的员工定单的内容，并将其显示在显示器上。当ID卡上记录员工编号等时，可以从R/W上读取它，并参考自助餐厅服务器，并显示由那个顾客所订购的菜单项目信息。该方式可以根据自助餐厅的操作方法适当地确定。不用说，也可以应用其他方法。顾客根据柜台终端显示器上所显示的指南信息可以事先接收他所订购的菜单选项。
注意也可以给柜台终端发布餐卷的功能。由图12的虚线所示的打印机用于发布餐卷。ID卡插入卡R/W时，读出所存储的定单信息并根据它从打印机中发布餐卷。
图13是厨房终端的配置的视图。当仅考虑上述的目的时，在厨房终端上显示所做的内容就足够了，因此在本实施例中，发布餐卷的打印机或卡R/W不是特别需要的(对于其他用途可能必须)。因此根据本实施例在厨房终端中未特别示出卡R/W和打印机。
图14是示出当使用自助餐厅系统订购时主要是通知顾客操作的程序流程图。
首先，当使用自助餐厅系统时，顾客从位于它的办公室的终端访问自助餐厅服务器(图中的“自助餐厅主页”)。此处在说明中使用术语“主页”的原因是考虑到在以后的时间里对因特网的使用的增长。
当访问自助餐厅服务器时，用于选择菜单的屏幕信息从自助餐厅服务器传输到终端。终端在其屏幕上显示所接收的屏幕信息。顾客从该屏幕上选择他或她想要订购的菜单项。然后，所选择的定单信息发送给自助餐厅服务器。自助餐厅服务器根据从终端发送的信息准备定单表格屏。并将其屏幕信息传输给终端。在终端所传输的定单表格屏显示在其显示器上并等待顾客输入定单表格。定单表格用于确认输入定单的内容。关于定单表格屏以后将解释。
顾客从定单表格屏输入定单内容。当确认了定单表格的输入后，作为响应，在终端上显示确认屏幕。使用该确认屏幕，顾客可以确认定单内容是否正确输入或确认他或她的定单是否应处理。
当检查完定单内容后，顾客执行确认操作。另一方面，当改变定单内容时，再次显示定单屏幕并再次输入定单。
图15解释了在图14的操作后使用安装在终端上的打印机发布一个优惠卷(餐卷)的操作。当执行确认操作时，作为确认的所输入的定单内容传输给自助餐厅服务器。响应于此，自助餐厅服务器发送对于向终端发送优惠卷所必须的信息。终端在接收到它之后编辑发布优惠卷的信息并启动打印机发布优惠卷。
图16示出当定单内容写入由顾客所持的卡(IC卡等)的情况下代替图15的处理的处理。直到确认操作在图14中被执行及定单确认被传输到自助餐厅服务器，图16的处理都与图15相似。接着，与发布优惠卷的方法相同，与订购食物相关的信息从自助餐厅服务器发送到终端。注意发布优惠卷时的信息可能与写入卡的信息完全相同。这是由于可能考虑到通常作为纸打印的优惠卷上的信息反而被写入IC卡中。当然也可以单独的为上述的每种格式例如优惠卷或卡准备信息。
当终端从自助餐厅服务器接收信息时，它向顾客显示提示将卡插入卡R/W中的消息。当顾客据此将卡插入R/W中时，终端将定单内容信息写入插入的卡中并然后弹出卡。
用于订购的处理序列是由这样的处理操作执行的。程序的细节将根据需要以后解释。
图17A，17B和图18是用于解释在订购时终端和自助餐厅侧的操作序列的细节。图的左侧示出终端侧的处理，而右侧示出自助餐厅服务器侧的处理。
在终端侧，首先访问自助餐厅服务器。响应于此，自助餐厅服务器将初始屏幕数据传输到终端。终端根据所接收的原始屏幕数据在屏幕上显示初始屏幕。
图19是初始菜单屏幕的例子的视图。初始菜单屏幕显示可以由顾客选择的菜单项目的大类及设置一个个人身份识别代码的项目(以后详细解释)。顾客首先使用初始菜单屏幕选择要订购的菜单项目的大类。
当从初始菜单选择了菜单项目的大类时，结果被通知给自助餐厅服务器。自助餐厅服务器参考菜单文件读取对应于所选择的大类的小类信息，并讲求传输给终端。在终端，所传输的小类信息显示在屏幕上。这里首先显示了菜单项目的列表。
图20示出当从图19所示的屏幕上选择日式饭菜菜单时菜单上的项目选择的列表。在菜单列表中以表格的形式显示了可以由自助餐厅提供的菜单项目名称、其价格及卡路里。当顾客从菜单屏幕上选择了特定的菜单项目时，详细的菜单显示在终端的屏幕上。
图21示出详细菜单屏幕显示的例子，并示出选择了烤鱼套餐时的例子。详细的菜单屏幕显示了所选的菜单的内容(项目)及项目的照片。通过这样，顾客可以确认他或她所选择的菜单项目的内容。注意，在图21所示的详细的菜单屏幕上，解释着大份米饭另加20日元。这样，可以通知顾客在烤鱼套餐中可以得到一个大份。
另外在详细菜单屏幕的右下角，设置了“定单”域和“返回”域。当选择了“定单”域时，显示在详细菜单屏幕上的菜单项目定单被传输到自助餐厅服务器侧。另外，当选择了“返回”域时，屏幕再次改变为选择菜单屏幕。
接收到详细菜单侧的“定单”域的选择后，自助餐厅服务器根据所选择的菜单项目编辑定单表格屏并讲求传输给终端。
图22是显示在用于从自助餐厅服务器接收信息的终端的屏幕上的定单表格的例子的视图。定单表格自动地显示定单日期。另外定单表格设置有员工编号输入域、定单显示域、定单数量显示域、选项信息选择域、可选对象数量显示域、就餐日期显示域、付款方法显示域、和个人身份标识代码输入域。
员工编号由顾客手工地或通过读取ID卡输入在员工编号输入域中。定单显示域显示在详细菜单屏幕上所选择的菜单项目的名称。可选信息选择域用于选择与各种选项(特殊要求)，例如“大份米饭”，相关的信息。选项的内容根据所选择的菜单项目确定。顾客从中适当地选择希望的内容。
由于个人的爱好或他或她的体质或健康，有许多食物不能吃或不吃。根据本实施例的选项选择也可以处理这种情况。即通过从可选信息选择域中输入他或她不能吃的项目。从订购菜单中可以删除特定的项目。在“烤鱼套餐”例子中例如可以省略“蔬菜沙拉”或删除“蔬菜沙拉”中的特定项。
另外如果自助餐厅侧可以处理它，作为进一步的选择，可以让顾客指定一个未在菜单中标识的附加项目。
在就餐日期的显示域，由于该实施例基本上考虑下一天的菜单，因此自动地显示下一天的午饭时间。注意顾客不是总要订购下一天的饭，有时也有他或她在午饭时间不能来自助餐厅就餐的情况。因此在本实施例中可以通过在就餐日期域中手工输入日期来改变就餐日期。
如果就餐日期，尤其是时间事先指定，自助餐厅侧可以为那个时间准备食物。因此，从确认屏幕所输入的就餐日期对自助餐厅侧是十分有用的。
由于在本实施例中考虑员工自助餐厅的例子，因此在付款方法域中自动地显示“工资扣除”。注意并不是所有去员工自助餐馆的顾客都是公司员工，因此也应可以选择除工资扣除之外的其他付款方法。因此当选择其他付款方法(现金付款，使用卡等)时，在付款方法域中选择所希望的付款方法。
在使用自助餐厅系统时将发生金钱交易，因此在本实施例中，通过让顾客输入他或她的个人身份识别代码来判断顾客是否正是相应的人。在自助餐厅服务器侧验证输入的个人身份识别代码及员工编号来判断所输入的代码是否正确。
当确认了该信息输入时，定单表格传输给自助餐厅服务器，响应于此，从自助餐厅服务器将定单接收确认的屏幕信息传输给终端并在终端显示。图23是定单接收确认屏幕的一个例子的视图。
在定单接收确认屏幕上，不同的项目例如订购时间，就餐日期，所定项目和数量，选项内容，如果可能还有帐单，付款方法都显示出来。顾客参考定单接收确认屏幕确认其定单是否被正确输入。
在定单接收确认屏幕的右下角，设置了一个“确认”域和一个“取消”域。当定单内容正确或未改变时，选择“确认”域。这样确认定单内容并通知自助餐厅服务器。当选择“取消”域时，显示前一个屏幕(选择屏幕等)。
当选择“确认”时，自助餐厅服务器认为定单已经被确认并象已经详细解释的那样，根据定单的输入内容，更新例如订购文件的文件内容。
这样结束制作定单处理序列。
图24是示出考虑到个人身份识别代码(密码)输入的情况下终端处的处理。当访问自助餐厅服务器并显示初始菜单时，终端判断是否选择了密码的输入(监视是否选择了项目)。当未选择密码输入时，则通过监视菜单(大类)是否被选择来判断。
此处当选择了密码输入时，终端执行图25A和25B的处理。
图25A和25B是示出设置密码的处理序列的流程图。另外图26示出密码输入初始屏幕。此处密码输入包括新输入和改变密码，从而通过使用示于图25A和25B的初始屏幕执行顾客选择。
首先，将解释新输入。这是在顾客新使用自助餐厅系统等时所执行的。
当从密码输入的初始菜单选择“新输入”时，在屏幕上显示个人身份识别代码的新输入屏幕(图27)。在个人身份识别代码新输入屏幕上设置了员工编号输入域和个人身份识别代码输入域。顾客通过使用个人身份识别代码的新输入屏幕输入要输入的秘密代码及他或她的员工编号。注意，为了防止个人身份识别代码被他人看见，在图27的例子中，显示星号而不是输入的个人身份识别代码的数字。
当从个人身份识别代码的新输入屏幕上输入了员工编号和个人身份识别代码时，接着显示用于确认个人身份识别代码的新输入的屏幕(图28)。这里通过再次输入当前输入的个人身份识别代码，可以确认个人身份识别代码是否正确并输入顾客所希望的个人身份识别代码。
这里，当从用于个人身份识别代码新输入的屏幕输入的个人身份识别代码与用于确认个人身份识别代码的输入的屏幕上输入的个人身份识别代码相匹配时，结束个人身份识别代码输入处理，并在终端上显示图19所示的初始菜单屏幕。
另一方面，当个人身份识别代码又未正确输入时，在屏幕上显示通知顾客个人身份识别代码输入错误的消息，例如“请再一次输入指定的个人身份识别代码”，以提示顾客再一次输入个人身份识别代码。
接着，将解释改变个人身份识别代码时的处理。
当在屏幕上选择了“改变代码”以输入个人身份识别代码时，终端显示用于改变个人身份识别代码的屏幕(图29)，顾客此时输入个人身份识别代码和其员工编号。由于该处理，确认了希望改变个人身份识别代码的人的合法性。
当当前的个人身份识别代码正确时，从新个人身份识别代码输入域输入一个新的个人身份识别代码(图30)。接着，与新输入的情况相同，在终端上显示图28中所示的用于确认个人身份识别代码的输入的屏幕。
当输入个人身份识别代码时，该信息传输给自助餐厅服务器侧。接着，存储在与员工编号相链接的个人信息文件中。
在输入个人身份识别代码后，再一次显示初始菜单，接着想要制作定单的顾客可以象制作平常的定单那样从菜单中选择项目。
这里，如果可以输入姓名、地址等，而代替输入员工编号，图25A和25B的处理可以用于在通常的自助餐厅中进行登记使用。此时，作为付款方法的选择，可以用信用卡付款。当很难识别顾客时，不象在员工自助餐厅，也可以要求输入信用卡号码等并检查顾客在付款能力方面是否有问题，这也是有用的。
图31是在接收定单后在自助餐厅服务器侧的处理程序的流程图，当从顾客传输过来定单后，自助餐厅服务器首先往定单接收文件中写入员工编号，他或她到来的日期，所订购的菜单项目，数量，如果有的话还有选项信息。接着，自助餐厅服务器对应于所订购的菜单项目参考配料文件。
当参考配料文件时，自助餐厅服务器接着从配料文件中读取对应于订购项目的配料和用量，并据此更改配料文件。此处，它在配料文件中为每种配料量增加对应于新订购的菜单项目的数的量。如前所述，配料文件用于订购配料，因此当量小于单位数字时，统计的量向上舍入到一个单位数，并记录在数量域中。
接着，根据传输的定单更新食物文件的内容。食物文件为菜单中的每一项记录某一天必须烹饪的菜单项目的数量(包括配料)。当制作新定单时，更新食物文件中的数量。相似地，菜单中每一项的配料量被更新。
在根据本实施例的自助餐厅系统中，为了方便订购配料，设置了接收定单的截止期限。图32是从终端接收定单时在自助餐厅服务器处的处理的视图。这里，当终端选择菜单项目时，它判定截止期限是否已过。当截止期限未过时，接收定单，但是当截止期限已过时，不能接收定单。
另外，为了订购配料以在某一天及时准备烹饪，例如，必须最迟在前一天的下午从供应商那里订购配料。因此，当到达截止期限时，自助餐厅服务器侧读取配料文件内容并从供应商处订购所记录的配料。
有时顾客想要改变或取消他或她所订购的定单的内容。这时如果在截止期限之前，根据本实施例的自助餐厅系统可以处理它。图33A和33B是用于解释用于此用途的处理程序的流程图。
当取消定单时，顾客访问自助餐厅服务器并选择取消屏幕(未特别示出)。然后，自助餐厅服务器判定取消操作是否在截止期限之后执行。当已过截止期限时，配料可能已经订购，因此自助餐厅服务器不能接受定单的取消(改变)。因此终端被指示显示通知顾客取消操作已过截止期限的屏幕。同时通知顾客取消要交取消费。
接着自助餐厅服务器通知终端显示用于确认取消的可能性的屏幕。当不可能取消时，不取消定单并且结束处理。另外，当操作终端来指示取消时，处理取消。
注意，可能有即使截止期限已过再取消也不付取消费的情况。如果在那时例如用现金付款，这尤其是一个问题，因此如果截止期限过后取消定单，必须确认取消费是否已经支付。因此必须限制那些截止期限后经常取消定单并不付取消费的顾客使用自助餐厅系统。
另外即使在截止期限之前有取消操作也可以处理取消。
当处理取消时，自助餐厅服务器侧参考接收文件并读取相关顾客的定单。然后编辑取消屏幕并将其传输到终端。
取消屏幕显示至少由相关顾客所订购的项目及就餐日期的计划日期。注意当相同的顾客定了好几天或好几个时间的定单时，在一个列表上显示该相关顾客计划到自助餐厅的所有日期，顾客可以从中选择。当不能在一个屏幕上完全显示时，可以采用分割显示。
当显示取消屏幕时，顾客选择要取消的内容并执行取消操作。取消操作之后，与在订购时的确认屏幕相同，显示用于确认取消内容的屏幕。当确认屏幕上确认了顾客的取消时，自助餐厅服务器根据取消内容更正或更新每个文件的内容。
注意，当然，在取消处理中，不仅可以取消某个日期定单的所有内容，也可以仅取消一部分。例如需要取消同一天所定的多个项目中的一个项目的情况。
另外可以通过相似的处理处理定单的改变。这时，代替取消，改变的内容写入每个文件。
图34是示出使用厨房终端处理程序的流程图。厨房终端可以显示在那天必须做的菜单项目及其数量。图34示出用于该目的的程序。
图35示出厨房终端上所显示的屏幕的例子。在图35的例子中，那天必须做的菜单项目及其数量一起显示。为了显示细节，在厨房终端上选择图35屏幕上要显示的项目。为了选择项目，可以使用键盘或不同类型的点设备。如果在屏幕上形成有触摸屏，可以仅通过触摸屏幕选择项目。
此处，将解释为每个项目显示配料的细节的例子。当“猪排米饭”在图35的屏幕上得以选择时，烹饪猪排米饭所选的配料，制作所有的食物所需的配料量及烹饪一个项目所需的配料量一起显示出来(图36)。另外，在屏幕的右下角显示用于选项的参考域。此处显示关于任何选项的存在及其内容和配料量的改变等的信息。注意在图36中，示出了显示用于制作所有食物所需的配料和数量及每个项目的配料和数量的例子，但稍后将详细解释，也可以根据剩下的未做的食物数量的输入和显示制作剩下的未做的食物数量所需的配料数量。
当烹饪菜单上的某项目时，厨房终端用于输入它还未做。这里，也有向上面所解释的很难同时烹饪所有订购的项目的情况，因此可能为菜单上的每个项目输入已经做好的食物的数量。其内容反映在食物文件中并且食物文件中的定单数量用已经做好的食物总量更改(减少)。厨房终端可用于确认是否所有的食物已经做好或还有多少食物未做。
在图35的屏幕上也设置了标识所有的食物已经做好的信息域。当菜单上相关项目的预订数量的食物已经做完时，加上一个标识它的标记(图示的一个圈)。这样瞥一眼就可以知道不需象在图35中所示的那样再制作烤鱼套餐。注意图35中并未特别显示还未做完的所有菜单项目。为了显示剩下的未做的食物数量，通过使用厨房终端选择菜单的一个项目。当使用触摸屏时，通过触模菜单上特定项目已做完区域，菜单上该相关项目剩下的未做食物数量被显示在显示屏上。
图37示出了一个表示猪排米饭的未做完食物剩余数量的屏幕的显示例。这里，与所有未做的食物数量一起，为每个选项显示未做完食物剩余数量，其中包括正常的食物的情况。通过执行这种显示菜单上的每个项目可以在厨房中没有任何浪费或库存的情况下制作。
注意，可以与图35的已做完屏幕一起显示剩余数量。在此情况下，可以减少切换屏幕的操作。注意，如果在图35的屏幕上同时显示选项，可能屏幕太细微很难辨认，因此包括选项的未做完食物剩余数量最后显示在不同屏幕上。这样可能需要在图35的“已做完”域中显示例如未做完食物剩余数量。
图38示出用于检查示于厨房终端上的商品的发货的屏幕的例子。该屏幕用于确认实际上是否为每个配料都发货了。为在屏幕上已被确认的发货的配料增加一个圆圈。当例如存在缺货的原因等时，也显示它(说明中用长方形)。
图39示出用于厨房终端的键盘的一部分。用于指示特定功能的功能键与十个数字键部分安排在一起。对于功能键，在所示的例子中，设置了功能例如“确认特定定单(选项)”，“确认检查”，“查看配料”，“输入做完的食物”及“查看备注”。但它们可进行适应性修改。例如如果按下“查看配料”功能键，显示图38所示的屏幕。
图40是示出当顾客走入自助餐厅时处理和操作程序的流程图。这里，以使用ID卡作为例子。
当顾客到达时，他或她将自己的ID卡插入柜台终端。该处理也可以象所说明的那样通过手工地从终端输入员工编号来执行。
这样，柜台终端参考自助餐厅服务器，并从接收文件中读出关于由相应的顾客所订购的菜单项目的信息，并将它们显示在柜台终端上(图41)。另外，它显示标识他或她在哪儿可以获得订购的项目的信息。这可以通过将柜台与菜单中的每一项相互关联，通过事先在接收文件或菜单文件中存储信息来处理。
另外它为订购选项的顾客显示信息以确认选项被订购了。
这里，通过插入ID卡和读取他或她的ID，在厨房终端等上显示到达自助餐厅的并发出了附加有例如选项这样的特定条件的定单的顾客。因此，可以可靠地为相应的顾客服务选项例如大份。
当顾客接收到所定项目后，从食物文件中减去所接收的项目数目。这样可以随时确认菜单的项目未做的剩余量。
当在IC卡中记录一个定单的内容时，不需在显示订购的项目时参考自助餐厅服务器。
另外对于付款，在订购时事先指定付款方法。因此当顾客使用自助餐厅终端时，它显示要求他或她确认付款方法的屏幕。当帐单从工资中扣除，或没有当场用现金交易时，终端将显示“已付款”等。另外当选择了用现金或用信用卡付款时，终端显示指示顾客去另一个现金柜台付款的信息。
这里，为了防止顾客的欺骗行为，当指定用现金付款的顾客未付款时，可以启动一个警报或其他可采用的装置。
图42是在检查完配料后的处理的流程图。当检查配料时，根据其输入添加一个食物文件检查标志。另外，通过从厨房终端的指令从文件中读取食物内容并显示在厨房终端上。
每次烹饪菜单上的一项时，从厨房终端输入已做的项目及其数量以更新食物文件中的数量等。
图43是当作为定单的结果完全在指定的就餐日期和时间预订自助餐厅时在一个终端显示的屏幕的例子的视图，这对于使用系统的仅靠预订的餐馆是极其有用的。在屏幕的底部，设置了确认域。
这里由于通过网络将终端和自助餐厅连接起来，顾客的要求等可以容易地传输到自助餐厅侧。因此也可以使终端显示一个调查屏幕并请求顾客从该屏幕输入在将来他们想在菜单上看到什么。
自助餐厅服务器统计来自于顾客的调查的答案。因此可以知道顾客的喜欢并提供满足顾客要求的菜单。
在此之前，根据在自助餐厅侧过去的结果确定菜单或根据世界流行的烹调趋势确定菜单。在前一种情况下很难为菜单增加新的项目，在后一种情况下，如果世界流行的烹调趋势与自助餐厅的世界顾客之间的差别太大，也不可能为顾客提供所希望的食物。
根据本实施例，这种问题可以被接近，并且可以改善提供给顾客的服务。
注意，在上述实施例中，解释所基于的例子是订购的配料数量及准备的食物数量与由顾客所订购的食物数量相等。但是，除了要求预订的自助餐厅，那天还有可能有随意走进的顾客。这时，如果仅准备预订份数的食物，那些没有预订而随意走进餐馆的顾客将不能在餐馆得到服务，或吃了为别人准备的食物，从而有可能其他预订了食物的顾客不能得到服务。
为了处理这个问题，可以考虑稍微增加所订购的配料数量或增加那天所准备的食物份数。具体而言，在图6的配料订购文件和图7的食物文件中所设置的食物份数和配料量可以稍微增加。即，订购的配料量比为准备预订的食物所需的食物数量稍微多一些，并且准备的食物份数更多一些。
这里，对于自助餐厅侧来讲根据经验确定增加的量是最可靠的，但是当没有了做这种决定的根据时，最简单的方法是为菜单的每个项目统一地增加数量。
但是这种过量订购和烹饪可能造成浪费。不用说，与不根据所要求的配料量和所要求的食物份数来进行预测相比，即与没有任何所存在的基本图表的情况来进行预测相比，当使用订购系统来事先获得预订信息时，可以事先确定所需的最小量，从而可以容易地降低订购和烹饪的浪费。
另外，在这种情况下，必须确保预订的顾客所订购的食物，因此必须持续地掌握可以为没有预订的顾客提供的食物份数。
可以为没有预订的顾客提供的食物份数等于所准备的食物份数减去预订的食物份数。该量独立于预订数量。一旦顾客走进来，通过使用ID卡等确定该顾客是否是做过预订的顾客。根据他是否做过预订来改变该顾客所被领入的方向。
做过预订的顾客被领到为预订的顾客服务的地方。未做预订的顾客被领到为没有预订的顾客服务的地方。在两种情况下，只要端上食物，就计算剩下的食物。尤其是，总是显示为未做预订的顾客所提供的食物的剩下的份数。最后是，为已经卖完的菜单上的项目显示标识“没有剩余食物”的消息。
可选地，可以显示可以做的项目及其数量的列表以使没有做预订的顾客瞥一眼就可以判定到餐馆后餐馆供应什么。
另外，由于订购系统没有确认没有预订的随意走入的顾客的标识，最好请求顾客指明付款方法，例如用现金付款以避免从工资中扣除帐单等，从而避免以后的麻烦。
总结本发明的效果，通过使用这样的订购系统，可以达到下述效果(1)尤其在自助餐厅或餐馆中，可以事先确定菜单中的什么项目被预订了，数量是多少。因此，可以根据这些数目确定要准备的食物份数和订购的配料量，从而可以不必依赖直觉来高效地经营自助餐厅或餐馆。
(2)可以自动地总计和更新来自于顾客的定单内容，从而自助餐厅侧可以节省合计帐单的麻烦步骤。
(3)可以自动地根据定单内容向供应商订购配料，从而自助餐厅侧可以防止定单等中的错误。
(4)顾客可以事先通过使用办公室等的个人计算机等方便地订购。由于可以容易地预订餐馆中的位子和食物，顾客享受到更多的方便。另外，由于自助餐厅侧根据定单内容订购配料和准备食物份数，顾客得不到所希望的服务的可能性很小。
(5)由于可以根据顾客或环境选择付款方法，顾客享受到更多的方便。
(6)由于事先接受定单，可以根据定单数量来订购配料和制作食物。因此与传统的情况相比，大大地减少了配料的过量订购和食物制作上的浪费。
权利要求
1.一种订购系统，具有一个自助餐厅服务器和一个由顾客操作的终端，它们通过一条传输线路相互连接，其中自助餐厅服务器具有一个菜单文件，用于存储关于由自助餐厅所提供的菜单的信息；一个配料文件，用于存储存储在菜单文件中的菜单的每一项所必须的配料名称和用量；一个接收文件，用于存储与从所示终端所接收的由顾客所订购的菜单上的项目相关的信息；一个配料总计文件，用于根据顾客的定单总计每种配料所需的用量；及一个食物文件，用于存储如下信息，即在某段时间内必须制作的菜单项目，其数量，及制作这些菜单项目所需的配料。
2.根据权利要求1所述的订购系统，其特征在于在所述自助餐厅服务器，与每种配料的供应商相关的信息存储在所述配料总计文件中。
3.根据权利要求2所述的订购系统，其特征在于所述自助餐厅服务器通过一条传输线路与供应商处的终端相连；供应商的终端标识信息存储在所述配料总计文件中；并且根据在所述自助餐厅服务器订购配料时的所述终端标识信息，通过传输线路将定单信息传输到供应商终端。
4.根据权利要求1所述的订购系统，其特征在于设置接受顾客定单的截止期限，并在过了截止期限后根据配料总计文件的信息订购配料。
5.根据权利要求2所述的订购系统，其特征在于设置接受顾客定单的截止期限，并在过了截止期限后根据配料总计文件的信息订购配料。
6.根据权利要求3所述的订购系统，其特征在于设置接受顾客定单的截止期限，并在过了截止期限后根据配料总计文件的信息订购配料。
7.根据权利要求1所述的订购系统，其特征在于在接收文件中存储如下信息，即，顾客所订购的菜单项目的名称及其数量，就餐时间，付款方法和特殊要求。
8.根据权利要求1所述的订购系统，其特征在于在所述食物文件中存储已经准备好的菜单项目的数量。
9.根据权利要求8所述的订购系统，其特征在于根据显示在屏幕上的已经准备好的菜单项目的数量和未做食物的数量计算未做食物的数量。
10.根据权利要求1所述的订购系统，其特征在于在所述食物文件中为菜单中的每一项存储与未做食物数量相关的信息。
11.根据权利要求1所述的订购系统，其特征在于在所述食物文件中为每种配料设置用于标识供应商是否已经为其发货的标记。
12.根据权利要求1所述的订购系统，其特征在于在所述配料总计文件中为每种配料设置用于标识供应商是否已经为其发货的标记。
13.根据权利要求1所述的订购系统，其特征在于在所述菜单文件中为每一项存储照片信息。
14.一种安装在自助餐厅中的数据处理装置，具有一个菜单文件，用于存储关于由自助餐厅所提供的菜单的信息；一个配料文件，用于存储存储在菜单文件中的菜单的每一项所必须的配料名称和用量；一个接收文件，用于存储与从所示终端所接收的由顾客所订购的菜单上的项目相关的信息；一个配料总计文件，用于根据顾客的定单总计每种配料所需的用量；及一个食物文件，用于存储如下信息，即在某段时间内必须制作的菜单项目，其数量，及制作这些菜单项目所需的配料。
15.根据权利要求14所述的数据处理装置，其特征在于所述数据处理装置与一个订购终端相连，顾客从该订购终端输入他或她的定单内容；及根据所述订购终端的操作接受顾客的定单。
16.一种用于接收顾客定单的订购系统，具有一个供顾客输入定单内容的终端；一个用于从所述终端接收定单输入的服务器，所述服务器具有一个产品文件，用于存储与可以由顾客订购的产品相关的信息及一个定单文件，用于存储包括顾客所选择的产品的定单内容。
17.根据权利要求16所述的订购系统，其特征在于所述服务器进一步具有一个定单文件，其中存储与产品及每个产品的供应商相关的信息。
18.根据权利要求16所述的订购系统，其特征在于所述服务器进一步具有一个文件，其中设置了一个检查标志，用于标识向一个供应商订购的产品是否已经发货。
19.根据权利要求16所述的订购系统，其特征在于定单文件存储由一个顾客所要求的特殊要求。
20.一种用于接收顾客定单的订购系统中的订购方法，包括显示与可以在一个订购终端订购的产品相关的信息；根据来自于订购终端对产品的选择更改存储与在接收终端中的定单内容相关的信息的定单文件的内容。
21.一种用于接收顾客定单的订购系统中的订购方法，包括显示可以在订购终端上订购的产品列表屏幕，顾客从该订购终端输入定单内容；显示根据顾客对产品的选择在订购终端上输入定单内容的定单表格屏幕；显示响应于来自于定单表格屏幕的定单内容的输入使顾客确认通过订购终端所输入的定单内容的确认屏幕；在顾客确认显示在确认屏幕上的内容后接受定单。
22.根据权利要求21所述的订购方法，进一步包括，当显示产品列表时首先显示可以由顾客订购的产品大类列表屏幕；及显示属于由顾客从大类列表屏幕上所选择的大类产品的小类产品列表屏幕。
23.一种用于接收来自于订购终端的顾客产品定单的订购系统，包括当已经输入来自于顾客的定单时，判定接收定单截止期限是否已过；当截止期限未过时，接受顾客定单；当截止期限已过时，在订购终端上显示标识截止期限已过的消息，并且不接受定单。
24.一种用于从顾客接收产品定单的订购系统，包括一个商店服务器，具有用于存储关于可以从商店买到的产品的信息的菜单文件；及一个终端，通过网络与所述商店服务器相连，并由顾客操作；从而所述顾客通过所述终端访问所述商店服务器以选择作为信息在所述菜单文件中存储的产品，从而接收所选择的产品定单。
全文摘要
一种用于自助餐厅等的订购系统,包括一个自助餐厅服务器,具有一个菜单文件,一个配料文件等,和通过网络连接起来的供顾客使用的终端PC。顾客通过从终端PC访问自助餐厅服务器来制作定单。顾客根据从菜单文件所读取的关于自助餐厅的菜单的信息从菜单中选择他们想要的食物。根据来自于顾客的定单相继修改如下信息,即那天要做的食物及其数量以及必须订购的配料及其用量。
文档编号G06Q50/00GK1236929SQ9910706
公开日1999年12月1日 申请日期1999年5月26日 优先权日1998年5月26日
发明者野口裕, 篠崎治, 小林康秀, 竖月中夫, 增田稔, 西泽俊辅 申请人:富士通株式会社