CN116109426A - 用车场景中用车差标管控方法以及装置、电子设备、存储介质 - Google Patents

Abstract

本申请公开了一种用车场景中用车差标管控方法以及装置、电子设备、存储介质。该方法包括确定用户的类型；根据所述用户的类型，按照所述用车差标中的预设管控维度对用户进行管控，以使所述用户在用车场景中在用车差标超标的限制情况或者用车差标未超标的情况使用叫车服务。本申请解决了用车差标的合规性的技术问题。

Description

用车场景中用车差标管控方法以及装置、电子设备、存储介质

技术领域

本申请涉及差标管控领域，具体而言，涉及一种用车场景中用车差标管控方法以及装置、电子设备、存储介质。

背景技术

企业员工消费报销是企业财务管控领域中的重要内容，而企业员工消费的重要比例主要集中于办公物品采购以及员工远途、近途外出公干所产生的商旅/差旅服务费用(例如出差所产生的机票、机票和火车票费用，以及酒店住宿费用、打车费用等)。

其中企业员工打车即企业用车，作为外出公干所需要经常使用和接触的差旅消费场景，无论是从使用频次、订单数量、消费金额等维度，对企业管理员工消费合规性而言都是重中之重。如何管控好企业员工用车消费过程中的消费合规性，对企业而言是一个越来越重要的话题。

如何通过合理的用车差标管控规则应用于企业用车的全过程管控，以达到能够有效管控企业用车合规性的效果，目前尚未提出有效的解决方案。

发明内容

本申请的主要目的在于提供一种用车场景中用车差标管控方法以及装置、电子设备、存储介质，以解决用车差标的合规性的问题。

为了实现上述目的，根据本申请的一个方面，提供了一种用车场景中用车差标管控方法。

根据本申请的用车场景中用车差标管控方法包括：

确定用户的类型；

根据所述用户的类型，按照所述用车差标中的预设管控维度对用户进行管控，以使所述用户在用车场景中在用车差标超标的限制情况或者用车差标未超标的情况使用叫车服务。

进一步地，所述用车场景至少包括如下之一：用车服务前，用车服务中、用车服务后，所述方法还包括：

按照所述用车差标中的预设管控维度在所述用车场景为用户用车服务前，对用户进行第一管控维度的管控；

和/或，

按照所述用车差标中的预设管控维度在所述用车场景为用户用车服务中，对用户进行第二管控维度的管控；

和/或，

按照所述用车差标中的预设管控维度在所述用车场景为用户用车后，对用户进行第三管控维度的管控，

其中所述第一管控维度用于在用户用车前校验、所述第二管控维度用于在用户用车服务中校验以及第三管控维度用于在用户用车后校验，且均不相同。

进一步地，所述预设管控维度至少包括如下之一：用车运力限制维度、用车服务限制维度、用车车型限制维度、用车单价限制维度、用车预算限制维度、用车次数限制维度、用车时间限制维度、用车地点限制维度、用车城市限制维度、用车跨城打车限制维度，所述第一管控维度、所述第二管控维度以及第三管控维度采用所述预设管控维度中的至少一种或多种，不同的所述用车场景配置多个所述用车差标，且每个所述用车差表关联所述用户的类型。

进一步地，所述按照所述用车差标中的预设管控维度在所述用车场景为用户用车后时，对用户进行第三管控维度的管控，包括：

所述预设管控维度包括用车差标超标或者用车差标未超标的情况，当用车差标超标的情况下，按照超标时无需审批、超标时需要审批、超标时可选审批中的不同分类按照第二预设支付方式进行付款或报销审批，其中所述第二预设支付方式至少包括企业支付、用户个人支付、用户和企业混合支付中的任一一种或多种；

当用车差标未超标的情况下，按照第一预设支付方式进行付款，其中所述第一预设支付方式包括企业支付。

进一步地，所述确定用户的类型，包括：确定不同的用户角色、用户人员或者用户职级。

进一步地，所述方法还包括：

通过用户端的用车首页，展示所述用户在用车场景中在用车差标超标的限制情况或者用车差标未超标的情况下对应的所述用车差标；

