CN112017076A - 餐饮服务信息处理方法及装置 - Google Patents

Abstract

本申请实施例公开了餐饮服务信息处理方法及装置，其中，所述方法包括：服务端获得同一目标服务场所中，多个餐厅对象、多个餐品对象、多个厨房对象的属性信息，以及对象之间的对应关系信息；接收到餐饮服务请求后，确定所述餐饮服务请求中对应的目标餐厅以及目标餐品信息；根据餐品对象与厨房对象之间的对应关系，确定可为所述目标餐品提供加工制作服务的目标厨房，并生成对应的加工制作任务，发送到所述目标厨房关联的客户端。通过本申请实施例，能够针对酒店餐饮等复杂场景，提升效能、节省成本，提升用户体验。

Description

餐饮服务信息处理方法及装置

技术领域

本申请涉及餐饮服务信息处理技术领域，特别是涉及餐饮服务信息处理方法及装置。

背景技术

酒店是一种给宾客提供歇宿和饮食的场所，通常可以以它的建筑物为凭证，通过出售客房、餐饮及综合服务设施等向客人提供服务。随着商品对象信息服务系统向更多领域的发展，酒店也成为了领域之一。通过这种服务系统，用户可以实现在线的客房预订，线上付款，等等。

关于酒店场景中的餐饮服务，与传统饭店等有很大的不同。例如，在酒店场景中，可能会有多个餐厅，包括中餐厅、西餐厅、大堂吧等。每个餐厅的在不同用餐时段是否营业也可能会不同，例如，中餐厅可能只有中餐和晚餐时段营业，西餐厅可能是中餐、下午茶、晚餐时段营业。大堂吧可能在全部时段都营业，等等。另外，每个餐厅都可能会提供多种点餐模式，例如，零点、固定套餐、定制套餐、自助餐等。再者，厨房通常也会有多个，同一个餐厅的菜品可能需要有不同的厨房进行加工制作，等等。可见，餐厅与时段时间可能是多对多的关系，餐厅与点餐模式也可能是多对多的关系，餐厅与厨房仍然可能是多对多的关系。

而现有技术中提供的帮助用户进行自助点餐的应用，通常是针对传统饭店而设计的。在这种传统的饭店中，通常是只有一个餐厅，一个厨房，因此，只需要为消费者用户开发一个简单的点餐界面，消费者通过该界面发起点餐，之后，具体的点餐信息会发送到厨房，厨房打印出纸质订单，交给具体的厨师进行餐品的加工制作即可，流程非常简单。

但是，上述现有技术中的实现方案在酒店餐饮的复杂场景中是不适用的，因此，针对酒店餐饮的复杂场景，如何在帮助企业提升效能、节省成本的同时，给消费者带来全新的体验，成为需要本领域技术人员解决的技术问题。

发明内容

本申请提供了餐饮服务信息处理方法及装置，能够针对酒店餐饮等复杂场景，提升效能、节省成本，提升用户体验。

本申请提供了如下方案：

一种餐饮服务信息处理方法，包括：

服务端获得同一目标服务场所中，多个餐厅对象、多个餐品对象、多个厨房对象的属性信息，以及对象之间的对应关系信息；

接收到餐饮服务请求后，确定所述餐饮服务请求中对应的目标餐厅以及目标餐品信息；

根据餐品对象与厨房对象之间的对应关系，确定可为所述目标餐品提供加工制作服务的目标厨房，并生成对应的加工制作任务，发送到所述目标厨房关联的客户端。

一种餐饮服务信息处理方法，包括：

第一客户端提供同一目标服务场所中可选的多个餐厅对象、多个餐品对象信息；

根据被选中的目标餐厅以及目标餐品对象，生成餐饮服务请求；

将所述餐饮服务请求提交到服务端，以便所述服务端根据餐品对象与厨房对象之间的对应关系，确定可为所述目标餐品提供加工制作服务的目标厨房，并向所述目标厨房发送加工制作任务信息。

一种餐饮服务信息处理方法，包括：

第二客户端提供用于针对目标服务场所进行预约订餐信息录入的操作界面；其中，所述目标服务场所中包括多个餐厅对象、多个餐品对象以及多个厨房对象；

通过所述操作界面接收录入的预约订餐信息，并提交到服务端；

接收所述服务端返回的预约结果展示界面，并将界面信息提供给提出预约订餐服务需求的消费者用户关联的终端设备。

一种餐饮服务信息处理方法，包括：

第三客户端接收加工制作任务；其中，所述第三客户端为目标服务场所中目标厨房关联的客户端；所述目标服务场所中包括多个餐厅对象、多个餐品对象以及多个厨房对象；所述加工制作任务是根据其中一目标餐厅以及目标餐品对应的用餐服务请求生成的；

对所述加工制作任务关联的目标餐厅以及目标餐品信息进行展示。

一种餐饮服务信息处理装置，包括：

信息获得单元，用于获得同一目标服务场所中，多个餐厅对象、多个餐品对象、多个厨房对象的属性信息，以及对象之间的对应关系信息；

信息确定单元，用于接收到餐饮服务请求后，确定所述餐饮服务请求中对应的目标餐厅以及目标餐品信息；

任务处理单元，用于根据餐品对象与厨房对象之间的对应关系，确定可为所述目标餐品提供加工制作服务的目标厨房，并生成对应的加工制作任务，发送到所述目标厨房关联的客户端。

