CN107590574A - 订单数据信息处理方法及装置 - Google Patents

Abstract

本申请实施例公开了订单数据信息处理方法及装置，所述方法包括：服务器记录业务订单的相关信息，所述相关信息包括业务订单关联的第一用户信息；在所述业务订单对应的事件完成前，接收客户端提交的提前进行订单数据处理的请求；确定请求对应的业务订单，并对所述客户端关联的第二用户进行信用权限验证；如果通过验证，则向对应的第一用户数据处理系统发送提前进行订单数据处理的第一通知消息。通过本申请实施例，能够在订单数据处理环节提高效率，避免用户的长时间等待。

Description

订单数据信息处理方法及装置

技术领域

本申请涉及订单数据信息处理技术领域，特别是涉及订单数据信息处理方法及装置。

背景技术

发票是指单位或个人在购销商品、提供或接受服务以及从事其他经营活动中，所开具和收取的业务凭证，是会计核算的原始依据，也是审计机关、税务机关执法检查的重要依据。

在酒店等行业内，对于互联网的订单，传统的开发票的方式是，对于预付订单(也即，在线下单时已经完成了付款)，由商家开具并寄送发票给客人，而非预付订单(到店面付或者其他方式付款)通常是客人离店时，在前台告知开票需求(金额和抬头等)，前台工作人员开具发票后交给客人。

但是，在客人退房时等待前台开发票的情况下，如果前台人手不足、排队离店并开票的人多，那么将非常耗费客人时间，甚至有可能耽误客人赶飞机赶火车等等。尤其是在酒店行业内，由于酒店的规定通常是，对于不再续住的客人，需要在当天中午12点或者14点之前办理离店，否则酒店可能会多收取一定的费用，等等。因此，客人通常会集中在早上离店，导致前台人员早上8点后就非常忙碌。另外，前台开具发票的过程中，通常需要先打印水单，客人在前台确认水单无误后，前台再打印发票，反复沟通及等待，耗时长。若离店且开票的客人多，排在后面的客人的等待时间将很长，有可能耽误客人后续行程。

现有技术中，基于互联网技术开发的一些应用、电子商务平台等，多数是针对酒店等业务的下单、付款等环节进行干预，以提高相应的处理效率，但是，对于开具发票等订单数据处理环节，现有技术中尚未有相应的解决方案来解决前述问题。

发明内容

本申请提供了订单数据信息处理方法及装置，能够在开具业务凭证环节提高效率，避免用户的长时间等待。

本申请提供了如下方案：

一种订单数据信息处理方法，包括：

服务器记录业务订单的相关信息，所述相关信息包括业务订单关联的第一用户信息；

在所述业务订单对应的事件完成前，接收客户端提交的提前进行订单数据处理的请求；

确定请求对应的业务订单，并对所述客户端关联的第二用户进行信用权限验证；

如果通过验证，则向对应的第一用户数据处理系统发送提前进行订单数据处理的第一通知消息。

一种订单数据信息处理方法，包括：

第一用户数据处理系统将业务订单的状态信息提交到服务器，以便服务器根据业务订单的状态向关联的第二用户的客户端提供用于发起提前进行订单数据处理请求的操作选项；

接收服务器发送的第一通知消息，其中，所述第一通知消息由所述服务器在所述业务订单对应的事件完成前接收到客户端提交的提前进行订单数据处理的请求，并对关联的第二用户进行信用权限验证通过后发出；

根据所述第一通知消息提供提示信息，所述提示信息用于提示所述第一用户进行相应的订单数据处理。

一种订单数据信息处理方法，包括：

客户端提供用于针对业务订单发起提前进行订单数据处理请求的第一操作选项；

在所述业务订单对应的事件完成前，通过所述第一操作选项接收针对目标业务订单的提前进行订单数据处理请求；

将所述请求提交到服务器，以便所述服务器对客户端关联的第二用户进行信用权限验证，并在验证通过后，根据所述目标业务订单标识确定关联的第一用户标识，向对应的第一用户数据处理系统发送提前进行订单数据处理的第一通知消息。

一种订单数据信息处理装置，应用于服务器，包括：

订单信息记录单元，用于记录业务订单的相关信息，所述相关信息包括业务订单关联的第一用户信息；

请求接收单元，用于在所述业务订单对应的事件完成前，接收客户端提交的提前进行订单数据处理的请求；

验证单元，用于确定请求对应的业务订单，并对所述客户端关联的第二用户进行信用权限验证；

通知单元，用于如果通过验证，则向对应的第一用户数据处理系统发送提前进行订单数据处理的第一通知消息。

一种订单数据信息处理装置，应用于第一用户数据处理系统，包括：