通过所述用户端的预估价查看页面，展示所述用户在用车场景中在用车差标超标的限制情况或者用车差标未超标的情况下对应的所述用车差标；

通过所述用户端的订单确认页面，展示所述用户在用车场景中在用车差标超标的限制情况或者用车差标未超标的情况下对应的所述用车差标。

进一步地，所述方法还包括：

在服务端维护多张与所述预设管控维度对应的数据库表结构，用于保存用车差标信息以及用车场景信息。

为了实现上述目的，根据本申请的另一方面，提供了一种用车场景中用车差标管控装置。

根据本申请的用车场景中用车差标管控装置包括：

确定模块，用于确定用户的类型；

管控模块，用于根据所述用户的类型，按照所述用车差标中的预设管控维度对用户进行管控，以使所述用户在用车场景中在用车差标超标的限制情况或者用车差标未超标的情况使用叫车服务。

根据本申请的又一个方面，还提供了一种存储介质，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

根据本申请的再一个方面，还提供了一种电子设备，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述任一项方法实施例中的步骤。

在本申请实施例中，采用确定用户的类型的方式，通过根据所述用户的类型，按照所述用车差标中的预设管控维度对用户进行管控，达到了多维度权过程管控的目的，从而实现了所述用户在用车场景中在用车差标超标的限制情况或者用车差标未超标的情况使用叫车服务的技术效果，进而解决了用车差标的合规性的技术问题。

附图说明

构成本申请的一部分的附图用来提供对本申请的进一步理解，使得本申请的其它特征、目的和优点变得更明显。本申请的示意性实施例附图及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的用车场景中用车差标管控方法的流程示意图；

图2是根据本申请实施例的用车场景中用车差标管控装置的结构示意图；

图3是根据本申请实施例的用车场景中用车差标管控方法中差旅标准展示界面示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本申请中，术语“上”、“下”、“左”、“右”、“前”、“后”、“顶”、“底”、“内”、“外”、“中”、“竖直”、“水平”、“横向”、“纵向”等指示的方位或位置关系为基于附图所示的方位或位置关系。这些术语主要是为了更好地描述本申请及其实施例，并非用于限定所指示的装置、元件或组成部分必须具有特定方位，或以特定方位进行构造和操作。

并且，上述部分术语除了可以用于表示方位或位置关系以外，还可能用于表示其他含义，例如术语“上”在某些情况下也可能用于表示某种依附关系或连接关系。对于本领域普通技术人员而言，可以根据具体情况理解这些术语在本申请中的具体含义。

此外，术语“安装”、“设置”、“设有”、“连接”、“相连”、“套接”应做广义理解。例如，可以是固定连接，可拆卸连接，或整体式构造；可以是机械连接，或电连接；可以是直接相连，或者是通过中间媒介间接相连，又或者是两个装置、元件或组成部分之间内部的连通。对于本领域普通技术人员而言，可以根据具体情况理解上述术语在本申请中的具体含义。

发明人研究时发现，虽然现有技术中很多平台可以接入打车服务，并用于企业的后续打车服务的报销。但是目前仍无法解决企业用车的众多费用标准管控和合规性问题管控。这些问题包括：

(1)哪些角色可以使用企业用车和公司支付，哪些角色不能使用公司支付。

(2)管控哪些角色可使用哪些不同的服务，例如某些用户可叫实时用车订单、某些用户可呼叫预约用车。

(3)管控不同的角色叫车时可享受的服务标准不同：例如管理层可呼叫商务型、豪华型车型，可呼叫高价车型；普通员工仅可呼叫经济型车型、仅可呼叫低价车型。

(4)管控不同的角色可叫车的时段不同：例如管理层可随时用车、都可用企业支付，普通员工仅可加班情况下用车可用企业支付，其他情况下叫车只能个人支付或不能叫车。

(5)管控不同的角色可用车的城市和地点不同：例如员工只能在公司办公地附近500米叫车、某个部门的员工只能在北京市打车等。

(6)如果管控合规与不合规情况下可用的支付方式不同：例如管控员工满足合规性时可用企业支付自动扣款、不满足合规性时是需要个人支付、还是走二次审批流程通过后仍然可使用企业支付。