一种餐饮服务信息处理装置，包括：

信息提供单元，用于提供同一目标服务场所中可选的多个餐厅对象、多个餐品对象信息；

请求生成单元，用于根据被选中的目标餐厅以及目标餐品对象，生成餐饮服务请求；

请求提交单元，用于将所述餐饮服务请求提交到服务端，以便所述服务端根据餐品对象与厨房对象之间的对应关系，确定可为所述目标餐品提供加工制作服务的目标厨房，并向所述目标厨房发送加工制作任务信息。

一种餐饮服务信息处理装置，包括：

界面提供单元，用于提供用于针对目标服务场所进行预约订餐信息录入的操作界面；其中，所述目标服务场所中包括多个餐厅对象、多个餐品对象以及多个厨房对象；

订餐信息接收单元，用于通过所述操作界面接收录入的预约订餐信息，并提交到服务端；

结果展示单元，用于接收所述服务端返回的预约结果展示界面，并将界面信息提供给提出预约订餐服务需求的消费者用户关联的终端设备。

一种餐饮服务信息处理装置，包括：

任务接收单元，用于接收加工制作任务；其中，所述第三客户端为目标服务场所中目标厨房关联的客户端；所述目标服务场所中包括多个餐厅对象、多个餐品对象以及多个厨房对象；所述加工制作任务是根据其中一目标餐厅以及目标餐品对应的用餐服务请求生成的；

展示单元，用于对所述加工制作任务关联的目标餐厅以及目标餐品信息进行展示。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，能够实现对酒店等服务场所中复杂场景下，多个餐厅、多个餐品、多个厨房等的数字化表达，并且可以保存彼此之间的多对多的关系。这样，就可以实现对具体下单、加工制作、上桌等全流程的数字化实现。用户可以通过线上操作的方式，实现对用餐服务请求的提交，服务端则可以根据接收到的请求，生成具体的加工制作任务，并根据餐品与厨房之间的对应关系，分配到具体的厨房进行加工制作，等等。通过这种数字化的处理流程，可以提高效率，提升服务场所的服务效能，降低成本，同时提升用户体验。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的系统架构的示意图；

图2是本申请实施例提供的第一方法的流程图；

图3是本申请实施例提供的服务场所与餐厅的关系示意图；

图4-1、4-2是本申请实施例提供的用户界面示意图；

图5是本申请实施例提供的信息录入界面示意图；

图6是本申请实施例提供的厨房侧展示界面示意图；

图7是本申请实施例提供的桌位侧展示界面示意图；

图8是本申请实施例提供的第二方法的流程图；

图9是本申请实施例提供的第三方法的流程图；

图10是本申请实施例提供的第四方法的流程图；

图11是本申请实施例提供的第一装置的示意图；

图12是本申请实施例提供的第二装置的示意图；

图13是本申请实施例提供的第三装置的示意图；

图14是本申请实施例提供的第四装置的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

本申请实施例针对酒店等目标服务场所中，复杂的餐饮服务场景，提供了相应的解决方案。通过该方案，可以实现对同一个目标服务场所中涉及到的多个餐厅、多个餐品、多个厨房，甚至多个用餐时段、多个消费模式等进行数字化表达，从而实现这种复杂场景下的全流程数字化。通过这种方式，消费者用户可以发起在线的用餐服务请求，包括即时点餐、预约订餐，或者还可以通过店内的员工用户进行预约订餐，等等。具体收到用户服务请求后，服务端还可以根据具体餐品与厨房之间的对应关系，生成对应的加工制作任务，发送到目标厨房关联的客户端。即使同一次服务请求中包括多个餐品，不同的餐品需要由不同的厨房进行加工制作，也能够实现准确的任务分配。另外，具体的消费模式可以有多种选择，包括进行零点、套餐、自助餐、会议或者公司团餐、自定义菜单，等等，都可以通过信息化的方式来实现，而不需要由店内的员工或者经理等进行手工的记录，从而可以提高效率。再者，还可以通过对餐厅内具体桌位的数字化表达，还可以避免预订过程中的桌位冲突等问题。另外，对于酒店等商家而言，则可以提高效率，提升效能，节省成本。

为了达到上述目的，具体实现时，如图1所示，首先可以提供服务端，该服务端可以预先对餐厅、餐品、厨房等进行数字化表达，分别对应餐厅对象、餐品对象、厨房对象，并且可以分别定义各自的属性。服务端通过预先保存上述各种对象的属性信息以及对应关系，可以对外发布具体的餐厅或者餐品的信息，在接收到具体的用餐服务请求后，对应生成具体的加工制作任务，然后，根据餐品与厨房之间的对应关系，将具体的加工制作任务分配到对应厨房，由厨房进行加工制作。其中，同一厨房可能会同时对多个餐厅对应的用餐服务中相关的餐品进行加工制作，制作完成的餐品会交付到具体的餐厅，以进行餐品的上桌操作，等等。

其中，为了方便与服务端进行信息交互，还可以提供多种客户端。例如，首先可以为消费者用户提供第一客户端，服务端可以将具体服务场所内，多个餐厅对应支持的用餐时段、消费模式、餐品等信息进行发布，第一客户端则可以进行提供即时点餐，或者预约订餐等操作入口，使得消费者用户能够根据具体的需求发起具体的用餐服务请求。另外，还可以通过第一客户端实时反馈具体餐品的状态等信息，使得用户便于获知具体餐品的加工制作状态，等等。