订单状态提交单元，用于将业务订单的状态信息提交到服务器，以便服务器根据业务订单的状态向关联的第二用户的客户端提供用于发起提前进行订单数据处理请求的操作选项；

通知接收单元，用于接收服务器发送的第一通知消息，其中，所述第一通知消息由所述服务器在所述业务订单对应的事件完成前接收到客户端提交的提前进行订单数据处理的请求，并对关联的第二用户进行信用权限验证通过后发出；

提示信息提供单元，用于根据所述第一通知消息提供提示信息，所述提示信息用于提示所述第一用户进行相应的订单数据处理。

一种订单数据信息处理装置，应用于客户端，包括：

操作选项提供单元，用于提供用于针对业务订单发起提前进行订单数据处理请求的第一操作选项；

请求接收单元，用于在所述业务订单对应的事件完成前，通过所述第一操作选项接收针对目标业务订单的提前进行订单数据处理请求；

请求提交单元，用于将所述请求提交到服务器，以便所述服务器对客户端关联的第二用户进行信用权限验证，并在验证通过后，根据所述目标业务订单标识确定关联的第一用户标识，向对应的第一用户数据处理系统发送提前进行订单数据处理的第一通知消息。

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

通过本申请实施例，由于能够为第二用户提供用于为指定业务订单提前进行订单数据处理的操作选项，因此，服务器可以在第二用户结束消费(例如，离店等)之前提前接收第二用户客户端的订单数据处理请求，并在对第二用户进行信用权限验证通过后，向第一用户数据处理系统发送通知消息，这样，第一用户数据处理系统就可以提前执行订单数据处理的操作。通过这种方式，可以避免集中在一个时间段到前台进行订单数据处理，可以节省第二用户时间。对于第一用户而言，由于可以将订单数据处理的请求分散到更长的时间段进行，因此，也有利于提高服务质量。对于提供该服务的平台而言，也可以提高服务内容以及信息内容的丰富性。

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

附图说明

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

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

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

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

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

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

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

具体实施方式

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

在本申请实施例中，第一用户可以是商家用户或者卖家用户等，并且这种第一用户通常是以提供线下资源的方式，为第二用户提供服务，相应的，第二用户就是通过使用第一用户提供的线下资源获得相应服务的买家用户、消费者用户等。具体的，对于不同类别的第一用户，线下资源的具体种类也有所不同，例如，对于酒店类的第一用户，具体的线下资源可以包括客房、房内的设施等等，对于汽车租赁类的第一用户，具体的线下资源主要是指汽车等。

针对上述应用场景，在本申请人提交的其他专利申请中，提供了以下技术方案：基于现有的移动终端应用(例如，阿里旅行、支付宝等，为便于描述，这里以阿里旅行为例进行介绍)，可以为用户提供“信用消费服务”，例如，“信用住”等。具体实现时，涉及到的交互实体通常包括：平台侧的服务器，平台提供的第二用户客户端，以及第一用户的数据处理系统。其中，所谓的第一用户的数据处理系统可以有多种具体的形式，例如，其中一种方式下，第一用户可以使用第三方的PMS(power production management system，工程生产管理系统)系统，或者还可以是平台为第一用户提供的客户端，等等。其中，对于前一种情况，平台服务器可以预先与第一用户的PMS系统建立合作关系，将服务器端的标准化接口等信息提供给第一用户的PMS系统，同样，第一用户的PMS系统也可以将其接口信息提供给服务器，以此实现平台服务器与第一用户的PMS系统之间的直连互通，使得两者之间可以直接进行数据交互，而无需通过手动工单等方式来完成。

当第二用户具体需要使用信用消费服务(例如，信用住)时，可以首先利用第二用户客户端，在线预订具有“信用消费”属性的第一用户的数据对象(例如，某酒店提供的某房型的房间等)，服务器依据支付宝等信用体系校验用户信用等级，符合信用等级的用户可以享受信用消费模式的预定。另外，服务器还可以将用户的订单实时传递到第一用户的数据处理系统，第一用户前台也可以直接看到订单信息，第二用户到第一用户办理入住时，可以直接进行免押金入住，在第二用户离店时，免查房、免排队，服务器可以直接将实际消费的资金从第二用户的支付宝账户划拨到第一用户的账户。或者，在其中的信用消费模式下，第二用户也可以不必预先在线预订，而是直接到酒店办理入住，此时，第一用户的数据处理系统也可以采集第二用户的身份信息、支付宝账户信息等，将其传递给服务器，服务器对第二用户进行信用评估，如果满足条件，则可以通知酒店为该第二用户办理信用消费，同样，该第二用户也可以免押金入住，离店时免查房、免排队，由服务器办理结账事宜。