针对上述不足，本申请的实施例中提供了一种用车场景中用车差标管控方法，基于本技术和管控策略的应用，在合思商城用车平台叫车整体流程的不同环节中接入不同的管控策略和规则，在企业员工用车过程的前、中、后应用相应的管控规则，有效解决了员工在企业用车全过程的费控标准管控合规性问题。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

如图1所示，是根据本申请实施例的用车场景中用车差标管控方法的流程示意图，该方法包括如下的步骤S110至步骤S120：

步骤S110，确定用户的类型。

由于用户的类型直接影响到了用车场景中用车差标管控，所以需要首先确定出用户的类型。可以理解，不同人员/角色/岗位/职级在企业用车消费场景下不同消费维度的用量和限制。

确定用户的类型后，可管控不同的角色、人员或者职级，并可应用于一个或多个不同的人员角色/职级，基于此以实现多不同角色/职级/岗位、不同人员差异化的差标管控规则和逻辑。

需要注意的是，所述“用车消费场景”指的是企业员工在不同情况下的用车情况分类，例如加班打车、出差用车、周末打车、因私出行，均为不同的用车场景。

同时对于一个企业可以配置一个或多个用车场景，且一个用车场景下可包含一套或多套用车差标规则。

作为本实施例中的优选，所述确定用户的类型，包括：不同的用户角色、用户人员或者用户职级，所述用车场景，包括：加班打车、出差用车、周末打车或者因私出行在不同情况下的用车情况分类。

步骤S120，根据所述用户的类型，按照所述用车差标中的预设管控维度对用户进行管控，以使所述用户在用车场景中在用车差标超标的限制情况或者用车差标未超标的情况使用叫车服务。

企业用车整体消费场景可具体拆分为多个流程环节，包括用车前(用车打开APP选择用车场景、选择用车运力和价格项等步骤)、用车服务中(用户下单后、乘坐于车上时以及到达目的地这个过程)、用车服务后(用车享受完用车服务到达目的地之后)。基于这套用车差标规则可管控用车前用户可用哪些运力/服务类型/价格项。

需要注意的是，所述“用车差标”，指的是某个用车场景下某个用户/职级具体应遵循哪些限制才能使用叫车服务的一系列管控规则的集合。用车差标中多种管控维度，在本申请的实施例中并不进行具体限定，可以根据实际情况进行增减。

如果按照预设管控维度对用户进行管控时，所述用户在用车场景中在用车差标超标的限制情况使用叫车服务。

如果按照预设管控维度对用户进行管控时，所述用户也可以在用车场景中在用车差标未超标的情况使用叫车服务。

并且，对于用户而言可以通过用户端显示的提示信息进行叫车服务的确认。无论是用车差标未超标或用车差标超标可以按照预设管控规则进行管控，从而便于之后的打车报销等环节。

通过上述方法，可以解决相关技术中的不足，并获得以下技术效果：

(1)用车场景中用车差标管控方法，可管控不同的角色、人员或者职级：设计实现一套用车差标规则，该规则可应用于一个或多个不同的人员角色/职级，基于此以实现多不同角色/职级/岗位、不同人员差异化的差标管控规则和逻辑。

(2)用车场景中用车差标管控方法，可管控不同的维度：通过设计多个不同的超标管控维度，可管控不同人员/角色/岗位/职级在企业用车消费场景下不同消费维度的用量和限制。

(3)用车场景中用车差标管控方法，可管控不同合规性情况下的不同支付策略：基于用车差标规则的建模，可设定每个维度合规、或超标的阈值，预设多个支付方式，比如企业支付、个人支付、混合支付，可设定当差标情况下可使用哪些支付方式。

从以上的描述中，可以看出，本申请实现了如下技术效果：采用确定用户的类型的方式，通过根据所述用户的类型，按照所述用车差标中的预设管控维度对用户进行管控，达到了多维度权过程管控的目的，从而实现了所述用户在用车场景中在用车差标超标的限制情况或者用车差标未超标的情况使用叫车服务的技术效果，进而解决了用车差标的合规性的技术问题。