另外，还可以为餐厅内的员工用户等提供第二客户端，在消费者用户自己未安装第一客户端，或者，在使用第一客户端进行点餐或者预订时出现问题等情况下，消费者用户可以通过电话等方式联系具体的员工用户，此时，员工用户可以通过其第二客户端来录入具体所需的用餐服务信息。

另外，还可以为具体的厨房提供第三客户端，其中，厨房中可以配备Pad等形式的终端设备，该第三客户端可以运行在这种终端设备中。通过这种第三客户端，可以接收服务端分配的加工制作任务信息，还可以输出到大屏幕设备中展示，使得具体的加工作业人员能够获知具体所需加工制作的餐品信息，等等。另外，在具体的加工制作过程中，还可以通过这种第三客户端提交具体餐品的加工制作状态或者进度信息。这样，服务端可以将这种信息同步给具体消费者用户的第一客户端，等等。

再者，还可以为具体餐厅内的桌位等配备终端设备，并在终端设备中运行第四客户端，具体的餐品加工制作进度等信息也可以发送到该第四客户端。这样，消费者用户即使没有安装第一客户端，也能通过该第四客户端查看自己的所点的餐品的加工制作进度信息。

下面对本申请实施例提供的具体技术方案进行详细介绍。

实施例一

首先，该实施例一从服务端的角度，提供了一种餐饮服务信息处理方法，参见图2，该方法具体可以包括：

S201：服务端获得同一目标服务场所中，多个餐厅对象、多个餐品对象、多个厨房对象的属性信息，以及对象之间的对应关系信息；

例如，关于餐厅对象，其属性可以包括id、名称、支持的用餐时段(早餐、午餐、下午茶、晚餐、夜宵等等)、支持的餐品列表、支持的消费模式(零点、套餐、自助餐、自定义餐品，等等)，等。其中，同一服务场所内可以包括多个餐厅，不同的餐厅支持的用餐时段、餐品、消费模式等都可能会不同，因此，可以分别对各个餐厅在上述多个维度上的属性信息进行配置。另外，在具体实现时，由于用餐时段、消费模式等通常也会有多种，因此，也可以用数字化的方式进行表达，对应用餐时段对象、消费模式对象。其中，用餐模式对象的属性可以包括id、名称、时间、支持的消费模式等。消费模式对象的属性可以包括自助、半自助、套餐(自由组合)、套餐(固定菜单)、零点、预订、自定义菜单，等等。另外，还可以对预订相关、计费相关的信息等进行配置。再者，同一个餐厅中通常会包括多个桌位，为了方便进行预订时选择桌位，且避免桌位之间相互冲突，还可以对桌位也进行数字化表达，对应桌位对象，具体的属性可以包括id、位置、状态(空闲、锁定等)，等等。

关于餐品对象，其属性可以包括id、名称、可提供加工制作服务的厨房，等等。其中，同一个餐厅中支持的餐品有多种，不同的餐品可能对应不同的厨房，也就是说，对于同一个餐厅，可能通过多个不同的厨房为其售卖的餐品提供加工制作服务，因此，可以针对同一餐厅中的多个不同餐品在上述厨房维度上的属性分别进行配置。

关于厨房对象，其属性可以包括id、名称、餐品信息、后厨流程(例如，分料、切配、制作等)，等等。

总之，如图3所示，服务场所与餐厅之间的一对多的关系，餐厅与支持的用餐时段(也可以称为“活动”)之间是一对多的关系，用餐时段与消费模式(也称为“子活动”)之间是一对多的关系，消费模式与餐品之间的多对多的关系，餐品与厨房之间又是多对一的关系，等等。本申请实施例中，通过对上述各种对象的数字化表达，可以实现对各种复杂关系的数字化处理，以提升效率，降低管理成本，提升用户体验。

S202：接收到餐饮服务请求后，确定所述餐饮服务请求中对应的目标餐厅以及目标餐品信息；

其中，具体的餐饮服务请求可以有多种来源，例如，可以来自消费者用户关联的第一客户端，也可以来自员工用户关联的第二客户端。具体的餐饮服务请求可以对应有目标餐厅、餐品等信息。另外，在可选的方式下，还可以包括用餐时段、消费模式等信息。具体的，上述信息都可以通过前述第一客户端或者第二客户端进行选择或者录入。

其中，消费模式可以包括即时点餐的信息，也可以包括预约预订的信息，等等。服务端可以根据具体消费模式的不同，控制加工制作任务的生成以及分配时机。例如，对于即时点餐类型的服务请求，可以立即生成加工制作任务，并发送到具体的厨房进行制作。而对于预约订餐类型的服务请求，则可以首先生成对应的预约订单，等到具体预约的用餐日期或用餐时段到来或即将到来时，再生成具体的加工制作任务，并分配到对应的厨房进行加工制作。其中，具体可以以餐品为单位生成加工制作任务，不同的餐品对应不同的厨房时，可以将具体的任务分配到不同的厨房中进行加工制作。

关于具体的餐饮服务请求，可以是通过消费者用户关联的第一客户端进行发起的。在这种情况下，可以通过第一客户端展示出目标服务场所中多个可选的餐厅信息，以及每个餐厅下多种可选的餐品信息，另外，在优选的方式下，还可以提供具体餐厅对应支持的用餐时段信息，消费模式信息，等等。用户可以通过该第一客户端选择具体的餐厅、餐品、时段、消费模式等信息，并提交对应的用餐服务请求。例如，如图4-1所示，在选择了某个餐厅后，可以通过“下午茶”选项进入对应时段的的详情页面，从中选择具体的点餐方式，可以进行零点，或者选择套餐，等等。