总之，在提供信用消费服务的过程中，阿里旅行等服务平台可以与第一用户的数据处理系统相互配合，为第一用户以及第二用户都提供了便利。相应的，本申请实施例就可以在以上技术方案的基础上，利用服务器能够与第一用户数据处理系统直连互通这一特点，进一步提供订单数据信息的处理方法，以便在开具业务凭证等环节上也能够为第一用户以及第二用户提供便利，提高效率，节省用户时间。当然，在实际应用中，能够提供“信用消费服务”功能的应用平台也不限于阿里旅行，例如，还可以为该功能提供专用的服务器，开发专用的第一用户数据处理系统、第二用户客户端，等等。另外，在实现本申请实施例中的订单数据信息处理功能时，也可以不必以实现“信用消费服务”功能为前提，也就是说，可以单独提供订单数据信息处理。其中，所谓的订单数据处理，可以包括多个方面的处理，例如，可以包括背景技术中所述的开具业务凭证，或者还可以是打印账单、打印消费清单等等，总之，传统实现方式中，需要第二用户亲自到前台找工作人员对订单数据执行的各种处理操作，都可以通过本申请实施例提供的方式来实现。

下面对具体的实现方式进行详细介绍。

实施例一

该实施例一首先从服务器的角度提供了一种订单数据信息处理方法，参见图1，该方法可以包括以下步骤：

S101：服务器记录业务订单的相关信息，所述相关信息包括业务订单关联的第一用户信息；

具体实现时，如果是第二用户预先通过客户端预订了“信用消费服务”，则相应的业务订单通常是由服务器生成的，并且，第二用户在进行预订的过程中，已经对第一用户进行了选择，因此，服务器可以直接在该业务订单中可以记录第一用户的信息。其中，由于是采用在线预订的方式，因此，也即意味着第一用户以及第二用户都是当前平台(例如阿里旅行)的注册用户，因此，在保存第一用户以及第二用户的标识信息时，可以通过用户id、用户名、账户信息等进行保存。后续在第二用户进店办理入住等操作时，第一用户数据处理系统(包括PMS系统等)可以向服务器回传已入住的通知消息，服务器可以将业务订单状态修改为已入住。此时，就可以在第二用户客户端的用户界面中提供提前进行“订单数据处理”的操作选项。也就是说，当第二用户开始进店消费后，随时都可以直接通过其客户端发起提前进行订单数据处理的请求。另外，具体实现时，除了提供用于提前进行订单数据处理的操作选项，还可以提供用于查看账单数据的操作选项，也即，第二用户还可以通过客户端实时查看已经消费的金额等信息。

如果第二用户并没有提前在线预订“信用消费服务”，而是在第二用户进店消费时，由第一用户数据处理系统向服务器发起对第二用户的信用校验，并在校验通过，服务器同意为该第二用户进行信用担保的情况下，第一用户数据处理系统为其生成业务订单，则第一用户数据处理系统在生成业务订单后，可以将业务订单信息保存到服务器(例如，阿里旅行的服务器等)，包括订单的状态、关联的第一用户第二用户标识信息等，服务器可以对业务订单的这些相关信息进行保存。

需要说明的是，在上述第二种情况下，关于第二用户，该用户通常是在阿里旅行等平台注册的用户，因此，可以利用该用户在平台中注册的用户id、用户名或者账户名等信息，作为第二用户的标识。而关于第一用户，如果第一用户使用的是提供的客户端，则也可以通过第一用户在平台中注册的用户id、用户名或者账户名等信息进行标识。而如果是使用的第三方PMS系统，则可以通过其他信息对第一用户进行标识，例如，可以是第一用户使用的设备id，或者，在PMS系统中注册的用户id、账户名等等。另外，在这种情况下，由于是在用户开始进店消费时，才生成的业务订单，因此，业务订单生成之后就可以进入“已入住”等状态，并且可以提供用于开具业务凭证、用户查看账单数据等操作的操作选项。

S102：在所述业务订单对应的事件完成前，接收客户端提交的提前进行订单数据处理的请求；

由于在第二用户客户端中提供用于提前进行订单数据处理的操作选项，因此，第二用户可以根据需要发起提前进行订单数据处理的请求，当然，在实际应用中，通常可以是在第二用户即将结束消费时，例如，在离店的前一天晚上或者当天早上等时间，发起提前进行订单数据处理的请求，这样可以避开办理开具凭证等处理的高峰时段，节省时间。

S103：确定请求对应的业务订单，并对所述客户端关联的第二用户进行信用权限验证；

