订单处理方法、装置、存储介质及计算机设备与流程

1.本发明涉及互联网领域，尤其是涉及一种订单处理方法、装置、存储介质及计算机设备。


背景技术：

2.随着互联网支付技术的发展，在互联网应用软件上提交订单，购买交通出行，差旅住宿等服务已成为当下的主流趋势。各大互联网厂商纷纷搭建在线商务平台，与各大公司搭建立合作关系，为公司的内部人员购买交通出行，差旅住宿服务提供在线交易平台。与此同时，各公司对其内部人员购买的交通住宿服务有着多样的限制要求，如对购买机票的舱等有着特定的限制，若内部人员购买的服务不满足该公司对于服务的限制要求，则判定该购买订单无效。
3.当前，对于互联网厂商而言，面对有着不同限制要求的公司，在搭建费用控制系统时，需要为有着不同限制要求的公司设置专门的订单有效性控制逻辑，以确保该公司的人员能够购买符合该公司限制要求的服务。进一步的，对于在线交易平台而言，在线交易平台每包含一家合作公司，在线交易平台的费用控制系统就要多包含一套针对该公司的控制逻辑，导致费用控制系统的代码体量过于臃肿，降低了费用控制系统的响应效率。


技术实现要素：

4.有鉴于此，本技术提供了一种订单处理方法、装置、存储介质及计算机设备，主要目的在于解决费用控制系统的代码体量臃肿，费用控制系统的响应效率低的技术问题。
5.根据本发明的第一个方面，提供了一种订单处理方法，该方法包括：
6.接收订单提交请求，其中，所述订单提交请求中携带有用户标识信息、消费场景类型信息以及与所述消费场景类型信息对应的至少一个消费信息；
7.基于所述消费场景类型信息和所述用户标识信息，在数据库中调取预先设置的与所述消费信息对应的消费限定要求；
8.判断所述消费信息是否满足对应的消费限定要求；
9.若所述消费信息满足对应的消费限定要求，则对所述订单提交请求进行处理，得到订单信息。
10.根据本发明的第二个方面，提供了一种订单处理装置，该装置包括：
11.请求接收模块，用于接收订单提交请求，其中，所述订单提交请求中携带有用户标识信息、消费场景类型信息以及与所述消费场景类型信息对应的至少一个消费信息；
12.信息调取模块，用于基于所述消费场景类型信息和所述用户标识信息，在数据库中调取预先设置的与所述消费信息对应的消费限定要求；
13.条件判断模块，用于判断所述消费信息是否满足对应的消费限定要求；
14.订单处理模块，用于若所述消费信息满足对应的消费限定要求，则对所述订单提交请求进行处理，得到订单信息。
15.根据本发明的第三个方面，提供了一种存储介质，其上存储有计算机程序，所述程序被处理器执行时实现上述订单处理方法。
16.根据本发明的第四个方面，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述订单处理方法。
17.本发明提供的一种订单处理方法、装置、存储介质及计算机设备，首先，通过识别用户的下单信息，从下单信息中提取该用户的用户标识以获取该用户或用户所在公司的主体信息，并识别该下单信息中的消费场景类型信息以及该消费场景类型信息对应的消费信息。然后基于消费场景类型信息以及用户标识信息从数据库中提取与该消费场景类型信息和用户标识信息对应的消费限定要求，用于判定该消费场景类型信息对应的消费信息是否满足消费限定要求。最后，判断消费信息是否满足与消费信息对应的消费限定要求，如果消费信息满足与消费信息对应的消费限定要求，则判定用户订单具有有效性，使用户下单通过，得到订单信息。本技术基于订单中的用户标识信息、消费场景类型信息从数据库中筛选与该订单包含的每个消费信息对应的要求信息，通过判定每个消费信息是否满足要求信息的方式，判定订单的有效性。相较于现有的为每个公司单独设置专门的订单有效性控制逻辑的方式而言，可以显著降低费用控制系统的代码体量，从而提高费用控制系统的响应效率。
18.上述说明仅是本技术技术方案的概述，为了能够更清楚了解本技术的技术手段，而可依照说明书的内容予以实施，并且为了让本技术的上述和其它目的、特征和优点能够更明显易懂，以下特举本技术的具体实施方式。
附图说明
19.此处所说明的附图用来提供对本发明的进一步理解，构成本技术的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
20.图1示出了本发明实施例提供的一种订单处理方法的流程示意图；
21.图2示出了本发明实施例提供的一种订单处理置的结构示意图；
22.图3示出了本发明实施例提供的另一种订单处理装置的结构示意图。
具体实施方式
23.下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本技术中的实施例及实施例中的特征可以相互组合。
24.目前，公司、团体的员工多使用各大互联网厂商搭建在线交易平台购买交通出行，差旅住宿服务。然而，不同的公司对其员工购买的交通住宿服务有着多样的限制要求，如对购买机票的舱等有着特定的限制，若员工购买的服务不满足该公司对于服务的限制要求，则判定该购买订单无效。其中，在线商务平台的核心在于费用控制系统，其用于接收各公司、团体的员工基于在线平台提交的订单提交请求，并根据订单提交请求内的信息，对订单提交请求进行处理，确定订单信息并购买服务。对于互联网厂商而言，当面对有着不同限制要求的公司，在搭建费用控制系统时，需要为有着不同限制要求的公司设置专门的订单有效性控制逻辑，以确保该公司的人员能够购买符合该公司限制要求的服务。进一步的，对于
在线交易平台而言，在线交易平台每包含一家合作公司，在线交易平台的费用控制系统就要多包含一套针对该公司的控制逻辑，导致费用控制系统的代码体量过于臃肿，降低了费用控制系统的响应效率。
25.针对上述问题，在一个实施例中，如图1所示，提供了一种订单处理方法，以该方法应用于计算机设备为例进行说明，包括以下步骤：
26.101、接收订单提交请求。
27.其中，所述订单提交请求中携带有用户标识信息、消费场景类型信息以及与所述消费场景类型信息对应的至少一个消费信息。进一步的，用户标识信息可以为针对各公司、团体设置的身份标识号(identity document.id)，用于识别接收到的订单提交请求所属的具体的公司；消费场景类型信息用于标识所购买的服务所属的消费场景，如交通出行方面的航空出行场景和差旅住宿方面的酒店住宿场景；消费信息用于标识公司、团体所购买的具体得服务事项信息，可以包括数值信息如航空出行场景中舱等费用在内的数值类信息，以及航空出行场景中舱等信息在内的文字类信息等。
28.具体的，当有订单提交请求发送到费用控制系统时，可以对接收到的订单提交请求中携带有用户标识信息、消费场景类型信息以及与所述消费场景类型信息对应的至少一个消费信息进行识别，得到订单提交请求中携带的用户标识信息、消费场景类型信息以及与所述消费场景类型信息对应的至少一个消费信息，并将上述信息存储到本地。
29.102、基于所述消费场景类型信息和所述用户标识信息，在数据库中调取预先设置的与所述消费信息对应的消费限定要求。
30.其中，在数据库中存储有针对每一个公司、团体对于购买交通出行，差旅住宿服务等不同消费场景类型而预先设置的消费限定要求。进一步的，每个消费限定要求对应有订单提交请求中的特定的消费信息，如舱等费用信息可以对应有包含该公司、团体对于其内部人员购买机票舱等费用的要求，用于判断该内部人员购买的服务是否符合该人员所属公司、团体对于该服务的要求。具体的，该消费限定要求与消费信息对应，若消费信息为数值类信息，如酒店住宿的金额，则与该消费信息对应的消费限定要求可以为对该金额的限定要求，如限定的金额范围等；若消费信息为文字类信息，如酒店住宿的名称，则与该消费信息对应的消费限定要求可以为对该酒店名称的限定要求。进一步的，消费限定要求与其对应的消费信息具有关联，并与消费信息对应的消费场景类型信息及用户标识信息映射存储到数据库中。
31.具体的，当得到订单提交请求中携带的用户标识信息、消费场景类型信息以及与所述消费场景类型信息对应的至少一个消费信息之后，可以基于消费场景类型信息和用户标识信息从数据库中调取与该消费场景类型信息及用户标识信息对应的消费限定要求。
32.103、判断所述消费信息是否满足对应的消费限定要求。
33.具体的，可以根据订单提交请求中的消费信息，并基于消费信息与其对应的消费限定要求的关联关系，在数据库中调取的消费限定要求中选取与订单提交请求中的消费信息对应的消费限定要求。进一步的，针对每一个消费信息，判断该消费信息中的数值类信息和/或文字类信息是否符合其所对应的消费限定要求，例如，若消费信息为酒店住宿的金额，则判断该金额是否满足对应的消费限定要求中关于金额的要求，若消费信息为酒店住宿的酒店名称，则判断该酒店名称是否与对应的消费限定要求中关于酒店名称的要求相吻
合(即消费信息中的酒店名称与消费限定要求中的酒店名称相同，或文字相似度超过预设阈值)。
34.104、若所述消费信息满足对应的消费限定要求，则对所述订单提交请求进行处理，得到订单信息。
35.具体的，如果消费信息为酒店住宿的金额，则判断该金额是否满足对应的消费限定要求中关于金额的要求，在该金额满足对应的消费限定要求中关于金额的要求的情况下，指示费用控制系统对所述订单提交请求进行处理，得到订单信息，从而可以购买所述订单信息中所涉及的服务。如果消费信息为酒店住宿的酒店名称，则判断该酒店名称是否与对应的消费限定要求中关于酒店名称的要求相吻合，在该酒店名称与对应的消费限定要求中关于酒店名称的要求相吻合的情况下，指示费用控制系统对所述订单提交请求进行处理，得到订单信息，从而，可以购买所述订单信息中所涉及的服务。与此相对的，在该金额不满足对应的消费限定要求中关于金额的要求的情况下，可以指示费用控制系统对订单提交请求进行中止处理；在该酒店名称与对应的消费限定要求中关于酒店名称的要求不能吻合的情况下，可以指示费用控制系统对订单提交请求进行中止处理。
36.本实施例提供的订单处理方法，首先，通过识别用户的下单信息，从下单信息中提取该用户的用户标识以获取该用户或用户所在公司的主体信息，并识别该下单信息中的消费场景类型信息以及该消费场景类型信息对应的消费信息。然后基于消费场景类型信息以及用户标识信息从数据库中提取与该消费场景类型信息和用户标识信息对应的消费限定要求，用于判定该消费场景类型信息对应的消费信息是否满足消费限定要求。最后，判断消费信息是否满足与消费信息对应的消费限定要求，如果消费信息满足与消费信息对应的消费限定要求，则判定用户订单具有有效性，使用户下单通过，得到订单信息。本技术基于订单中的用户标识信息、消费场景类型信息从数据库中筛选与该订单包含的每个消费信息对应的要求信息，通过判定每个消费信息是否满足要求信息的方式，判定订单的有效性。相较于现有的为每个公司单独设置专门的订单有效性控制逻辑的方式而言，可以显著降低费用控制系统的代码体量，从而提高费用控制系统的响应效率。
37.在本技术的实施例中，所述消费场景类型信息包括机票信息，所述消费信息包括舱等信息、舱等费用信息以及舱等折扣信息中的至少一种信息，所述消费限定要求包括舱等要求、舱等费用要求以及舱等折扣要求中的至少一种要求。其中，机票信息可以指公司、团体在需要购买航空运输服务时发送的信息；舱等信息可以包括航班的头等舱、公务舱和经济舱；舱等费用信息可以为购买该航班服务的金额信息；舱等折扣信息可以为购买该航班所享受的折扣信息。相应的，舱等要求可以限定购买航班舱等的要求，如限定此次订单必须要购买头等舱、公务舱等要求；舱等费用要求可以限定购买当次航班服务的金额要求；舱等折扣要求可以为购买当次航班服务所需要享受的折扣要求。在实际操作中，可以根据实际情况，消费信息可以为舱等信息、舱等费用信息以及舱等折扣信息中的一种或多种。相应的，消费限定要求也可以为舱等要求、舱等费用要求以及舱等折扣要求中的一种或多种。应当注意的是，上述实施例只是提供了机票信息对应的航空运输消费场景类型中常见的消费信息以及与其对应的消费限定要求，其他与购买民航运输服务相关的消费信息以及与其对应的消费限定要求同样适用于本实施例。
38.进一步的，所述判断所述消费信息是否满足对应的消费限定要求，包括：
39.依次判断所述舱等信息是否满足所述舱等要求、所述舱等费用信息是否满足所述舱等费用要求、所述舱等折扣信息是否满足所述舱等折扣要求。具体的，首先，获取消费场景类型信息为机票信息所对应的舱等信息、舱等费用信息以及舱等折扣信息，进一步的，判断舱等信息是否符合舱等要求，如果预设的消费限定要求中舱等要求为经济舱，则判断舱等信息是否为经济舱；判断舱等费用信息是否符合舱等费用要求，如果预设的消费限定要求中舱等费用要求为机票的金额需要在1500元以下，则判断舱等费用信息中的金额信息是否为1500元以下；判断舱等折扣信息是否符合舱等折扣要求，如果预设的消费限定要求中舱等折扣要求为机票享受的折扣需要为8折及以下，则判断舱等折扣信息中的折扣信息是否为8折及以下。
40.进一步的，所述若所述消费信息满足对应的消费限定要求，则对所述订单提交请求进行处理，得到订单信息，包括：
41.若所述舱等信息满足所述舱等要求、所述舱等费用信息满足所述舱等费用要求、所述舱等折扣信息满足所述舱等折扣要求，则对所述订单提交请求进行处理，得到订单信息。具体的，如果预设的消费限定要求中舱等要求为经济舱，若舱等信息为经济舱，则对所述订单提交请求进行处理，得到订单信息；如果预设的消费限定要求中舱等费用要求为1500元以下，若舱等费用信息中的机票的金额信息为1400元，则对所述订单提交请求进行处理，得到订单信息；如果预设的消费限定要求中舱等折扣要求为8折及以下，若舱等折扣信息中机票享受的折扣为7折，则对所述订单提交请求进行处理，得到订单信息。相对的，如果预设的消费限定要求中舱等要求为经济舱，若舱等信息为头等舱，则对订单提交请求进行中止处理；如果预设的消费限定要求中舱等费用要求为1500元以下，若舱等费用信息中机票的金额信息为1800元，则对订单提交请求进行中止处理；如果，预设的消费限定要求中舱等折扣要求为8折及以下，若舱等折扣信息中机票享受的为折扣9折，则对订单提交请求进行中止处理。
42.本技术提供的实施例，可以针对各公司、团体对于消费场景类型信息为机票信息对应的航空运输服务场景时，从数据库中获取针对各消费信息预设相应的消费限定要求，并判断消费信息是否符合消费限定要求。当需要购买航空运输服务时，判断各项消费信息是否符合预设的消费限定要求，在消费信息符合预设的消费限定要求时，判定订单有效，并允许进行后续的订单处理，购买相应的服务。从而不必在费用控制系统中设置针对每一个公司的航空运输服务订单有效性控制逻辑，可以显著降低费用控制系统的代码体量，从而提高费用控制系统的响应效率。
43.在本技术的实施例中，所述消费场景类型信息还包括酒店信息，所述消费信息还包括额度信息、酒店星级信息以及酒店名称信息中的至少一种信息，所述消费限定要求还包括：额度要求、酒店星级要求以及酒店限定要求中的至少一种要求。其中，酒店信息可以指公司、团体在购买酒店住宿服务时的发送的信息；额度信息可以为购买酒店住宿服务所需的金额；酒店星级信息可以为所购买酒店住宿服务的酒店的星级信息；酒店名称信息可以为所购买酒店住宿服务的酒店的名称信息。相应的，额度要求可以为限定购买酒店住宿服务的金额要求，如限定此次订单的金额需要处于特定的数值区间；酒店星级要求可以为限定所购买酒店住宿服务的酒店的星级；酒店限定要求可以为所购买酒店住宿服务的酒店的名称，可以为与公司、团体预订协议价格的酒店。在实际操作中，可以根据实际情况，消费
信息可以为额度信息、酒店星级信息以及酒店名称信息中的一种或多种。相应的，消费限定要求也可以为额度要求、酒店星级要求以及酒店限定要求中的一种或多种。应当注意的是，上述实施例只是提供了酒店信息对应的酒店消费场景类型中常见的消费信息以及与其对应的消费限定要求，其他与购买酒店住宿服务相关的消费信息以及与其对应的消费限定要求同样适用于本实施例。
44.进一步的，所述判断所述消费信息是否满足对应的消费限定要求，包括：
45.依次判断所述额度信息是否满足所述额度要求、所述酒店星级信息是否满足所述酒店星级要求、所述酒店名称信息是否满足所述酒店限定要求。具体的，首先，获取消费场景类型信息为酒店信息下的额度信息、酒店星级信息以及酒店名称信息，进一步的，判断额度信息是否符合额度要求，如预设的额度要求为酒店住宿的金额需要在1000元以下，则判断额度信息中酒店住宿的金额信息是否为1000元以下；判断酒店星级信息是否符合酒店星级要求，如预设的酒店星级要求为酒店的星级需要在3星级以上，则判断酒店星级信息中的所购买酒店住宿服务的酒店的星级是否为3星级以上；判断酒店名称信息是否符合酒店限定要求，如预设的酒店限定要求为特定的目标酒店，则判断酒店名称信息中的酒店名称是否与目标酒店的名称吻合。
46.进一步的，所述若所述消费信息满足对应的消费限定要求，则对所述订单提交请求进行处理，得到订单信息，包括：
47.若所述额度信息满足所述额度要求、所述酒店星级信息满足所述酒店星级要求、所述酒店名称信息满足所述酒店限定要求，则对所述订单提交请求进行处理，得到订单信息。具体的，如果预设的消费限定要求中额度要求为酒店住宿的金额需要在1000元以下，若额度信息中酒店住宿的金额信息为900元，则对所述订单提交请求进行处理，得到订单信息；如果预设的消费限定要求中酒店星级要求为3星级以上，若酒店星级信息中的酒店星级为4星级，则对所述订单提交请求进行处理，得到订单信息；如果预设的消费限定要求中酒店限定要求为所购买酒店住宿服务的酒店名称为a酒店，若酒店名称信息中的酒店名称为a酒店，则对所述订单提交请求进行处理，得到订单信息。相对的，如果预设的消费限定要求中额度要求为酒店住宿的金额需要在1000元以下，若额度信息中酒店住宿的金额信息为1200元，则对订单提交请求进行中止处理；如果预设的消费限定要求中酒店星级要求为3星级以上，若酒店星级信息中的酒店星级为2星级，则对订单提交请求进行中止处理；如果预设的消费限定要求中酒店限定要求为所购买酒店住宿服务的酒店名称为a酒店，若酒店名称信息中的酒店名称为b酒店，则对订单提交请求进行中止处理。
48.本技术提供的实施例，可以针对各公司、团体对于消费场景类型信息为酒店信息对应的酒店住宿服务场景时，从数据库中获取针对各消费信息预设相应的消费限定要求，并判断消费信息是否符合消费限定要求。当需要购买酒店住宿服务时，判断各项消费信息是否符合预设的消费限定要求，在消费信息符合预设的消费限定要求时，判定订单有效，并允许进行后续的订单处理，购买相应的服务，从而不必在费用控制系统中设置针对每一个公司的酒店住宿服务订单有效性控制逻辑，可以显著降低费用控制系统的代码体量，从而提高费用控制系统的响应效率。
49.在本技术的实施例中，所述消费场景类型信息还包括用车信息，所述消费信息还包括里程信息、车型信息以及乘车地点信息中的至少一种信息，所述消费限定要求还包括：
里程要求、车型要求以及乘车地点要求中的至少一种要求。其中，用车信息对应的消费场景类型可以为车辆交通运输场景。具体的，用车信息可以在订单提交请求中提取，如果订单提交请求中包含与用车服务相关的信息或用车信息这一信息类型，则确定消费场景类型为用车信息。里程信息可以指公司、团体中的人员购买车辆运输服务时的运输里程信息；车型信息可以为公司、团体中的人员购买车辆运输服务的车辆车型；乘车地点信息可以为公司、团体中的人员所购买车辆运输服务的乘车地点以及是否为跨区域运输。相应的，里程要求可以为对于买车辆运输服务的里程限制信息，如限定当次车辆运输服务的里程需要在100公里以下；车型信息可以为对于购买车辆运输服务的车辆车型限制信息，如限定当次车辆运输服务车辆车型需要为中型车辆；乘车地点要求可以为当次车辆运输服务的乘车地点需要为从a地到b地，且不允许跨地区运输。在实际操作中，可以根据实际情况，消费信息可以为里程信息、车型信息以及乘车地点信息中的一种或多种。相应的，消费限定要求也可以为里程要求、车型要求以及乘车地点要求中的一种或多种。应当注意的是，上述实施例只是提供了与用车信息对应的车辆交通运输消费场景类型中常见的消费信息以及与其对应的消费限定要求，其他与购买车辆交通运输相关的消费信息以及与其对应的消费限定要求同样适用于本实施例。
50.进一步的，所述判断所述消费信息是否满足对应的消费限定要求，包括：
51.依次判断所述里程信息是否满足所述里程要求、所述车型信息是否满足所述车型要求、所述乘车地点信息是否满足所述乘车地点要求。具体的，首先，获取消费场景类型信息为用车信息下的里程信息、车型信息以及乘车地点信息，进一步的，判断里程信息是否符合里程要求，如果预设的里程要求为当次车辆运输服务的里程需要在100公里以下，则判断里程信息中车辆运输服务的里程是否为100公里以下；判断车型信息是否符合车型要求，如果预设的车型要求限定当次车辆运输服务车辆车型需要为中型车辆，则判断车型信息中车辆运输服务车辆车型是否为中型车辆；判断乘车地点信息是否符合乘车地点要求，如果预设的乘车地点要求当次车辆运输服务的乘车地点需要为从a地到b地，且不允许跨地区运输，则判断乘车地点信息中的乘车信息是否为从a地到b地，并是否出现跨地区运输。
52.进一步的，所述若所述消费信息满足对应的消费限定要求，则对所述订单提交请求进行处理，得到订单信息，包括：
53.若所述里程信息满足所述里程要求、所述车型信息满足所述车型要求、所述乘车地点信息满足所述乘车地点要求，则对所述订单提交请求进行处理，得到订单信息。具体的，如果预设的消费限定要求中里程要求为当次车辆运输服务的里程需要在100公里以下，若里程信息中车辆运输服务的里程为50公里，则对所述订单提交请求进行处理，得到订单信息；如果预设的消费限定要求中车型要求为限定当次车辆运输服务车辆车型需要为中型车辆，若车型信息中车辆运输服务车辆车型为中型车，则对所述订单提交请求进行处理，得到订单信息；如果预设的消费限定要求中乘车地点要求为当次车辆运输服务的乘车地点需要为从a地到b地，且不允许跨地区运输，若乘车地点信息中的乘车信息为从a地到b地，并没有出现跨地区运输，则对所述订单提交请求进行处理，得到订单信息。相对的，如果预设的消费限定要求中里程要求为当次车辆运输服务的里程需要在100公里以下，若里程信息中车辆运输服务的里程为150公里，则对订单提交请求进行中止处理；如果预设的消费限定要求中车型要求为限定当次车辆运输服务车辆车型需要为中型车辆，若车型信息中当次车辆
运输服务的车辆车型为中大型车，则对订单提交请求进行中止处理；如果预设的消费限定要求中乘车地点要求为当次车辆运输服务的乘车地点需要为从a地到b地，且不允许跨地区运输，若乘车地点信息中的乘车信息为从a地到c地，和/或出现了跨地区运输，则对订单提交请求进行中止处理。
54.本技术提供的实施例，可以针对各公司、团体对于消费场景类型信息为用车信息车辆交通运输服务场景时，从数据库中获取针对各消费信息预设相应的消费限定要求，并判断消费信息是否符合消费限定要求。当需要购买车辆交通运输服务时，判断各项消费信息是否符合预设的消费限定要求，在消费信息符合预设的消费限定要求时，判定订单有效，并允许进行后续的订单处理，购买相应的服务，从而不必在费用控制系统中设置针对每一个公司的车辆交通运输服务订单有效性控制逻辑，可以显著降低费用控制系统的代码体量，从而提高费用控制系统的响应效率。
55.在本技术的实施例中，所述消费场景类型信息还包括火车信息，所述消费信息还包括座等信息，所述消费限定要求还包括座等要求。其中，火车信息可以指公司、团体在需要购买铁路运输服务时的消费场景类型信息,具体的，火车信息可以在订单提交请求中提取，如果订单提交请求中包含与火车服务相关的信息或火车信息这一信息类型，则确定消费场景类型为火车信息。座等信息可以为购买铁路运输服务的座位等级，如特等座、一等座以及二等座等。相应的，座等要求可以为限定购买铁路运输座等的要求，如限定此次订单必须要购买一等座、二等座等要求。应当注意的是，上述实施例只是提供了火车信息对应的铁路运输消费场景类型中常见的消费信息以及与其对应的消费限定要求，其他与购买铁路运输服务相关的消费信息以及与其对应的消费限定要求同样适用于本实施例。
56.进一步的，所述判断所述消费信息是否满足对应的消费限定要求，包括：
57.判断所述座等信息是否满足所述座等要求。具体的，首先，获取消费场景类型信息为火车信息下的座等信息，进一步的，判断座等信息是否满足座等要求，如果预设的消费限定要求中座等要求为当次铁路运输服务的座等需要为一等座或二等座，则判断座等信息中铁路运输服务的座等是否为一等座或二等座。
58.进一步的，所述若所述消费信息满足对应的消费限定要求，则对所述订单提交请求进行处理，得到订单信息，包括：
59.若所述座等信息满足所述座等要求，则对所述订单提交请求进行处理，得到订单信息。如果预设的消费限定要求中座等要求为当次铁路运输服务的座等需要为一等座或二等座，若座等信息中铁路运输服务的座等为一等座，则对所述订单提交请求进行处理，得到订单信息。相对的，如果预设的消费限定要求中座等要求为当次铁路运输服务的座等需要为一等座或二等座，若座等信息中铁路运输服务的座等为特等座，则对订单提交请求进行中止处理。
60.本技术提供的实施例，可以针对各公司、团体对于消费场景类型信息为火车信息对应的铁路运输场景时，从数据库中获取针对各消费信息预设相应的消费限定要求，并判断消费信息是否符合消费限定要求。当需要购买铁路运输服务时，判断各项消费信息是否符合预设的消费限定要求，在消费信息符合预设的消费限定要求时，判定订单有效，并允许进行后续的订单处理，购买相应的服务，从而不必在费用控制系统中设置针对每一个公司的铁路运输服务订单有效性控制逻辑，可以显著降低费用控制系统的代码体量，从而提高
费用控制系统的响应效率。
61.进一步的，可以根据订单提交请求中的下单时间信息以及所购买服务的信息，计算出下单时间至服务时间之间的提前预定天数，并将预定天数与数据库中相应公司、团体对于提前预订天数的消费限定要求进行对比，若预定天数满足提前预订天数的消费限定要求，则对所述订单提交请求进行处理，得到订单信息。若预定天数不满足提前预订天数的消费限定要求，则对订单提交请求进行中止处理。
62.应当注意的是，本技术实施例对应的消费场景可以包括上述的消费场景类型以外的其他消费场景，如展会服务场景、采购场景等，具体的适用过程可以如对上文步骤的描述，这里不再赘述。
63.在本技术的实施例中，在步骤102所述的基于所述消费场景类型信息和所述用户标识信息，在数据库中调取预先设置的与所述消费信息对应的消费限定要求之前，所述方法还包括：首先，响应于信息录入请求，展示信息录入页面。其中，所述信息录入请求中包括用户标识信息和消费场景类型信息。具体的，当需要对在线交易平台中配置公司、团体购买交通住宿服务的限制要求时，可以对费用控制系统发出信息录入请求，将该公司、团体的用户标识信息和消费场景类型信息录入到费用控制系统中，得到与该用户标识信息和消费场景类型信息对应的信息录入页面。其中，信息录入页面可以包括用户标识信息显示栏，用于显示该公司、团体对应的身份标识号；消费场景类型信息显示栏，用于标注与该公司、团体对应的消费场景类型；消费限定要求标签栏，用于输入该消费限定要求的名称，如舱等费用要求；消费限定要求标签值栏，用于处输入消费限定要求的具体要求，如舱等费用要求的金额数值要求。然后，接收用户输入的消费限定请求，并对所述消费限定请求、所述用户标识信息和所述消费场景类型信息进行映射存储。具体的，可以在消费限定要求标签栏中输入该消费限定要求的名称，并在消费限定要求标签值栏中输入该消费限定要求的具体要求。随后，对消费限定请求、用户标识信息和消费场景类型信息进行映射存储。本技术提供的实施例，可以灵活简便地对费用控制系统中的各公司、团体在购买交通住宿服务时的限制要求进行新增与修改，提高费用控制系统的运行效率。
64.在本技术的实施例中，在步骤104之后，所述方法还包括：若所述消费信息不满足对应的消费限定要求，则对所述订单提交请求进行中止处理，并对不满足所述消费限定要求的消费信息进行显示。具体的，当消费信息不满足对应的消费限定要求时，停止对订单提交请求的处理，以使公司、团体内的员工不能通过该订单购买相应的交通住宿服务。进一步的，识别出不满足相应消费限定要求的消费信息，并进行显示。本技术提供的实施例，可以阻止相关人员购买不符合限定要求的交通住宿服务，并使相关人员得知无法购买相应的交通住宿服务的具体原因，方便其做进一步处理。
65.本实施例提供的订单处理方法，首先，通过识别用户的下单信息，从下单信息中提取该用户的用户标识以获取该用户或用户所在公司的主体信息，并识别该下单信息中的消费场景类型信息以及该消费场景类型信息对应的消费信息。然后，基于消费场景类型信息以及用户标识信息从数据库中提取与该消费场景类型信息和用户标识信息对应的消费限定要求，用于判定该消费场景类型信息对应的消费信息是否满足消费限定要求。最后，判断消费信息是否满足与和消费信息对应消费限定要求，如果消费信息满足与和消费信息对应消费限定要求，则判定用户订单具有有效性，使用户下单通过，得到订单信息，进一步的，如
果消费信息不满足与和消费信息对应消费限定要求，则对所述订单提交请求进行中止处理，阻止相关人员购买不符合限定要求的交通住宿服务，并显示造成无法得到订单信息，购买相关服务的具体事项，以使相关人员得知无法购买相应的交通住宿服务的具体原因，方便其做进一步处理。本技术能够覆盖大多数的公司、团体对于交通住宿服务的需求场景，如航空服务场景、酒店住宿服务场景、车辆交通运输服务场景以及铁路运输服务场景，满足各公司、团体对于购买交通住宿服务的大多数需求。同时，可以基于订单中的用户标识信息、消费场景类型信息从数据库中筛选与该订单包含的每个消费信息对应的要求信息，通过判定每个消费信息是否满足要求信息的方式，判定订单的有效性。相较于现有的为每个公司单独设置专门的订单有效性控制逻辑的方式而言，可以显著降低费用控制系统的代码体量，从而提高费用控制系统的响应效率。
66.进一步的，作为图1所示方法的具体实现，本实施例提供了一种订单处理装置，如图2所示，该装置包括：请求接收模块21、信息调取模块22、条件判断模块23和订单处理模块24。
67.请求接收模块21，可用于接收订单提交请求，其中，所述订单提交请求中携带有用户标识信息、消费场景类型信息以及与所述消费场景类型信息对应的至少一个消费信息；
68.信息调取模块22，可用于基于所述消费场景类型信息和所述用户标识信息，在数据库中调取预先设置的与所述消费信息对应的消费限定要求；
69.条件判断模块23，可用于判断所述消费信息是否满足对应的消费限定要求；
70.订单处理模块24，可用于若所述消费信息满足对应的消费限定要求，则对所述订单提交请求进行处理，得到订单信息；
71.在具体的应用场景中，所述条件判断模块23，具体可用于依次判断所述舱等信息是否满足所述舱等要求、所述舱等费用信息是否满足所述舱等费用要求、所述舱等折扣信息是否满足所述舱等折扣要求；
72.在具体的应用场景中，所述订单处理模块24，具体可用于若所述舱等信息满足所述舱等要求、所述舱等费用信息满足所述舱等费用要求、所述舱等折扣信息满足所述舱等折扣要求，则对所述订单提交请求进行处理，得到订单信息；
73.在具体的应用场景中，所述条件判断模块23，具体还可用于依次判断所述额度信息是否满足所述额度要求、所述酒店星级信息是否满足所述酒店星级要求、所述酒店名称信息是否满足所述酒店限定要求；
74.在具体的应用场景中，所述订单处理模块24，具体还可用于若所述额度信息满足所述额度要求、所述酒店星级信息满足所述酒店星级要求、所述酒店名称信息满足所述酒店限定要求，则对所述订单提交请求进行处理，得到订单信息；
75.在具体的应用场景中，所述条件判断模块23，具体还可用于依次判断所述里程信息是否满足所述里程要求、所述车型信息是否满足所述车型要求、所述乘车地点信息是否满足所述乘车地点要求；
76.在具体的应用场景中，所述订单处理模块24，具体还可用于若所述里程信息满足所述里程要求、所述车型信息满足所述车型要求、所述乘车地点信息满足所述乘车地点要求，则对所述订单提交请求进行处理，得到订单信息；
77.在具体的应用场景中，所述条件判断模块23，具体还可用于判断所述座等信息是
否满足所述座等要求；
78.在具体的应用场景中，所述订单处理模块24，具体还可用于若所述座等信息满足所述座等要求，则对所述订单提交请求进行处理，得到订单信息。
79.在具体的应用场景中，如图3所示，本装置还包括数据录入模块31，所述数据录入模块31具体可用于响应于信息录入请求，展示信息录入页面，其中，所述信息录入请求中包括用户标识信息和消费场景类型信息；接收用户输入的消费限定请求，并对所述消费限定请求、所述用户标识信息和所述消费场景类型信息进行映射存储；
80.在具体的应用场景中，如图3所示，本装置还包括问题显示模块36，所述问题显示模块36具体可用于若所述消费信息不满足对应的消费限定要求，则对所述订单提交请求进行中止处理，并对不满足所述消费限定要求的消费信息进行显示；
81.需要说明的是，本实施例提供的一种订单处理装置所涉及各功能单元的其它相应描述，可以参考图1中的对应描述，在此不再赘述。
82.基于上述如图1所示方法，相应的，本实施例还提供了一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述如图1所示的订单处理方法。
83.基于这样的理解，本技术的技术方案可以以软件产品的形式体现出来，该待识别软件产品可以存储在一个非易失性存储介质(可以是cd-rom，u盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施场景所述的方法。
84.基于上述如图1所示的方法，以及图2和图3所示的订单处理装置实施例，为了实现上述目的，本实施例还提供了一种订单处理的实体设备，具体可以为个人计算机、服务器、智能手机、平板电脑、智能手表、或者其它网络设备等，该实体设备包括存储介质和处理器；存储介质，用于存储计算机程序；处理器，用于执行计算机程序以实现上述如图1所示的方法。
85.可选的，该实体设备还可以包括用户接口、网络接口、摄像头、射频(radio frequency，rf)电路，传感器、音频电路、wi-fi模块等等。用户接口可以包括显示屏(display)、输入单元比如键盘(keyboard)等，可选用户接口还可以包括usb接口、读卡器接口等。网络接口可选的可以包括标准的有线接口、无线接口(如wi-fi接口)等。
86.本领域技术人员可以理解，本实施例提供的一种订单处理的实体设备结构并不构成对该实体设备的限定，可以包括更多或更少的部件，或者组合某些部件，或者不同的部件布置。
87.存储介质中还可以包括操作系统、网络通信模块。操作系统是管理上述实体设备硬件和待识别软件资源的程序，支持信息处理程序以及其它待识别软件和/或程序的运行。网络通信模块用于实现存储介质内部各组件之间的通信，以及与信息处理实体设备中其它硬件和软件之间通信。
88.通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本技术可以借助软件加必要的通用硬件平台的方式来实现，也可以通过硬件实现。通过应用本技术的技术方案，首先，接收订单提交请求，其中，所述订单提交请求中携带有用户标识信息、消费场景类型信息以及与所述消费场景类型信息对应的至少一个消费信息；然后，基于所述消费场景类型信息和所述用户标识信息，在数据库中调取预先设置的与所述消费信息对应的消
费限定要求；再后，判断所述消费信息是否满足对应的消费限定要求；最后，若所述消费信息满足对应的消费限定要求，则对所述订单提交请求进行处理，得到订单信息。与现有技术相比，可以显著降低费用控制系统的代码体量，从而提高费用控制系统的响应效率。
89.本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本技术所必须的。本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。
90.上述本技术序号仅仅为了描述，不代表实施场景的优劣。以上公开的仅为本技术的几个具体实施场景，但是，本技术并非局限于此，任何本领域的技术人员能思之的变化都应落入本技术的保护范围。