在这种方式下，当其具体请求被受理后，还可以通过第一客户端对餐品的加工制作进度信息通过第一客户端进行展示。例如，如图4-2所示，在用户通过第一客户端完成点餐后，在查看具体订单中的餐品时，可以展示出“已下单”等状态信息。后续随着具体的餐品进入的加工制作流程，还可以提供更多的关于加工制作进度的信息，例如，切配中、制作中、制作完成、已上桌，等等。这样，消费者用户可以直接通过该第一客户端获得餐品的加工制作进度信息，而不需要向具体的服务员等进行询问。

另一种提起用餐服务请求的方式，可以是通过餐厅内的服务员等员工用户的第二客户端进行发起。在消费者用户自己未安装第一客户端，或者，在使用第一客户端进行点餐或者预订时出现问题等情况下，消费者用户可以通过电话等方式联系具体的员工用户，此时，员工用户可以通过其第二客户端来录入具体所需的用餐服务信息，并将具体的用餐服务请求提交到服务端。例如，具体用于进行信息录入的界面可以如图5所示，可以对具体的套餐名称、餐品信息、用餐时间、人数等进行录入。另外，对于预订的情况，还可以提供用于选择桌位的入口，对具体餐厅内的桌位进行预订，等等。

服务端对第二客户端提交的服务请求进行处理后，可以将具体的请求处理结果通过H5页面等形式返回给第二客户端，第二客户端则可以通过短消息等方式，将H5页面的网址等信息提供给具体的需求方消费者用户。这样，消费者用户即可通过其他终端设备浏览到具体的页面内容。其中，如果其终端设备中安装了第一客户端，则在其点击具体的H5页面的网址时，可以自动跳转至该第一客户端中进行展示。如果未安装第一客户端，则可以通过终端设备中的浏览器等应用对H5页面进行展示。通过这种页面的方式，让消费者用户获知具体的点餐或者预订结果等信息。

其中，无论是通过第一客户端还是第二客户端提交具体的用餐服务请求，都可以包括预约订餐请求。在这种预约订餐的模式下，除了可以对具体的餐厅、用餐时段、点餐方式(零点、套餐、自定义等)等进行指定外，还可以对具体的桌位进行选择。

具体实现时，为了便于实现对桌位的选择，所述餐厅对象还可以关联有桌位信息属性，具体的桌位属性可以包括桌位的位置、状态等。在接收到针对目标餐厅的预约请求时，可以根据所述目标餐厅在对应时段的已预订情况，提供可选的桌位信息；例如，可以展示出具体桌位的布局信息界面，并将由于已经被其他用户预订而处于“锁定”状态的桌位显示为不可选。用户可以对可选的桌位进行选择，在目标桌位被预订后，可以将具体的目标桌位置为锁定状态。

其中，具体的桌位属性包括主桌以及副桌；对于团餐或者会议用餐等情况，用餐人数通常会比较多，此时，可能需要预订多个桌位。为了便于进行信息管理，在接收到对多个桌位的预约请求后，可以将首个被选择的桌位确定为主桌，并建立主桌与副桌之间的关联关系，并在主桌被锁定后，将关联的副桌置为锁定状态；在根据具体的请求生成预约订单生成后，可以将所述预约订单与所述主桌建立关联关系；在用餐结束后，可以将主桌以及关联的副桌进行解锁。

其中，所述预约请求中的目标餐品信息可以有多种，例如，可以包括从所述目标餐厅目标用餐时段提供的菜单信息中通过零点的方式选择的餐品信息。或者，也可以包括：所述目标餐厅目标用餐时段提供的套餐信息；所述套餐信息包括特定人数对应的套餐，或者，针对多人参加会议的场景提供的套餐。另外，所述预约请求中的目标餐品信息包括：自定义的餐品，等等。

S203：根据餐品对象与厨房对象之间的对应关系，确定可为所述目标餐品提供加工制作服务的目标厨房，并生成对应的加工制作任务，发送到所述目标厨房关联的客户端。

在接收到具体的用餐服务请求，并确定出目标餐厅以及目标餐品信息后，则可以生成具体的加工制作任务。如前文所述，具体实现时，可以以单个餐品为单位进行加工制作任务的生成，每个餐品对应一个加工制作任务。这样，由于不同的餐品可能需要由不同的厨房来进行加工制作，因此，便于将不同的任务分配到不同的厨房来完成。其中，关于具体的目标餐品，如果具体的点餐方式是零点，则可以直接从具体的请求中确定具体的目标餐品的标识等信息。如果具体的点餐方式是套餐，则可以根据预先保存的套餐关联的餐品列表信息，确定出具体的餐品。如果点餐方式是自定义餐品，则可以根据请求中携带的自定义信息，包括所选择的配料等等，确定出餐品的信息，并在生成具体的加工制作任务时，可以将自定义信息备注在任务工单信息中。

其中，具体实现时，由于消费模式可以包括即时点餐以及预约订餐等多种，因此，具体生成加工制作任务的时机也可以是不同的。具体的，如果用餐服务请求中的目标消费模式是即时点餐模式，则可以在收到所述即时点餐的请求后，立即生成所述加工制作任务，并向目标厨房进行发送。