具体实现时，用于提前进行订单数据处理的操作选项通常可以在业务订单详情信息页面、列表页面等处提供，每个业务订单对应着各自的用于提前进行订单数据处理的操作选项，也就是说，操作选项与业务订单之间具有关联关系，因此，在通过某操作选项接收到提前进行订单数据处理的请求时，可以根据这种关联关系确定出对应的业务订单。另外，在提前进行订单数据处理时，可能还需要第二用户提供一些信息，例如，具体的处理请求如果是开具发票等业务凭证的请求，则通常需要第二用户提供业务凭证的抬头(个人或者单位，如果是单位，则可能还需要第二用户提供单位名称等信息)、金额、类型等等。因此，具体实现时，在接收到提前进行订单数据处理的请求时，还可以提供用于输入上述信息的操作选项，根据第二用户输入的信息确定提前进行订单数据处理所需的信息。当然，在实际应用中，还可以对第二用户输入过的提前进行订单数据处理所需的信息进行保存，这样，当第二用户后续再使用该功能时，可以将历史记录的信息提供给第二用户进行确认，当第二用户确认无误后，可以直接确定为提前进行订单数据处理所需的信息。

在确定出请求对应的业务订单后，可以对客户端关联的第二用户进行信用权限验证。也就是说，在本申请实施例中，可以仅对一些信用度比较高的用户提供相应的功能。具体实现时，可以是按照预先设定的业务条件，对当前用户进行信用验证。其中，具体的验证方式可以有多种，并且，具体的业务条件可以根据实际的业务需求来确定。例如，可以是对用户的信用等级、信用额度的大小、未结账交易订单的数量等进行限制。这样，服务器具体在进行判断时，针对业务条件中涉及到的各项参数，可以确定出当前用户对应的参数值，并与条件中设定的阈值等进行比对，进而确定用户是否符合业务条件。例如，在阿里旅行平台下，可以获取到用户的支付宝账户关联的“芝麻信用”信息，还可以获取“蚂蚁花呗”为该第二用户提供的额度信息，另外，还可以确定出该支付宝账户关联的未结账订单数量，等等，以上因素都可以用于确定当前用户是否满足业务条件。如果满足条件，即可针对其发起的数据处理请求进行提前处理。当然，在实际应用中，如果生成业务订单的过程中已经对第二用户进行过信用验证，对应的业务订单属于信用消费订单的情况下，则该步骤也可以直接通过判断业务订单的类型，来对当前第二用户进行信用权限验证，如果当前业务订单属于信用消费订单，则确定当前第二用户通过验证，否则，再按照前述方式，提取第二用户的信用相关的数据，然后与预置的业务条件进行比对，等等。

另外，在实际应用中，由于在第二用户预订酒店等数据对象的过程中，通过会确定消费开始日期以及结束日期，例如，在预订某酒店时，通常会指定入住日期以及离店日期，这样也便于第一用户根据预订情况进行线下资源的调配。对于这种情况，还可以对允许第二用户发起提前进行业务订单数据处理的时间进行限制，以避免由于第二用户对该功能的滥用，给第一用户带来经济或者资源等方面造成的损失。具体的，可以预先制定规则，例如，离店前一天中午12点到离店当前8点前，可以发起提前进行业务订单数据处理的请求，等等。这样，在接收到具体的提前进行业务订单数据处理的请求时，可以首先确定所述业务订单中记录的消费结束日期，然后，根据所述消费结束日期以及预置的规则，确定可提前进行订单数据处理的时间范围，进而再判断接收到所述请求的时间点是否在所述时间范围内，如果在，则触发执行发送所述第一通知消息的步骤。例如，如果某业务订单中记录的离店日期为6月5日，则如果在6月4日13：00接收到提前进行订单数据处理的请求，则可以按照该请求进行数据处理，而如果是在6月4日12：00之前接收到该请求，则可以提示第二用户，尚未到达可以办理的时间，等等，并且，还可以对允许开始的时间进行提示。

另外，还可以根据第二用户信用权限高低的不同，设定不同的提前进行订单数据处理的时间范围。例如，如果第二用户的信用权限越高，则可以越早开始进行订单数据处理，等等。这样，在具体实现时，在接收到具体的提前进行订单数据处理还可以根据第二用户具体的信用权限，确定出允许该第二用户提前发起订单数据处理请求的时间范围，然后再确定当前接收到请求的时间，是否在该时间范围内，如果在，则开始按照该请求对订单数据进行处理。S104：如果通过验证，则向对应的第一用户数据处理系统发送提前进行订单数据处理的第一通知消息。

S104：如果通过验证，则向对应的第一用户数据处理系统发送提前进行订单数据处理的第一通知消息。