作为本实施例中的优选，所述用车场景至少包括如下之一：用车服务前，用车服务中、用车服务后，所述方法还包括：按照所述用车差标中的预设管控维度在所述用车场景为用户用车服务前，对用户进行第一管控维度的管控；和/或，按照所述用车差标中的预设管控维度在所述用车场景为用户用车服务中，对用户进行第二管控维度的管控；和/或，按照所述用车差标中的预设管控维度在所述用车场景为用户用车后，对用户进行第三管控维度的管控，其中所述第一管控维度用于在用户用车前校验、所述第二管控维度用于在用户用车服务中校验以及第三管控维度用于在用户用车后校验，且均不相同。

具体实施时，对于用车场景包括了用车服务前，用车服务中、用车服务后。也就是说，在这些场景中都会进行差标验证流程。当然，通常在用车服务前会提前进行校验，而在用车服务后会再进行校验。所述第一管控维度用于在用户用车前校验、所述第二管控维度用于在用户用车服务中校验以及第三管控维度用于在用户用车后校验，且均不相同。

按照所述用车差标中的预设管控维度在所述用车场景为用户用车服务前，对用户进行第一管控维度的管控，且管控维度从使用叫车服务前考量，选择用车场景、选择用车运力和价格项时的管控项目。

按照所述用车差标中的预设管控维度在所述用车场景为用户用车服务中，对用户进行第二管控维度的管控，且管控维度从使用叫车服务中考量，与开始用车服务之前保持一致。并确保用户下单后、乘坐于车上时以及到达目的地这个过程的合规性。

按照所述用车差标中的预设管控维度在所述用车场景为用户用车后，对用户进行第三管控维度的管控。用车使用完叫车服务到达目的地之后，基于这套用车差标规则可管控用车前用户可用哪些运力/服务类型/价格项，例如仅能选择一定范围内的价格项；可管控用户到达目的地后实际的消费行为是否超标，如未差标时可用企业支付、超标时仅可用个人支付或者可用混合支付等等。

作为本实施例中的优选，所述预设管控维度至少包括如下之一：用车运力限制维度、用车服务限制维度、用车车型限制维度、用车单价限制维度、用车预算限制维度、用车次数限制维度、用车时间限制维度、用车地点限制维度、用车城市限制维度、用车跨城打车限制维度，所述第一管控维度、所述第二管控维度以及第三管控维度采用所述预设管控维度中的至少一种或多种，不同的所述用车场景配置多个所述用车差标，且每个所述用车差表关联所述用户的类型。

如图3所示，用车场景下可包含一套或多套用车差标，每套用车差标均关联某个用户职级。基于运力限制、服务限制、车型限制、单价限制、预算限制、次数限制、时间限制、地点限制、城市限制、跨城打车限制的考量，将所述预设管控维度配置为用车运力限制维度、用车服务限制维度、用车车型限制维度、用车单价限制维度、用车预算限制维度、用车次数限制维度、用车时间限制维度、用车地点限制维度、用车城市限制维度、用车跨城打车限制维度。

具体实施时，用车运力限制维度，可限制用户使用或禁用包含运力在内的等100多个运力服务商，包括但不限于：滴滴出行、T3出行、阳光出行、曹操出行、享道出行、神州出行、美团出行等。

用车服务限制，可限制或不限用户在如下情况下用车：立即用车、预约用车、接送机、接送站。

用车车型限制，可限制或不限用户选择如下车型：经济型、舒适型、商务型、豪华型、出租车。

用车单价限制，可按如下规则限制或不限用户的叫车价格：不限，按车型限制用户选择不同车型时的每公里最高均价、每单最高车费，按城市限制用户的每单最高车费。

用车预算限制，可按如下规则限制或不限用车一定期限内的叫车费用：

·不限

·按日限制不超过aa元

·按周限制不超过aa元

·按月限制不超过aa元

·按年限制不超过aa元。

用车次数限制，可按如下规则限制或不限用车一定期限内的叫车次数

·不限

·按日限制不超过bb次

·按周限制不超过bb次

·按月限制不超过bb次

·按年限制不超过bb次。

用车时间限制，可按如下规则限制或不限用户的用车时间段：

·不限

·按周限制用户在每周的哪些日期、哪些时间段能够用车