如果所述目标消费模式包括是预约订餐模式；此时，所述餐饮服务请求可以包括：针对选定的目标餐厅、目标用餐时段、对目标餐品进行预约订餐的请求；此时，在接收到所述预约订餐的请求后，可以根据所述目标用餐时段，生成所述加工制作任务。

其中，具体的预约订餐的请求可以包括：通过消费者用户关联的第一客户端提交的预约请求；此时，服务端还可以生成预约订单，并返回给所述第一客户端；在所述加工制作任务生成后，将所述预约订单与对应的任务工单建立关联关系；然后，可以根据所述目标厨房关联的客户端针对所述任务工单反馈的加工制作进度信息，向所述预约订单对应的第一客户端提供所述加工制作进度信息。

另外，所述预约的请求也可以包括：通过所述目标服务场所中的员工用户关联的第二客户端提交的预约请求；此时，可以根据所述预约请求生成预约结果展示界面，并将界面信息返回给所述第二客户端，以便所述第二客户端将所述界面信息提供给消费者用户关联的终端设备。

在根据具体的用餐服务请求生成加工制作任务后，发送到厨房关联的第三客户端。之后，可以在所述第三客户端所在的终端设备或关联的其他大屏幕设备中展示出具体的任务详情信息。另外，具体实现时，由于多个不同餐厅的加工制作任务都可能到达同一个厨房，因此，将具体在展示任务信息时，还可以以餐厅为单位分别展示具体的任务列表，等等。例如，具体可以如图6所示，其中可以包括中餐厅、西餐厅、大堂吧、饼屋、客房送餐等多个选项卡，可以通过切换选项卡的方式分别对不同餐厅对应的任务进行查看。

另外，在具体实现时，还可以为具体桌位配备的终端设备提供第四客户端，具体桌位对应的已下单列表等信息可以通过该第四客户端进行展示，另外还可以提供具体餐品的加工制作进度信息。例如，如图7所示，其示出了关于“B17桌”的已下单菜品信息，可以展示出“已上桌”等状态信息。另外，还可以展示出结算状态信息，例如，“已结账”、“未结账”，等等。

总之，通过本申请实施例，能够实现对酒店等服务场所中复杂场景下，多个餐厅、多个餐品、多个厨房等的数字化表达，并且可以保存彼此之间的多对多的关系。这样，就可以实现对具体下单、加工制作、上桌等全流程的数字化实现。用户可以通过线上操作的方式，实现对用餐服务请求的提交，服务端则可以根据接收到的请求，生成具体的加工制作任务，并根据餐品与厨房之间的对应关系，分配到具体的厨房进行加工制作，等等。通过这种数字化的处理流程，可以提高效率，提升服务场所的服务效能，降低成本，同时提升用户体验。

实施例二

该实施例二是从为消费者用户提供的第一客户端的角度，提供了一种餐饮服务信息处理方法，具体的，参见图8，该方法具体可以包括：

S801：第一客户端提供同一目标服务场所中可选的多个餐厅对象、多个餐品对象信息；

S802：根据被选中的目标餐厅以及目标餐品对象，生成餐饮服务请求；

S803：将所述餐饮服务请求提交到服务端，以便所述服务端根据餐品对象与厨房对象之间的对应关系，确定可为所述目标餐品提供加工制作服务的目标厨房，并向所述目标厨房发送加工制作任务信息。

具体实现时，第一客户端中还可以提供所述目标餐厅对应的可支持用餐时段信息，以便对具体的餐厅的具体用餐时段信息进行选择。另外，还可以提供所述目标餐厅对应的可选消费模式信息；可以根据被选择的目标消费模式信息，提交所述餐饮服务请求。

其中，所述目标消费模式包括：即时点餐模式；此时，还可以接收服务端提供的餐品加工进度信息并展示。

或者，所述目标消费模式包括：预约订餐模式；此时，可以针对选定的目标餐厅、目标用餐时段、对目标餐品生成的预约订餐请求。

实施例三

该实施例三是从提供给目标服务场所内员工用户使用的第二客户端的角度，提供了一种餐饮服务信息处理方法，具体的，参见图9，该方法具体可以包括：

S901：第二客户端提供用于针对目标服务场所进行预约订餐信息录入的操作界面；其中，所述目标服务场所中包括多个餐厅对象、多个餐品对象以及多个厨房对象；

S902：通过所述操作界面接收录入的预约订餐信息，并提交到服务端；

S903：接收所述服务端返回的预约结果展示界面，并将界面信息提供给提出预约订餐服务需求的消费者用户关联的终端设备。

具体实现时，可以将所述界面的链接信息通过短消息方式发送到所述消费者用户关联的终端设备。这样，消费者用户可以通过点击终端设备中的链接的方式查看具体的界面内容，获得具体的预约结果信息。

实施例四

该实施例四是从提供给厨房关联终端设备的第三客户端的角度，提供了一种餐饮服务信息处理方法，参见图10，该方法具体可以包括：

S1001：第三客户端接收加工制作任务；其中，所述第三客户端为目标服务场所中目标厨房关联的客户端；所述目标服务场所中包括多个餐厅对象、多个餐品对象以及多个厨房对象；所述加工制作任务是根据其中一目标餐厅以及目标餐品对应的用餐服务请求生成的；

S1002：对所述加工制作任务关联的目标餐厅以及目标餐品信息进行展示。