在通过对第二用户的权限验证后，就可以向该第一用户数据处理系统发送通知消息，另外，还可以将目标业务订单标识提供给第一用户数据处理系统，在订单数据处理需要第二用户提供一些信息，并且在收到请求时，也确定出这些信息的情况下，还可以将订单数据处理所需的信息传递给第一用户数据处理系统。第一用户数据处理系统在接收到通知消息后，就可以提供提示信息，例如，可以弹框提示，还可以伴随有语音提示等等。前台服务人员就可以根据提示信息，进行订单数据处理的操作，例如，开具业务凭证，打印消费清单，等等。其中，由于第二用户是在离店前发起的请求，因此，实际对订单数据处理的操作也是在离店前就办理，避免第二用户在前台的长时间排队等待，提高用户对平台的使用体验。

如前文所述，在具体实现时，还可以提供查看账单数据的操作选项，这是因为，由于第二用户可能是采用“信用消费”的方式，在消费结束后才会由服务器办理款项划拨操作，因此，第二用户可能会具有了解当前消费情况，进而再确定订单数据处理需要填写的金额等信息的需求。为此，可以为业务订单提供用于查看消费数据的操作选项，在第二用户发起提前进行订单数据处理的请求之前，可以首先根据查看具体的消费数据，然后在填写订单数据处理所需的信息时，可以根据查询的结果填写订单数据处理所需的消费金额等信息。当然，在实际应用中，第二用户还可以在其他时间查询实时的账单数据。

具体实现时，第二用户客户端在接收到查看账单数据的请求时，就可以将该请求转发至服务器，服务器在收到该请求后，可以根据业务订单关联的第一用户标识信息，向第一用户数据处理系统发送查看请求，第一用户数据处理系统就可以将相应的账单数据返回，再由服务器提供给第二用户客户端。

另外，由于订单数据处理通常包括对一些信息的打印等处理，打印结果通常是纸质文件，因此，在确定订单数据处理所需的信息时，还可以确定出打印结果的领取方式信息，具体实现时，可以在提供用于输入订单数据处理所需各项信息时，提供用于输入或者选择打印结果领取方式信息的选项。例如，可以包括送至房间、放在前台、或邮寄等，如果邮寄，则第二用户还可以输入邮寄地址等等。在发送所述第一通知消息时，还将所述打印结果领取方式信息传递给所述第一用户数据处理系统。

需要说明的是，在实际应用中，前台服务人员在接收到第一通知消息后，还可以对各项信息进行审核，例如，包括开票金额与实际消费金额是否一致等，如果审核通过，则直接按照接收到的信息进行订单数据处理即可。而如果审核不通过，则还可以与第二用户进行沟通协商(可以通过电话等方式)，协商通过后再进行处理。

在订单数据处理完成后，第一用户数据处理系统可以向服务器发送第二通知消息，以通知服务器，订单数据处理已完成，进而，服务器就可以根据第二通知消息，向第二用户客户端提供第三通知消息，以通知第二用户，订单数据处理已完成。这样，第二用户可以通过其客户端查看到订单数据的处理情况。

在订单数据处理已完成并打印后，可以根据打印结果的领取方式进行处理，例如，可以将打印结果送至房间、放在前台、或邮寄等。其中，对于邮寄的方式，第一用户数据处理系统还可以将邮寄服务提供方信息(例如，快递公司名称等)以及邮寄凭证标识信息(例如，快递单号等)等提供给服务器，服务器可以将这些信息提供给第二用户客户端。并且，服务器还可以实时对物流详情进行监控，监控到最新的物流详情信息时，还可以同步提供给第二用户客户端，使得第二用户还可以通过客户端查看打印结果的具体邮寄信息。

总之，在本申请实施例中，由于能够为第二用户提供用于为指定业务订单提前进行订单数据处理的操作选项，因此，服务器可以在第二用户结束消费(例如，离店等)之前提前接收第二用户客户端的订单数据处理请求，并在对第二用户进行信用权限验证通过后，向第一用户数据处理系统发送通知消息，这样，第一用户数据处理系统就可以提前执行订单数据处理的操作。通过这种方式，可以避免集中在一个时间段到前台进行订单数据处理，可以节省第二用户时间。对于第一用户而言，由于可以将订单数据处理的请求分散到更长的时间段进行，因此，也有利于提高服务质量。对于提供该服务的平台而言，也可以提高服务内容以及信息内容的丰富性。

实施例二

以上实施例一主要从服务器的角度对本申请实施例的实现方案进行了介绍，在该实施例二中，主要从第一用户数据处理系统的角度进行介绍。如前文所述，该第一用户数据处理系统可以是提供相应功能的平台提供的，或者也可以是第三方的PMS系统。

参见图2，该实施例二提供了一种订单数据信息处理方法，其特征在于，包括：