·按月限制用户在每周的哪些日期、哪些时间段能够用车

·按工作日/非工作日限制用户在哪些时间段能够用车。

用车地点限制，可按如下规则限制或不限用户的用车地点：

·不限

·限制用户只能选择某些地点作为出发地叫车

·限制用户只能选择某些地点作为目的地叫车

·限制用户出发地和目的地同时属于某个范围内时才能叫车

·限制用户出发地和目的地任一属于某个范围内时才能叫车。

用车城市限制，可按如下规则限制或不限用户的用车城市：

·不限

·限制用户只允许在某些城市才能叫车

·限制用户只能在除某些城市外的其他城市才能叫车。

跨城打车限制，可按如下规则限制或不限用户的用车跨城打车：

不限：可任意跨区县和城市

仅可跨区：同地级市下可跨区、不能跨县，不可跨地级市

仅可跨区县：同地级市下可跨区或县，不可跨地级市

可跨市：同地级市下可跨区或县、可跨地级市，不可跨省。

作为本实施例中的优选，所述按照所述用车差标中的预设管控维度在所述用车场景为用户用车后时，对用户进行第三管控维度的管控，包括：所述预设管控维度包括用车差标超标或者用车差标未超标的情况，当用车差标超标的情况下，按照超标时无需审批、超标时需要审批、超标时可选审批中的不同分类按照第二预设支付方式进行付款或报销审批，其中所述第二预设支付方式至少包括企业支付、用户个人支付、用户和企业混合支付中的任一一种或多种；当用车差标未超标的情况下，按照第一预设支付方式进行付款，其中所述第一预设支付方式包括企业支付。

具体实施时，基于前述的用车差标规则各个管控维度的具体内容，可管控当用户叫车行为超出规则(即超标)时的具体可用支付方式及审批流程，具体如下：

超标时无需审批：

只需填写超标原因无需审/只能个人支付，无需审批/只能个人支付或金额超标时部分个人自付，无需审批。

超标时需要审批：

可企业支付或个人支付，但都需要审批/只能个人支付，需要审批/只能个人支付或金额超标部分个人自付，需要审批。

超标时可选审批：

企业支付需要审批，个人支付无需审批/企业支付需要审批，个人支付或金额超标部分个人自付无需审批企业支付或金额超标部分个人自付需要审批，个人支付无需审批。

作为本实施例中的优选，所述方法还包括：通过用户端的用车首页，展示所述用户在用车场景中在用车差标超标的限制情况或者用车差标未超标的情况下对应的所述用车差标；通过所述用户端的预估价查看页面，展示所述用户在用车场景中在用车差标超标的限制情况或者用车差标未超标的情况下对应的所述用车差标；通过所述用户端的订单确认页面，展示所述用户在用车场景中在用车差标超标的限制情况或者用车差标未超标的情况下对应的所述用车差标。

具体实施时，通过用户端的配置用车场景以及用车差标规则。对于用车场景以及用车差标规则均可以通过列表配置，且可进行新增以及编辑。

用车首页及首页的差旅标准展示，通过用户端的用车首页，展示所述用户在用车场景中在用车差标超标的限制情况或者用车差标未超标的情况下对应的所述用车差标

预估价查看页及差旅标准展示，通过所述用户端的预估价查看页面，展示所述用户在用车场景中在用车差标超标的限制情况或者用车差标未超标的情况下对应的所述用车差标

订单确认页及差旅标准展示，通过所述用户端的订单确认页面，展示所述用户在用车场景中在用车差标超标的限制情况或者用车差标未超标的情况下对应的所述用车差标。

作为本实施例中的优选，所述方法还包括：在服务端维护多张与所述预设管控维度对应的数据库表结构，用于保存用车差标信息以及用车场景信息。

在服务端维护多张与所述预设管控维度对应的数据库表结构，用于保存用车差标信息以及用车场景信息，所述用车差标信息中的表结构包括主表、允许或禁止的用车承运商表结构、允许的用车服务类型表结构、允许的用车车型表结构、按车型限制单价时的车型单价详细限制规则表结构、允许的用车时间-按周限制表结构、允许的用车时间-按工作日/节假日模式限制表结构、允许的用车时间-按照月限制表结构、允许的用车POI位置表结构、允许或禁止的用车城市表结构中的任一一种或多种。