具体实现时，还可以将所述同一目标服务场所中多个餐厅对应的加工制作任务信息进行分组展示进行展示。

关于该实施例二至实施例四中的未详述部分，可参见前述实施例一中的记载，这里不再赘述。

与实施例一相对应，本申请实施例还提供了一种餐饮服务信息处理装置，参见图11，该装置可以包括：

信息获得单元1101，用于获得同一目标服务场所中，多个餐厅对象、多个餐品对象、多个厨房对象的属性信息，以及对象之间的对应关系信息；

信息确定单元1102，用于接收到餐饮服务请求后，确定所述餐饮服务请求中对应的目标餐厅以及目标餐品信息；

任务处理单元1103，用于根据餐品对象与厨房对象之间的对应关系，确定可为所述目标餐品提供加工制作服务的目标厨房，并生成对应的加工制作任务，发送到所述目标厨房关联的客户端。

其中，所述任务处理单元具体可以用于：

以餐品为单位生成对应的加工制作任务，如果同一餐饮服务请求中的多个目标餐品对应不同的目标厨房，则分别将生成的加工制作任务发送至不同的目标厨房关联的客户端。

其中，所述餐厅对象关联有消费模式属性；

所述餐饮服务请求中还包括目标消费模式信息；

所述任务处理单元具体用于：根据所述目标消费模式生成所述加工制作任务。

其中，所述目标消费模式包括即时点餐模式；

所述餐饮服务请求包括：通过消费者用户关联的第一客户端针对选定的目标餐厅的目标餐品进行即时点餐的请求；

所述任务处理单元可以用于：收到所述即时点餐的请求后，即生成所述加工制作任务。

另外，该装置还可以包括：

进度信息接收单元，用于接收所述目标厨房关联的客户端提供的餐品制作进度信息；

进度信息提供单元，用于将所述制作进度信息提供给所述第一客户端。

另外，所述目标消费模式包括：预约订餐模式；

所述餐厅对象还关联有支持的用餐时段属性；

所述餐饮服务请求包括：针对选定的目标餐厅、目标用餐时段、对目标餐品进行预约订餐的请求；

此时，所述任务处理单元可以用于：

接收到所述预约订餐的请求后，根据所述目标用餐时段，生成所述加工制作任务。

其中，所述预约订餐的请求包括：通过消费者用户关联的第一客户端提交的预约请求；

所述装置还可以包括：

预约订单生成单元，用于生成预约订单，并返回给所述第一客户端；

关联关系建立单元，用于在所述加工制作任务生成后，将所述预约订单与对应的任务工单建立关联关系；

进度信息提供单元，用于根据所述目标厨房关联的客户端针对所述任务工单反馈的加工制作进度信息，向所述预约订单对应的第一客户端提供所述加工制作进度信息。

其中，所述预约的请求包括：通过所述目标服务场所中的员工用户关联的第二客户端提交的预约请求；

所述装置还包括：

界面信息返回单元，用于根据所述预约请求生成预约结果展示界面，并将界面信息返回给所述第二客户端，以便所述第二客户端将所述界面信息提供给消费者用户关联的终端设备。

另外，所述餐厅对象还可以关联有桌位信息属性；

所述装置还可以包括：

桌位信息提供单元，用于在接收到针对目标餐厅的预约请求时，根据所述目标餐厅在对应时段的已预订情况，提供可选的桌位信息；

第一状态处理单元，用于在目标桌位被预订后，将该目标桌位置为锁定状态。

其中，所述桌位属性包括主桌以及副桌；

所述装置还包括：

第二状态处理单元，用于在接收到对多个桌位的预约请求后，将首个被选择的桌位确定为主桌，并建立主桌与副桌之间的关联关系，并在主桌被锁定后，将关联的副桌置为锁定状态；

关联关系建立单元，用于在预约订单生成后，将所述预约订单与所述主桌建立关联关系；

第三状态处理单元，用于在用餐结束后，将主桌以及关联的副桌进行解锁。

其中，所述预约请求中的目标餐品信息包括：从所述目标餐厅目标用餐时段提供的菜单信息中选择的餐品信息。

所述预约请求中的目标餐品信息包括：所述目标餐厅目标用餐时段提供的套餐信息；所述套餐信息包括特定人数对应的套餐，或者，针对多人参加会议的场景提供的套餐。

所述预约请求中的目标餐品信息包括：自定义的餐品。

与实施例二相对应，本申请实施例还提供了一种餐饮服务信息处理装置，参见图12，该装置可以包括：

信息提供单元1201，用于提供同一目标服务场所中可选的多个餐厅对象、多个餐品对象信息；

请求生成单元1202，用于根据被选中的目标餐厅以及目标餐品对象，生成餐饮服务请求；

请求提交单元1203，用于将所述餐饮服务请求提交到服务端，以便所述服务端根据餐品对象与厨房对象之间的对应关系，确定可为所述目标餐品提供加工制作服务的目标厨房，并向所述目标厨房发送加工制作任务信息。

具体实现时，该装置还可以包括：

时段信息提供单元，用于提供所述目标餐厅对应的可支持用餐时段信息。

消费模式信息提供单元，用于提供所述目标餐厅对应的可选消费模式信息；

请求提交单元，用于根据被选择的目标消费模式信息，提交所述餐饮服务请求。

其中，所述目标消费模式包括：即时点餐模式；

所述装置还包括：