S201：第一用户数据处理系统将业务订单的状态信息提交到服务器，以便服务器根据业务订单的状态向关联的第二用户的客户端提供用于发起提前进行订单数据处理请求的操作选项；

S202：接收服务器发送的第一通知消息，其中，所述第一通知消息由所述服务器接收到客户端提交的提前进行订单数据处理的请求，并对关联的第二用户进行信用权限验证通过后发出；

S203：根据所述第一通知消息提供提示信息，所述提示信息用于提示所述第一用户进行相应的订单数据处理。

具体实现时，所述第一通知消息中还可以携带有打印结果的领取方式信息，当领取方式为邮寄到指定地址时，还可以将邮寄服务提供方信息以及邮寄凭证标识信息提供给服务器，以便服务器向所述第二用户客户端提供物流详情信息。

在订单数据处理完成后，还可以向服务器提供第二通知消息，以便服务器通知所述第二用户客户端订单数据处理已完成。

实施例三

该实施例三主要从第二用户客户端的角度进行介绍，具体的，参见图3，该实施例三提供了一种订单数据信息处理方法，该方法可以包括以下步骤：

S301：客户端提供用于针对业务订单发起提前进行订单数据处理请求的第一操作选项；

具体实现时，提供该第一操作选项的操作可以是根据服务器的指示进行的，例如，在服务器获知业务订单已经处于“以入住”等开始消费的状态时，再指示第二用户客户端通过该第一操作选项。

S302：通过所述第一操作选项接收到针对目标业务订单的提前进行订单数据处理请求时将所述请求提交到服务器，以便所述服务器对客户端关联的第二用户进行信用权限验证，并在验证通过后，根据所述目标业务订单标识确定关联的第一用户标识，向对应的第一用户数据处理系统发送提前进行订单数据处理的第一通知消息。

之后，还可以接收服务器返回的第三通知消息，所述第三通知消息用于通知第二用户客户端订单数据已处理，由所述服务器在接收到第一用户数据处理系统提交的订单数据已处理的第二通知消息后发出。

另外，在具体实现时，第二用户客户端还可以提供用于发起业务订单账单数据查询请求的第二操作选项，通过所述第二操作选项接收到针对目标业务订单的查询请求时，将所述查询请求提交到服务器，并在所述请求中携带所述目标业务订单标识，以便服务器根据所述目标业务订单标识确定关联的第一用户标识，并向对应的第一用户数据处理系统发送查询请求，接收到第一用户数据处理系统返回的账单数据后，返回给所述第二用户客户端，第二用户客户端再对服务器返回的账单数据进行展示。

以上实施例二以及实施例三均是与实施例一相对应的，因此，相关的具体实现可以参见实施例一中的记载，这里不再赘述。

与实施例一相对应，本申请实施例还提供了一种订单数据信息处理装置，该装置可以应用于服务器，参见图4，该装置具体可以包括：

订单信息记录单元401，用于记录业务订单的相关信息，所述相关信息包括业务订单关联的第一用户信息；

请求接收单元402，用于在所述业务订单对应的事件完成前，接收客户端提交的提前进行订单数据处理的请求；

验证单元403，用于确定请求对应的业务订单，并对所述客户端关联的第二用户进行信用权限验证；

通知单元404，用于如果通过验证，则向对应的第一用户数据处理系统发送提前进行订单数据处理的第一通知消息。

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

操作选项提供单元，用于根据所述业务订单的状态，向客户端提供用于发起提前进行订单数据处理请求的操作选项。

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

查看请求接收单元，用于接收客户端提交的查看账单数据的请求，所述请求中携带有目标业务订单标识；

查询请求发送单元，用于根据所述目标业务订单标识确定关联的第一用户标识，并向对应的第一用户数据处理系统发送查询请求；

账单数据提供单元，用于接收到第一用户数据处理系统返回的账单数据后，提供给所述客户端。

其中，所述业务订单的相关信息还包括：预订的消费结束日期信息，在接收到所述提前进行订单数据处理的请求时，还包括：

结束日期确定单元，用于确定所述业务订单对应的消费结束日期；

时间范围确定单元，用于根据所述消费结束日期以及预置的规则，确定可提前进行订单数据处理的时间范围；

判断单元，用于判断接收到所述请求的时间点是否在所述时间范围内，如果在，则触发执行发送所述第一通知消息的步骤。

具体实现时，根据第二用户信用权限的不同，可以对应不同的所述时间范围。

另外，该装置还包括：

信息确定单元，用于所述接收所述请求时，确定进行订单数据处理所需的信息；

信息传递单元，用于在向第一用户数据处理系统发送所述第一通知消息时，将所述进行订单数据处理所需的信息传递给所述第一用户数据处理系统。

其中，所述订单数据处理请求包括打印订单相关数据的请求。