为了在用户端实现上述用车差标管控，还需要在服务端维护多张与所述预设管控维度对应的数据库表结构，用于保存用车差标信息以及用车场景信息。

示例性地，所述用车差标信息包括：

主键-自增长ID；

用车差标-编码；

用车差标-关联的用车场景编码；

用车差标-关联的职级id；

用车差标-关联的职级名称；

用车差标-该差标对应的职级是否为默认职级；

用车运力限制类型；

是否限制用车车型；

是否限制用车服务类型；

用车单价限制类型；

用车预算限制类型；

用车预算限制值(元)；

用车预算限制值或类型的更新时间；

用车差标-用车次数限制方式；

用车差标-用车次数限制的值；

用车差标-用车次数限制方式更新时间；

用车时间限制类型；

用车差标-下车地点变更限制方式；

用车差标-下车地点变更限制-可以更改且与原计划下车点距离不得超过多远距离；

用车差标-用车事由填写方式限制类型；

用车差标-用车地点限制方式；

用车城市限制类型；

跨城打车限制类型；

用车差标-重新叫车时的价格限制方式；

用车差标-重新叫车时的价格限制的金额；

用车差标-重新叫车时的价格限制的百分比；

用车差标-实际下车地点与计划下车地点允许的最大直线距离；

用车运力限制类型-是否隐藏超标项对用户不可见,0-否(默认),1-是；

用车服务限制类型-是否隐藏超标项对用户不可见,0-否(默认),1-是；

用车车型限制类型-是否隐藏超标项对用户不可见,0-否(默认),1-是；

用车单价限制类型-是否隐藏超标项对用户不可见,0-否(默认),1-是；

用车预算限制类型-是否隐藏超标项对用户不可见,0-否(默认),1-是；

用车差标-乘车超标时的处理方式(0-填写超标原因但无需审批,1-支付需要审批,2-企业支付需审批个人支付无需审批,3-只能个人支付无需审批,4-只能个人支付且需要审批)；

行记录创建时间；

行记录创建者用户ID；

行记录最后修改时间；

行记录最后修改者用户ID。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

根据本申请实施例，还提供了一种用于实施上述方法的用车场景中用车差标管控装置200，如图2所示，该装置包括：

确定模块210，用于确定用户的类型；

管控模块220，用于根据所述用户的类型，按照所述用车差标中的预设管控维度对用户进行管控，以使所述用户在用车场景中在用车差标超标的限制情况或者用车差标未超标的情况使用叫车服务。

本申请实施例中的确定模块210中由于用户的类型直接影响到了用车场景中用车差标管控，所以需要首先确定出用户的类型。可以理解，不同人员/角色/岗位/职级在企业用车消费场景下不同消费维度的用量和限制。

确定用户的类型后，可管控不同的角色、人员或者职级，并可应用于一个或多个不同的人员角色/职级，基于此以实现多不同角色/职级/岗位、不同人员差异化的差标管控规则和逻辑。

需要注意的是，所述“用车消费场景”指的是企业员工在不同情况下的用车情况分类，例如加班打车、出差用车、周末打车、因私出行，均为不同的用车场景。

同时对于一个企业可以配置一个或多个用车场景，且一个用车场景下可包含一套或多套用车差标规则。

作为本实施例中的优选，所述确定用户的类型，包括：不同的用户角色、用户人员或者用户职级，所述用车场景，包括：加班打车、出差用车、周末打车或者因私出行在不同情况下的用车情况分类。

本申请实施例中的管控模块220中企业用车整体消费场景可具体拆分为多个流程环节，包括用车前(用车打开APP选择用车场景、选择用车运力和价格项等步骤)、用车服务中(用户下单后、乘坐于车上时以及到达目的地这个过程)、用车服务后(用车享受完用车服务到达目的地之后)。基于这套用车差标规则可管控用车前用户可用哪些运力/服务类型/价格项。