进度信息提供单元，用于接收服务端提供的餐品加工进度信息并展示。

所述目标消费模式包括：预约订餐模式；

所述请求生成单元具体用于：

针对选定的目标餐厅、目标用餐时段、对目标餐品生成的预约订餐请求。

与实施例三相对应，本申请实施例还提供了一种餐饮服务信息处理装置，参见图13，该装置可以包括：

界面提供单元1301，用于提供用于针对目标服务场所进行预约订餐信息录入的操作界面；其中，所述目标服务场所中包括多个餐厅对象、多个餐品对象以及多个厨房对象；

订餐信息接收单元1302，用于通过所述操作界面接收录入的预约订餐信息，并提交到服务端；

结果展示单元1303，用于接收所述服务端返回的预约结果展示界面，并将界面信息提供给提出预约订餐服务需求的消费者用户关联的终端设备。

其中，结果展示单元具体可以用于：

将所述界面的链接信息通过短消息方式发送到所述消费者用户关联的终端设备。

与实施例四相对应，本申请实施例还提供了一种餐饮服务信息处理装置，参见图14，该装置可以包括：

任务接收单元1401，用于接收加工制作任务；其中，所述第三客户端为目标服务场所中目标厨房关联的客户端；所述目标服务场所中包括多个餐厅对象、多个餐品对象以及多个厨房对象；所述加工制作任务是根据其中一目标餐厅以及目标餐品对应的用餐服务请求生成的；

展示单元1402，用于对所述加工制作任务关联的目标餐厅以及目标餐品信息进行展示。

具体实现时，该装置还可以包括：

分组展示单元，用于将所述同一目标服务场所中多个餐厅对应的加工制作任务信息进行分组展示进行展示。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的餐饮服务信息处理方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (26)

1.一种餐饮服务信息处理方法，其特征在于，包括：

服务端获得同一目标服务场所中，多个餐厅对象、多个餐品对象、多个厨房对象的属性信息，以及对象之间的对应关系信息；

接收到餐饮服务请求后，确定所述餐饮服务请求中对应的目标餐厅以及目标餐品信息；

根据餐品对象与厨房对象之间的对应关系，确定可为所述目标餐品提供加工制作服务的目标厨房，并生成对应的加工制作任务，发送到所述目标厨房关联的客户端。

2.根据权利要求1所述的方法，其特征在于，

所述生成对应的加工制作任务，包括：

以餐品为单位生成对应的加工制作任务，如果同一餐饮服务请求中的多个目标餐品对应不同的目标厨房，则分别将生成的加工制作任务发送至不同的目标厨房关联的客户端。

3.根据权利要求1所述的方法，其特征在于，

所述餐厅对象关联有消费模式属性；

所述餐饮服务请求中还包括目标消费模式信息；

所述生成对应的加工制作任务，包括：

根据所述目标消费模式生成所述加工制作任务。

4.根据权利要求3所述的方法，其特征在于，

所述目标消费模式包括即时点餐模式；

所述餐饮服务请求包括：通过消费者用户关联的第一客户端针对选定的目标餐厅的目标餐品进行即时点餐的请求；

所述根据所述目标消费模式生成所述加工制作任务，包括：

收到所述即时点餐的请求后，即生成所述加工制作任务。

5.根据权利要求4所述的方法，其特征在于，还包括：

接收所述目标厨房关联的客户端提供的餐品制作进度信息；

将所述制作进度信息提供给所述第一客户端。

6.根据权利要求3所述的方法，其特征在于，

所述目标消费模式包括：预约订餐模式；

所述餐厅对象还关联有支持的用餐时段属性；

所述餐饮服务请求包括：针对选定的目标餐厅、目标用餐时段、对目标餐品进行预约订餐的请求；

所述根据所述目标消费模式生成所述加工制作任务，包括：

接收到所述预约订餐的请求后，根据所述目标用餐时段，生成所述加工制作任务。

7.根据权利要求6所述的方法，其特征在于，

所述预约订餐的请求包括：通过消费者用户关联的第一客户端提交的预约请求；

所述方法还包括：

生成预约订单，并返回给所述第一客户端；

在所述加工制作任务生成后，将所述预约订单与对应的任务工单建立关联关系；

根据所述目标厨房关联的客户端针对所述任务工单反馈的加工制作进度信息，向所述预约订单对应的第一客户端提供所述加工制作进度信息。

8.根据权利要求6所述的方法，其特征在于，

所述预约的请求包括：通过所述目标服务场所中的员工用户关联的第二客户端提交的预约请求；

所述方法还包括：

根据所述预约请求生成预约结果展示界面，并将界面信息返回给所述第二客户端，以便所述第二客户端将所述界面信息提供给消费者用户关联的终端设备。

9.根据权利要求6所述的方法，其特征在于，

所述餐厅对象还关联有桌位信息属性；

所述方法还包括：

在接收到针对目标餐厅的预约请求时，根据所述目标餐厅在对应时段的已预订情况，提供可选的桌位信息；

在目标桌位被预订后，将该目标桌位置为锁定状态。

10.根据权利要求9所述的方法，其特征在于，

所述桌位属性包括主桌以及副桌；

所述方法还包括：

在接收到对多个桌位的预约请求后，将首个被选择的桌位确定为主桌，并建立主桌与副桌之间的关联关系，并在主桌被锁定后，将关联的副桌置为锁定状态；

在预约订单生成后，将所述预约订单与所述主桌建立关联关系；