具体实现时，所述请求中还可以携带有打印结果领取方式信息，在发送所述第一通知消息时，还将所述领取方式信息传递给所述第一用户数据处理系统。

其中，当所述领取方式为邮寄到指定地址时，所述装置还可以包括：

邮寄信息接收单元，用于接收所述第一用户数据处理系统提供的邮寄服务提供方信息以及邮寄凭证标识信息；

邮寄信息提供单元，用于将所述邮寄服务提供方信息以及邮寄凭证标识信息提供给所述客户端。

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

物流详情信息获取单元，用于从所述邮寄服务提供方获取物流详情信息；

物流详情信息提供单元，用于将获取到的物流详情信息提供给所述客户端。

再者，所述装置还可以包括：

第二通知消息接收单元，用于接收第一用户数据处理系统提交的订单数据已处理的第二通知消息；

第三通知消息提供单元，用于向所述第二用户客户端发送第三通知消息，所述第三通知消息用于通知第二用户客户端订单数据已处理。

与实施例二相对应，本申请实施例还提供了一种订单数据信息处理装置，该装置可以应用于第一用户数据处理系统，参见图5，该装置可以包括：

订单状态提交单元501，用于将业务订单的状态信息提交到服务器，以便服务器根据业务订单的状态向关联的第二用户的客户端提供用于发起提前进行订单数据处理请求的操作选项；

通知接收单元502，用于接收服务器发送的第一通知消息，其中，所述第一通知消息由所述服务器在所述业务订单对应的事件完成前接收到客户端提交的提前进行订单数据处理的请求，并对关联的第二用户进行信用权限验证通过后发出；

提示信息提供单元503，用于根据所述第一通知消息提供提示信息，所述提示信息用于提示所述第一用户进行相应的订单数据处理。

与实施例三相对应，本申请实施例还提供了一种订单数据信息处理装置，该装置可以应用于客户端，参见图6，该装置具体可以包括：

操作选项提供单元601，用于提供用于针对业务订单发起提前进行订单数据处理请求的第一操作选项；

请求接收单元602，用于在所述业务订单对应的事件完成前，通过所述第一操作选项接收针对目标业务订单的提前进行订单数据处理请求；

请求提交单元603，用于将所述请求提交到服务器，以便所述服务器对客户端关联的第二用户进行信用权限验证，并在验证通过后，根据所述目标业务订单标识确定关联的第一用户标识，向对应的第一用户数据处理系统发送提前进行订单数据处理的第一通知消息。

通过本申请实施例，由于能够为第二用户提供用于为指定业务订单提前进行订单数据处理的操作选项，因此，服务器可以在第二用户结束消费(例如，离店等)之前提前接收第二用户客户端的订单数据处理请求，并在对第二用户进行信用权限验证通过后，向第一用户数据处理系统发送通知消息，这样，第一用户数据处理系统就可以提前执行订单数据处理的操作。通过这种方式，可以避免集中在一个时间段到前台进行订单数据处理，可以节省第二用户时间。对于第一用户而言，由于可以将订单数据处理的请求分散到更长的时间段进行，因此，也有利于提高服务质量。对于提供该服务的平台而言，也可以提高服务内容以及信息内容的丰富性。

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

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

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

Claims (17)

1.一种订单数据信息处理方法，其特征在于，包括：

服务器记录业务订单的相关信息，所述相关信息包括业务订单关联的第一用户信息；

在所述业务订单对应的事件完成前，接收客户端提交的提前进行订单数据处理的请求；

确定请求对应的业务订单，并对所述客户端关联的第二用户进行信用权限验证；

如果通过验证，则向对应的第一用户数据处理系统发送提前进行订单数据处理的第一通知消息。

2.根据权利要求1所述的方法，其特征在于，在接收客户端提交的提前进行订单数据处理的请求之前，还包括：

根据所述业务订单的状态，向客户端提供用于发起提前进行订单数据处理请求的操作选项。

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

接收客户端提交的查看账单数据的请求，所述请求中携带有目标业务订单标识；

根据所述目标业务订单标识确定关联的第一用户标识，并向对应的第一用户数据处理系统发送查询请求；

接收到第一用户数据处理系统返回的账单数据后，提供给所述客户端。

4.根据权利要求1所述的方法，其特征在于，所述业务订单的相关信息还包括：预订的消费结束日期信息，在接收到所述提前进行订单数据处理的请求时，还包括：

确定所述业务订单对应的消费结束日期；

根据所述消费结束日期以及预置的规则，确定可提前进行订单数据处理的时间范围；

判断接收到所述请求的时间点是否在所述时间范围内，如果在，则触发执行发送所述第一通知消息的步骤。