需要注意的是，所述“用车差标”，指的是某个用车场景下某个用户/职级具体应遵循哪些限制才能使用叫车服务的一系列管控规则的集合。用车差标中多种管控维度，在本申请的实施例中并不进行具体限定，可以根据实际情况进行增减。

如果按照预设管控维度对用户进行管控时，所述用户在用车场景中在用车差标超标的限制情况使用叫车服务。

如果按照预设管控维度对用户进行管控时，所述用户也可以在用车场景中在用车差标未超标的情况使用叫车服务。

并且，对于用户而言可以通过用户端显示的提示信息进行叫车服务的确认。无论是用车差标未超标或用车差标超标可以按照预设管控规则进行管控，从而便于之后的打车报销等环节。

显然，本领域的技术人员应该明白，上述的本申请的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请不限制于任何特定的硬件和软件结合。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种用车场景中用车差标管控方法，其特征在于，包括：

确定用户的类型；

根据所述用户的类型，按照所述用车差标中的预设管控维度对用户进行管控，以使所述用户在用车场景中在用车差标超标的限制情况或者用车差标未超标的情况使用叫车服务。

2.根据权利要求1所述的方法，其特征在于，所述用车场景至少包括如下之一：用车服务前，用车服务中、用车服务后，所述方法还包括：

按照所述用车差标中的预设管控维度在所述用车场景为用户用车服务前，对用户进行第一管控维度的管控；

和/或，

按照所述用车差标中的预设管控维度在所述用车场景为用户用车服务中，对用户进行第二管控维度的管控；

和/或，

按照所述用车差标中的预设管控维度在所述用车场景为用户用车后，对用户进行第三管控维度的管控，

其中所述第一管控维度用于在用户用车前校验、所述第二管控维度用于在用户用车服务中校验以及第三管控维度用于在用户用车后校验，且均不相同。

3.根据权利要求2所述的方法，其特征在于，所述预设管控维度至少包括如下之一：用车运力限制维度、用车服务限制维度、用车车型限制维度、用车单价限制维度、用车预算限制维度、用车次数限制维度、用车时间限制维度、用车地点限制维度、用车城市限制维度、用车跨城打车限制维度；

所述第一管控维度、所述第二管控维度以及第三管控维度采用所述预设管控维度中的至少一种或多种；不同的所述用车场景配置多个所述用车差标，且每个所述用车差表关联所述用户的类型。

4.根据权利要求2所述的方法，其特征在于，所述按照所述用车差标中的预设管控维度在所述用车场景为用户用车后时，对用户进行第三管控维度的管控，包括：

所述预设管控维度包括用车差标超标或者用车差标未超标的情况，当用车差标超标的情况下，按照超标时无需审批、超标时需要审批、超标时可选审批中的不同分类按照第二预设支付方式进行付款或报销审批，其中所述第二预设支付方式至少包括企业支付、用户个人支付、用户和企业混合支付中的任一一种或多种；

当用车差标未超标的情况下，按照第一预设支付方式进行付款，其中所述第一预设支付方式包括企业支付。

5.根据权利要求1所述的方法，其特征在于，所述确定用户的类型，包括：确定不同的用户角色、用户人员或者用户职级。

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

通过用户端的用车首页，展示所述用户在用车场景中在用车差标超标的限制情况或者用车差标未超标的情况下对应的所述用车差标；

通过所述用户端的预估价查看页面，展示所述用户在用车场景中在用车差标超标的限制情况或者用车差标未超标的情况下对应的所述用车差标；

通过所述用户端的订单确认页面，展示所述用户在用车场景中在用车差标超标的限制情况或者用车差标未超标的情况下对应的所述用车差标。

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

在服务端维护多张与所述预设管控维度对应的数据库表结构，用于保存用车差标信息以及用车场景信息。

8.一种用车场景中用车差标管控装置，其特征在于，包括：

确定模块，用于确定用户的类型；

管控模块，用于根据所述用户的类型，按照所述用车差标中的预设管控维度对用户进行管控，以使所述用户在用车场景中在用车差标超标的限制情况或者用车差标未超标的情况使用叫车服务。

9.一种电子设备，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行所述权利要求1～7之任一所述方法。

10.一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行所述权利要求1～7之任一所述方法。

Images