在用餐结束后，将主桌以及关联的副桌进行解锁。

11.根据权利要求6所述的方法，其特征在于，

所述预约请求中的目标餐品信息包括：从所述目标餐厅目标用餐时段提供的菜单信息中选择的餐品信息。

12.根据权利要求6所述的方法，其特征在于，

所述预约请求中的目标餐品信息包括：所述目标餐厅目标用餐时段提供的套餐信息；所述套餐信息包括特定人数对应的套餐，或者，针对多人参加会议的场景提供的套餐。

13.根据权利要求6所述的方法，其特征在于，

所述预约请求中的目标餐品信息包括：自定义的餐品。

14.一种餐饮服务信息处理方法，其特征在于，包括：

第一客户端提供同一目标服务场所中可选的多个餐厅对象、多个餐品对象信息；

根据被选中的目标餐厅以及目标餐品对象，生成餐饮服务请求；

将所述餐饮服务请求提交到服务端，以便所述服务端根据餐品对象与厨房对象之间的对应关系，确定可为所述目标餐品提供加工制作服务的目标厨房，并向所述目标厨房发送加工制作任务信息。

15.根据权利要求14所述的方法，其特征在于，还包括：

提供所述目标餐厅对应的可支持用餐时段信息。

16.根据权利要求14所述的方法，其特征在于，还包括：

提供所述目标餐厅对应的可选消费模式信息；

根据被选择的目标消费模式信息，提交所述餐饮服务请求。

17.根据权利要求16所述的方法，其特征在于，

所述目标消费模式包括：即时点餐模式；

所述方法还包括：

接收服务端提供的餐品加工进度信息并展示。

18.根据权利要求16所述的方法，其特征在于，

所述目标消费模式包括：预约订餐模式；

所述生成餐饮服务请求，包括：

针对选定的目标餐厅、目标用餐时段、对目标餐品生成的预约订餐请求。

19.一种餐饮服务信息处理方法，其特征在于，包括：

第二客户端提供用于针对目标服务场所进行预约订餐信息录入的操作界面；其中，所述目标服务场所中包括多个餐厅对象、多个餐品对象以及多个厨房对象；

通过所述操作界面接收录入的预约订餐信息，并提交到服务端；

接收所述服务端返回的预约结果展示界面，并将界面信息提供给提出预约订餐服务需求的消费者用户关联的终端设备。

20.根据权利要求19所述的方法，其特征在于，

所述将将界面信息提供给提出预约订餐服务需求的消费者用户关联的终端设备，包括：

将所述界面的链接信息通过短消息方式发送到所述消费者用户关联的终端设备。

21.一种餐饮服务信息处理方法，其特征在于，包括：

第三客户端接收加工制作任务；其中，所述第三客户端为目标服务场所中目标厨房关联的客户端；所述目标服务场所中包括多个餐厅对象、多个餐品对象以及多个厨房对象；所述加工制作任务是根据其中一目标餐厅以及目标餐品对应的用餐服务请求生成的；

对所述加工制作任务关联的目标餐厅以及目标餐品信息进行展示。

22.根据权利要求21所述的方法，其特征在于，还包括：

将所述同一目标服务场所中多个餐厅对应的加工制作任务信息进行分组展示进行展示。

23.一种餐饮服务信息处理装置，其特征在于，包括：

信息获得单元，用于获得同一目标服务场所中，多个餐厅对象、多个餐品对象、多个厨房对象的属性信息，以及对象之间的对应关系信息；

信息确定单元，用于接收到餐饮服务请求后，确定所述餐饮服务请求中对应的目标餐厅以及目标餐品信息；

任务处理单元，用于根据餐品对象与厨房对象之间的对应关系，确定可为所述目标餐品提供加工制作服务的目标厨房，并生成对应的加工制作任务，发送到所述目标厨房关联的客户端。

24.一种餐饮服务信息处理装置，其特征在于，包括：

信息提供单元，用于提供同一目标服务场所中可选的多个餐厅对象、多个餐品对象信息；

请求生成单元，用于根据被选中的目标餐厅以及目标餐品对象，生成餐饮服务请求；

请求提交单元，用于将所述餐饮服务请求提交到服务端，以便所述服务端根据餐品对象与厨房对象之间的对应关系，确定可为所述目标餐品提供加工制作服务的目标厨房，并向所述目标厨房发送加工制作任务信息。

25.一种餐饮服务信息处理装置，其特征在于，包括：

界面提供单元，用于提供用于针对目标服务场所进行预约订餐信息录入的操作界面；其中，所述目标服务场所中包括多个餐厅对象、多个餐品对象以及多个厨房对象；

订餐信息接收单元，用于通过所述操作界面接收录入的预约订餐信息，并提交到服务端；

结果展示单元，用于接收所述服务端返回的预约结果展示界面，并将界面信息提供给提出预约订餐服务需求的消费者用户关联的终端设备。

26.一种餐饮服务信息处理装置，其特征在于，包括：

任务接收单元，用于接收加工制作任务；其中，所述第三客户端为目标服务场所中目标厨房关联的客户端；所述目标服务场所中包括多个餐厅对象、多个餐品对象以及多个厨房对象；所述加工制作任务是根据其中一目标餐厅以及目标餐品对应的用餐服务请求生成的；

展示单元，用于对所述加工制作任务关联的目标餐厅以及目标餐品信息进行展示。

Images