5.根据权利要求4所述的方法，其特征在于，根据第二用户信用权限的不同，对应不同的所述时间范围。

6.根据权利要求1所述的方法，其特征在于，所述接收所述请求时，还包括：

确定进行订单数据处理所需的信息；

在向第一用户数据处理系统发送所述第一通知消息时，还包括：

将所述进行订单数据处理所需的信息传递给所述第一用户数据处理系统。

7.根据权利要求1所述的方法，其特征在于，所述订单数据处理请求包括打印订单相关数据的请求。

8.根据权利要求7所述的方法，其特征在于，所述请求中还携带有打印结果领取方式信息，在发送所述第一通知消息时，还将所述领取方式信息传递给所述第一用户数据处理系统。

9.根据权利要求7所述的方法，其特征在于，当所述领取方式为邮寄到指定地址时，所述方法还包括：

接收所述第一用户数据处理系统提供的邮寄服务提供方信息以及邮寄凭证标识信息；

将所述邮寄服务提供方信息以及邮寄凭证标识信息提供给所述客户端。

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

从所述邮寄服务提供方获取物流详情信息；

将获取到的物流详情信息提供给所述客户端。

11.根据权利要求1所述的方法，其特征在于，所述方法之后还包括：

接收第一用户数据处理系统提交的订单数据已处理的第二通知消息；

向所述第二用户客户端发送第三通知消息，所述第三通知消息用于通知第二用户客户端订单数据已处理。

12.一种订单数据信息处理方法，其特征在于，包括：

第一用户数据处理系统将业务订单的状态信息提交到服务器，以便服务器根据业务订单的状态向关联的第二用户的客户端提供用于发起提前进行订单数据处理请求的操作选项；

接收服务器发送的第一通知消息，其中，所述第一通知消息由所述服务器在所述业务订单对应的事件完成前接收到客户端提交的提前进行订单数据处理的请求，并对关联的第二用户进行信用权限验证通过后发出；

根据所述第一通知消息提供提示信息，所述提示信息用于提示所述第一用户进行相应的订单数据处理。

13.一种订单数据信息处理方法，其特征在于，包括：

客户端提供用于针对业务订单发起提前进行订单数据处理请求的第一操作选项；

在所述业务订单对应的事件完成前，通过所述第一操作选项接收针对目标业务订单的提前进行订单数据处理请求；

将所述请求提交到服务器，以便所述服务器对客户端关联的第二用户进行信用权限验证，并在验证通过后，根据所述目标业务订单标识确定关联的第一用户标识，向对应的第一用户数据处理系统发送提前进行订单数据处理的第一通知消息。

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

接收服务器返回的第三通知消息，所述第三通知消息用于通知客户端订单数据已处理，由所述服务器在接收到第一用户数据处理系统提交的订单数据已处理的第二通知消息后发出。

15.一种订单数据信息处理装置，其特征在于，应用于服务器，包括：

订单信息记录单元，用于记录业务订单的相关信息，所述相关信息包括业务订单关联的第一用户信息；

请求接收单元，用于在所述业务订单对应的事件完成前，接收客户端提交的提前进行订单数据处理的请求；

验证单元，用于确定请求对应的业务订单，并对所述客户端关联的第二用户进行信用权限验证；

通知单元，用于如果通过验证，则向对应的第一用户数据处理系统发送提前进行订单数据处理的第一通知消息。

16.一种订单数据信息处理装置，其特征在于，应用于第一用户数据处理系统，包括：

订单状态提交单元，用于将业务订单的状态信息提交到服务器，以便服务器根据业务订单的状态向关联的第二用户的客户端提供用于发起提前进行订单数据处理请求的操作选项；

通知接收单元，用于接收服务器发送的第一通知消息，其中，所述第一通知消息由所述服务器在所述业务订单对应的事件完成前接收到客户端提交的提前进行订单数据处理的请求，并对关联的第二用户进行信用权限验证通过后发出；

提示信息提供单元，用于根据所述第一通知消息提供提示信息，所述提示信息用于提示所述第一用户进行相应的订单数据处理。

17.一种订单数据信息处理装置，其特征在于，应用于客户端，包括：

操作选项提供单元，用于提供用于针对业务订单发起提前进行订单数据处理请求的第一操作选项；

请求接收单元，用于在所述业务订单对应的事件完成前，通过所述第一操作选项接收针对目标业务订单的提前进行订单数据处理请求；

请求提交单元，用于将所述请求提交到服务器，以便所述服务器对客户端关联的第二用户进行信用权限验证，并在验证通过后，根据所述目标业务订单标识确定关联的第一用户标识，向对应的第一用户数据处理系统发送提前进行订单数据处理的第一通知消息。