CN114399305A - 一种车辆多账户扣费方法、装置、设备及存储介质 - Google Patents

Abstract

本发明公开了一种车辆多账户扣费方法、装置、设备及存储介质，涉及人工智能技术领域，适用于金融信息服务技术领域，例如银行等应用场景。方法包括，接收ETC账户的扣费请求；根据ETC账户的扣费请求中的扣费金额，从所述ETC账户对应的第一扣款服务器中进行扣费；当从所述第一扣款服务器中扣费失败时，根据所述第一扣款服务器的特征、所述扣费金额以及所述ETC账户对应的第二扣款服务器，从所述第一扣款服务器或所述第二扣款服务器中进行扣费，其中每个所述第二扣款服务器对应多个所述第一扣款服务器。本发明实现了对公ETC账户下的多个具有对应关系的扣款账户的扣费，解决了现有技术中不支持对公ETC账户下的多账户进行扣费的问题。

Description

一种车辆多账户扣费方法、装置、设备及存储介质

技术领域

本发明涉及人工智能技术领域，适用于金融信息服务技术领域，例如银行等应用场景，尤其涉及一种车辆多账户扣费方法、装置、设备及存储介质。

背景技术

现有技术中，电子不停车收费(Electronic Toll Collection，ETC)***的所针对的都是一辆车辆，一张ETC卡和一个银行，当设置有ETC设备的车辆通过收费站点时，可以通过ETC所绑定的银行账户进行费用的自动扣除。

在现有的ETC扣款方式中，从与ETC账户签约的银行账户进行扣款，ETC扣费场景有很多，最简单的是对私贷记卡，直接从与ETC账户绑定的银行账户中扣款，对私贷记卡的种类为借记卡，由于借记卡本身没有透支额度，为了保证ETC账户扣款成功并避免银行的垫款，需要对对私贷记卡进行资金冻结。对私ETC账户可以直接对扣款账户进行资金冻结，但对公ETC账户可能绑定了多张银行卡，因此将对公ETC账户下的所有银行卡都进行资金冻结将降低用户的使用便利性。且为了方便对资金进行管理，企业往往采用专款专用制度，即同一银行账户仅负责一项业务的支出，因此多个对公ETC账户需要从同一银行账户中扣费。面对复杂的ETC扣费场景，现有的ETC扣费过程中缺少对公ETC账户下的多账户扣费方法。

现在亟需一种车辆多账户扣费方法，从而解决现有技术不支持对公ETC账户下的多账户进行扣费的问题。

发明内容

为解决现有技术不支持对公ETC账户下的多账户进行扣费的问题，本发明实施例提供了一种车辆多账户扣费方法、装置、设备及存储介质，实现了对公ETC账户下的多个账户的扣费。

为了解决上述技术问题，本发明的具体技术方案如下：

一方面，本发明实施例提供了一种车辆多账户扣费方法，包括，

接收ETC账户的扣费请求；

根据所述ETC账户的扣费请求中的扣费金额，从所述ETC账户对应的第一扣款服务器中进行扣费；

当从所述第一扣款服务器中扣费失败时，根据所述第一扣款服务器的特征、所述扣费金额以及所述ETC账户对应的第二扣款服务器，从所述第一扣款服务器或所述第二扣款服务器中进行扣费，其中每个所述第二扣款服务器对应多个所述第一扣款服务器。

进一步地，所述第一扣款服务器的特征包括所述第一扣款服务器的余额；

根据所述ETC账户对应的第二扣款服务器以及所述第一扣款服务器的特征对所述扣费金额进行扣费进一步包括，

根据所述扣费金额和/或所述第一扣款服务器的余额确定充值金额；

根据所述充值金额从所述第二扣款服务器向所述第一扣款服务器进行充值；

充值完成后，从所述第一扣款服务器中进行所述扣费金额的扣费。

进一步地，根据所述充值金额从所述第二扣款服务器向所述第一扣款服务器进行充值进一步包括，

根据所述第二扣款服务器的最大充值金额向所述第一扣款服务器中进行充值。

进一步地，所述第一扣款服务器的特征包括所述第一扣款服务器的历史扣费数据；

所述方法还包括，

根据所述第一扣款服务器的历史扣费数据以及历史充值数据构建所述ETC账户的消费模型；

根据所述消费模型处理所述ETC账户的扣费请求。

进一步地，所述消费模型包括所述第一扣款服务器的预定充值金额和充值时间；

根据所述消费模型处理所述ETC账户的扣费请求之前，所述方法还包括，根据所述预定充值金额和所述充值时间从所述第二扣款服务器向所述第一扣款服务器进行充值。

进一步地，根据所述消费模型处理所述ETC账户的扣费请求进一步包括，

当根据所述扣费金额和/或所述第一扣款服务器的余额确定充值金额后，根据所述充值金额、所述ETC账户的扣费请求的时间以及所述ETC账户的消费模型对所述充值金额进行合理性验证，根据所述合理性验证的结果对所述第一扣款服务器进行充值。

进一步地，根据所述充值金额、所述ETC账户的扣费请求的时间以及所述ETC账户的消费模型对所述充值金额进行合理性验证进一步包括，

根据所述ETC账户的扣费请求的时间以及所述ETC账户的消费模型计算预测充值金额；

根据所述预测充值金额对所述充值金额进行合理性验证。

进一步地，当根据所述预测充值金额对所述充值金额进行合理性验证的验证结果为不通过时，所述方法还包括，

接收所述第二扣款服务器的充值请求；

根据所述充值请求中的充值金额从所述第二扣款服务器向所述第一扣款服务器进行充值。

进一步地，当根据所述第一扣款服务器的特征、所述扣费金额以及所述ETC账户对应的第二扣款服务器，从所述第一扣款服务器或所述第二扣款服务器中进行扣费失败时，所述方法还包括，根据所述ETC账户对应的第三扣款服务器对所述扣费金额进行扣费。

进一步地，根据所述ETC账户对应的第三扣款服务器对所述扣费金额进行扣费进一步包括，根据所述第三扣款服务器的最大扣费金额从所述第三扣款服务器中进行所述扣费金额的扣费。

进一步地，所述第一扣款服务器包括多个子扣款服务器；

根据所述ETC账户的扣费请求中的扣费金额，从所述ETC账户对应的第一扣款服务器中进行扣费进一步包括，

根据所述扣费金额以及各子扣款服务器的扣费优先级或扣费比例进行扣费。

另一方面，本发明实施例还提供了一种车辆多账户扣费装置，包括，

扣费请求接收单元，用于接收ETC账户的扣费请求；

第一扣费单元，用于根据所述ETC账户的扣费请求中的扣费金额，从所述ETC账户对应的第一扣款服务器中进行扣费；

第二扣费单元，用于当从所述第一扣款服务器中扣费失败时，根据所述第一扣款服务器的特征、所述扣费金额以及所述ETC账户对应的第二扣款服务器，从所述第一扣款服务器或所述第二扣款服务器中进行扣费，其中每个所述第二扣款服务器对应多个所述第一扣款服务器。

另一方面，本发明实施例还提供了一种计算机设备，包括存储器、处理器、以及存储在存储器上的计算机程序，处理器执行所述计算机程序时实现上述的方法。

另一方面，本发明实施例还提供了一种计算机存储介质，其上存储有计算机程序，计算机程序被计算机设备的处理器运行时，执行上述的方法。

最后，本发明还提供一种计算机程序产品，所述计算机程序产品被计算机设备的处理器运行时，执行根据上述所述方法的指令。

利用本发明实施例，将存在对应关系的第一扣款服务器和第二扣款服务器绑定在同一个对公ETC账户下，当根据第一扣款服务器对ETC账户的扣费请求中的扣费金额扣费失败时，根据与第一扣款服务器存在对应关系的第二扣款服务器以及第一扣款服务器的特征对扣费金额进行扣费，其中第一扣款服务器和第二扣款服务器可以分别对应不同的账户，实现了当从第一扣款服务器中扣费失败时，根据第一扣款服务器的特征设定与第一付款服务器存在对应关系的第二扣款服务器的扣费金额，从而实现了对公ETC账户下的多个具有对应关系的扣款账户的扣费，解决了现有技术中不支持对公ETC账户下的多账户进行扣费的问题。

附图说明

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

图1所示为本发明实施例一种车辆多账户扣费方法实施***示意图；

图2所示为本发明实施例一种车辆多账户扣费方法的流程图；

图3所示为本发明实施例根据第一扣款服务器的特征、扣费金额以及ETC账户对应的第二扣款服务器，从第一扣款服务器或第二扣款服务器中进行扣费的过程；

图4所示为本发明实施例对充值金额进行合理性验证的过程；

图5所示为本发明实施例一种车辆多账户扣费装置的结构示意图；

图6所示为本发明实施例计算机设备的结构示意图。

【附图标记说明】：

101、扣款终端；

102、扣款服务器；

501、扣费请求接收单元；

502、第一扣费单元；

503、第二扣费单元；

601、计算机设备；

602、处理器；

603、存储器；

604、驱动机构；

605、输入/输出模块；

606、输入设备；

607、输出设备；

608、呈现设备；

609、图形用户接口；

610、网络接口；

611、通信链路；

612、通信总线。

具体实施方式

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

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

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

本申请技术方案中对数据的获取、存储、使用、处理等均符合相关法律法规的相关规定。

如图1所示为本发明实施例一种车辆多账户扣费方法实施***示意图，可以包括扣款终端101和扣款服务器102，所述扣款终端101与所述扣款服务器102之间建立通信连接，能够实现数据的交互。所述扣款终端101可以向所述扣款服务器102发送ETC账户的扣费请求，所述ETC账户的扣费请求中可以包括扣费金额。

在本发明实施例所述的车辆多账户扣费方法的实施环境中，对公ETC账户为公司所有，公司名下的每一公务车辆均配置一个ETC账户，可以为各公务车辆的ETC账户关联一个或多个扣款账户、充值账户，还可以配置一个备付金账户，可以根据公司对公务车辆的业务范围配置一个或多个扣款账户，例如，公务车辆1为部门A专用，则可以将部门A的交通费账户A关联在该公务车辆1的ETC账户1下。在本发明实施例的应用场景中，将部门A的交通费账户A部署在第一扣款服务器中，以从第一扣款服务器中的部门A的交通费账户A进行ETC账户1的扣费。此外，若公务车辆2为部门B、部门C共同所有，则可以将部门B的交通费账户B和部门C的交通费账户C关联在该公务车辆2的ETC账户2下，在本发明实施例的应用场景中，将部门B的交通费账户B和部门C的交通费账户C均部署在第一扣款服务器中，以从第一扣款服务器中的部门B的交通费账户B和部门C的交通费账户C进行ETC账户2的扣费。

在本发明实施例的应用场景中，也可以根据公司的财务规定为该公司名下的多个公务车辆的ETC账户关联一个公司专用交通费账户，该公司各部门的交通费账户可以为零余额账户，即仅为了记录哪个部门的公务车辆产生了交通费以及该交通费的具体金额，例如，在该应用场景下，部门A的交通费账户A、部门B的交通费账户B和部门C的交通费账户C均为零余额账户，公司专用交通费账户M分别关联在公务车辆1的ETC账户1、公务车辆2的ETC账户2下，即将公司专用交通费账户M部署在第二扣款服务器中，以当从第一扣款服务器中的部门A的交通费账户A进行ETC账户1的扣款或从第一扣款服务器中的部门B的交通费账户B和部门C的交通费账户C进行ETC账户2的扣款失败时，从第二扣款服务器中的公司专用交通费账户M进行ETC账户1和ETC账户2的扣款。

在本说明书实施例中，所述扣款服务器102中可以包括第一扣款服务器和第二扣款服务器，所述扣款服务器102可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式***，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(CDN,Content DeliveryNetwork)、以及大数据和人工智能平台等基础云计算服务的云服务器。

需要说明的是，图1所示的仅仅是本发明提供的一种应用环境，在实际应用中，还可以包括其他应用环境，在本发明实施例中不做限制。

为了解决现有技术中不支持对公ETC账户下的多账户进行扣费的问题，本发明实施例提供了一种车辆多账户扣费方法，实现了对公ETC账户下的多个账户的扣费。图2所示为本发明实施例一种车辆多账户扣费方法的流程图，在本图中描述车辆的对公ETC账户下多账户扣费的过程，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的***或装置产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行。具体地，如图2所示，所述方法可以包括：

步骤201：接收ETC账户的扣费请求；

步骤202：根据所述ETC账户的扣费请求中的扣费金额，从所述ETC账户对应的第一扣款服务器中进行扣费；

步骤203：当从所述第一扣款服务器中扣费失败时，根据所述第一扣款服务器的特征、所述扣费金额以及所述ETC账户对应的第二扣款服务器，从所述第一扣款服务器或所述第二扣款服务器中进行扣费，其中每个所述第二扣款服务器对应多个所述第一扣款服务器。

通过本发明实施例的方法，将存在对应关系的第一扣款服务器和第二扣款服务器绑定在同一个对公ETC账户下，当根据第一扣款服务器对ETC账户的扣费请求中的扣费金额扣费失败时，根据与第一扣款服务器存在对应关系的第二扣款服务器以及第一扣款服务器的特征对扣费金额进行扣费，其中第一扣款服务器和第二扣款服务器可以分别对应不同的账户，实现了当从第一扣款服务器中扣费失败时，根据第一扣款服务器的特征设定与第一付款服务器存在对应关系的第二扣款服务器的扣费金额，从而实现了对公ETC账户下的多个具有对应关系的扣款账户的扣费，解决了现有技术中不支持对公ETC账户下的多账户进行扣费的问题。

可以理解为，本发明实施例所述的第一扣款服务器中包括公司部门的交通费账户，可以根据公司的财务制度，向部门的交通费账户中存入一定金额的交通费，以使公司各部门对自己的公务车辆的ETC消费进行管理。本发明实施例所述的第二扣款服务器中可以包括公司专用交通费账户，当部门的公务车辆的ETC账户产生的交通费超过该部门的交通费账户的余额时，根据公司专用交通费账户和该部门的交通费账户的特征对该部门的公务车辆的ETC账户产生的交通费进行支付。

在本发明实施例中，所述第一扣款服务器的特征可以包括第一扣款服务器的余额、扣费次数、每次扣费的扣费金额等，实现了根据第一扣款服务器的特征设定与第一付款服务器存在对应级关系的第二扣款服务器的扣费金额，所述第一扣款服务器和所述第二扣款服务器的对应关系可以为本文实施例所述的应用场景中公司通行费账户和部门通行费账户之间的上下级关系，多个部门的通行费账户对应一个公司的通行费账户，从而实现了对公ETC账户下的多个具有上下级关系的扣款账户的扣费。在本发明实施例中所述的第一扣款服务器和第二扣款服务器之间的对应关系可以表示公司部门之间的财务层级关系，例如，业务部门的财务隶属于公司财务部的管辖，因此第一扣款服务器包括业务部门的交通费账户，第二扣款服务器包括财务部的总账户。通过本发明实施例所述的车辆多账户扣费方法，实现了对公ETC账户下的多账户扣费，提升了公司财务管理的便利性。

需要说明的是，同一ETC账户还可以对应多个第二扣款服务器，根据预先设定的扣费规则在所述多个第二扣款服务器中指定一个第二扣款服务器，从而根据所述第一扣款服务器的特征、所述扣费金额以及指定的第二扣款服务器，从所述第一扣款服务器或所述指定的第二扣款服务器中进行扣费。例如，公司可以在同一家银行办理多个通行费账户，一个第二扣款服务器中包括一个所述通行费账户，然后根据公司指定的通行费账户确定所述指定的第二扣款服务器(即指定的通行费账户)。

在本文的一些其他实施例中，当从所述第一扣款服务器中扣费失败时，还可以根据所述第一扣款服务器的特征、所述扣费金额以及所述ETC账户对应的第二扣款服务器，从所述第二扣款服务器中进行扣费，从而适应公司不同的财务规定。

根据本发明的一个实施例，步骤203所述的第一扣款服务器的特征包括所述第一扣款服务器的余额；

如图3所示，根据所述第一扣款服务器的特征、所述扣费金额以及所述ETC账户对应的第二扣款服务器，从所述第一扣款服务器或所述第二扣款服务器中进行扣费进一步包括，

步骤301：根据所述扣费金额和/或所述第一扣款服务器的余额确定充值金额；

步骤302：根据所述充值金额从所述第二扣款服务器向所述第一扣款服务器进行充值；

步骤303：充值完成后，从所述第一扣款服务器中进行所述扣费金额的扣费。

在本发明实施例中，充值金额可以根据ETC账户的扣费请求中的扣费金额确定。例如，充值金额与扣费金额相同，可以理解为，在该情况下，第一扣款服务器中的扣款账户可以为零余额账户，即仅为了记录ETC账户的扣费金额，以便于公司的财务核对。当充值金额根据ETC账户和第一扣款服务器的余额确定时，可以理解为，在该情况下，扣费金额超出部门的交通费账户的余额，需要公司的交通费账户对超出的部门的交通费账户进行拨款，即充值金额为扣费金额和第一扣款服务器的余额的差值。但充值金额根据第一扣款服务器的余额确定时，可以理解为，在该情况下，当部门的交通费账户的余额小于预设的最小金额时，通过公司的交通费账户向部门的交通费账户中进行充值。

当从第二扣款服务器向第一扣款服务器中充值完成后，从第一扣款服务器中进行扣费金额的扣费，可以理解为，第二扣款服务器中的公司交通费账户记录了哪个部门产生的ETC费用以及具体金额，以便于公司的财务核对。

在本发明实施例的应用场景中，公司的财务规定中可能包括对部门ETC费用的限制，因此，根据本发明的一个实施例，步骤302根据所述充值金额从所述第二扣款服务器向所述第一扣款服务器进行充值进一步包括，

根据所述第二扣款服务器的最大充值金额向所述第一扣款服务器中进行充值。

在本发明实施例中，可以预先在第二扣款服务器中设置最大充值金额，当从第二扣款服务器向第一扣款服务器进行充值时，首先判断充值金额和第二扣款服务器的最大充值金额的大小，当充值金额大于第二扣款服务器设置的最大充值金额时，结束从第二扣款服务器向第一扣款服务器的充值。可以理解为，部门的ETC费用超出公司的规定，公司不再向部门的交通费账户中充值。

在本发明实施例的应用场景中，为了进一步便于公司对ETC费用的管理，根据本发明的一个实施例，步骤203所述的第一扣款服务器的特征还包括所述第一扣款服务器的历史扣费数据；

所述方法还包括，

根据所述第一扣款服务器的历史扣费数据以及历史充值数据构建所述ETC账户的消费模型；

根据所述消费模型处理所述ETC账户的扣费请求。

在本发明实施例中，第一扣款服务器的历史扣费数据中可以包括所述第一扣款服务器的历史扣费时间以及每次扣费的金额，然后根据第一扣款服务器的历史扣费时间、每次扣费的金额以及第一扣款服务器的历史充值数据构建ETC账户的消费模型，该消费模型中包括扣费时间、扣费金额和充值数据之间的关系，例如在指定的时间范围内(例如指定一个月内)，第一扣款服务器在哪些具体时间点发生了扣费，各时间点扣费的金额以及各时间点第二扣款服务器向第一扣款服务器的充值金额。最后根据消费模型处理ETC账户的扣费请求，提高了公司对ETC费用的管理便利性。

根据本发明的一个实施例，所述消费模型包括所述第一扣款服务器的预定充值金额和充值时间；

根据所述消费模型处理所述ETC账户的扣费请求之前，所述方法还包括，根据所述预定充值金额和所述充值时间从所述第二扣款服务器向所述第一扣款服务器进行充值。

在本发明实施例中，消费模型中还包括第一扣款服务器的预定充值金额和充值时间，该预定充值金额和充值时间可以根据第一扣款服务器的历史扣费数据和历史充值数据得到，例如，对第一扣款服务器中的历史扣费时间、各扣费时间的扣费金额以及各扣费时间的充值金额进行分析，判断在各扣费时间是否从第二扣款服务器向第一扣款服务器进行充值，若存在，则确定该充值金额的大小，表示在该扣费时间时，第一扣款服务器的余额小于ETC账户的扣费金额，且需要从第二扣款服务器向第一口扣款服务器充值该充值金额的资金，因此，为了便于公司对ETC费用的管理，可以在该时间之前，从第二扣款服务器向第一扣款服务器先进行充值，从而避免在该时间从第二扣款服务器向第一扣款服务器进行充值的不便。需要说明的是，本发明实施例所述的时间可以为一个时间点(例如每个工作日的固定时间点)，也可以为一个时间段(例如某个月内)。可以理解为，通过上述步骤，实现了对部门的ETC费用进行分析，得出部门的ETC费用超出公司财务规定的金额大小，然后预先从公司的交通费账户中向部门的交通费账户进行充值，提高了公司财务管理的便利性。

根据本发明的一个实施例，根据所述消费模型处理所述ETC账户的扣费请求进一步包括，

当根据所述扣费金额和/或所述第一扣款服务器的余额确定充值金额后，根据所述充值金额、所述ETC账户的扣费请求的时间以及所述ETC账户的消费模型对所述充值金额进行合理性验证，根据所述合理性验证的结果对所述第一扣款服务器进行充值。

在本发明实施例中，所述ETC账户的消费模型中还可以包括ETC账户的扣费规律，例如周期性扣费，即在指定周期内ETC账户扣费金额的浮动变化规律。因此，当根据扣费金额和/或第一扣款服务器的余额确定充值金额后，根据充值金额、ETC账户的扣费请求的时间以及ETC账户的周期性扣费规律判断该充值金额是否符合规律，若符合规律则从第二扣款服务器向第一扣款服务器中进行充值，若不符合规律，则停止从第二扣款服务器向第一扣款服务器的充值。例如，部门A的ETC账户的消费模型为：部门A在每年的2月至3月内，公务车辆产生的ETC费用较多，在该时间段内，每次进行ETC扣费时，都需要从第二扣款服务器(包括公司的交通费账户)向第一扣款服务器(包括部门A的交通费账户)进行充值，根据历史充值数据分析得到每次充值的充值金额在50元至100元，但除了每年的2月至3月，部门A的公务车辆产生的ETC费用较少，在该时间段内，每次进行ETC扣费时，都不需要从第二扣款服务器(包括公司的交通费账户)向第一扣款服务器(包括部门A的交通费账户)进行充值。若部门A的公务车辆在5月1日产生了一笔ETC费用，根据扣费金额和/或第一扣款服务器的余额确定充值金额为500元，因此根据充值金额500元、ETC账户的扣费请求的时间5月1日以及上述部门A的ETC账户的消费模型判断部门A的公务车辆在5月1日产生了一笔ETC费用不符合部门A的规律，即合理性验证结果为不通过，则停止从第二扣款服务器(包括公司的交通费账户)向第一扣款服务器(包括部门A的交通费账户)的充值。

通过上述步骤，实现了对“公车私用”情况下的ETC费用的监管，进一步提高了公司财务管理的便利性。

根据本发明的一个实施例，如图4所示，根据所述充值金额、所述ETC账户的扣费请求的时间以及所述ETC账户的消费模型对所述充值金额进行合理性验证进一步包括，

步骤401：根据所述ETC账户的扣费请求的时间以及所述ETC账户的消费模型计算预测充值金额；

步骤402：根据所述预测充值金额对所述充值金额进行合理性验证。

在本发明实施例中，ETC账户的消费模型还可以包括指定时间内第二扣款服务器向第一扣款服务器进行充值的充值金额大小，当根据所述扣费金额和/或所述第一扣款服务器的余额确定充值金额后，根据该ETC账户的扣费请求的时间以及上述消费模型计算该时间对应的预测充值金额，然后比较根据扣费金额和/或所述第一扣款服务器的余额确定的充值金额和预测充值金额的大小，若根据扣费金额和/或所述第一扣款服务器的余额确定的充值金额大于预测充值金额，则可以表示该ETC账户所属的公务车辆可能存在使用异常，则停止从第二扣款服务器向第一扣款服务器的充值。

需要说明的是，在本发明的一些其他实施例中，还预测充值金额还可以是充值金额的范围，例如ETC账户的消费模型包括指定时间内第二扣款服务器向第一扣款服务器进行充值的充值金额范围，当根据所述扣费金额和/或所述第一扣款服务器的余额确定充值金额后，根据该ETC账户的扣费请求的时间以及上述消费模型计算该时间对应的充值金额范围，然后比较根据扣费金额和/或所述第一扣款服务器的余额确定的充值金额和是否超出充值金额范围，若超出范围，则可以表示该ETC账户所属的公务车辆可能存在使用异常，则停止从第二扣款服务器向第一扣款服务器的充值。

在本发明的一些其他实施例中，若根据所述充值金额、所述ETC账户的扣费请求的时间以及所述ETC账户的消费模型对所述充值金额进行合理性验证结果为不通过时，例如，根据扣费金额和/或所述第一扣款服务器的余额确定的充值金额大于预测充值金额，或根据扣费金额和/或所述第一扣款服务器的余额确定的充值金额和超出充值金额范围，则还可能表示该ETC账户所属的公务车辆临时被公司的突发事务所调用，需要从公司的交通费账户中支付该ETC费用。针对上述情况，根据本发明的一个实施例，当根据所述预测充值金额对所述充值金额进行合理性验证的验证结果为不通过时，所述方法还包括，

接收所述第二扣款服务器的充值请求；

根据所述充值请求中的充值金额从所述第二扣款服务器向所述第一扣款服务器进行充值。

在本发明实施例中，第二扣款服务器的充值请求表示第二扣款服务器主动发起的向第一扣款服务器进行充值的请求，该充值请求中可以包括充值金额，然后根据第二扣款服务器的充值请求中的充值金额从第二扣款服务器向第一扣款服务器进行充值。可以理解为，经过公司的财务审批，从公司的交通费账户(第二扣款服务器)中向部门的交通费账户(第一扣款服务器)充值指定的充值金额，以通过部门的交通费账户完成ETC的扣费，其中，指定的充值金额可以从公司的财务审批结果中获取到。通过上述步骤，进一步提高了公司财务管理的便利性。

在本发明实施例的应用场景中，若ETC费用支付失败，则需要ETC账户的签约银行垫付ETC的扣费金额，为了减少银行的垫款，根据本发明的一个实施例，当根据所述第一扣款服务器的特征、所述扣费金额以及所述ETC账户对应的第二扣款服务器，从所述第一扣款服务器或所述第二扣款服务器中进行扣费失败时，所述方法还包括，根据所述ETC账户对应的第三扣款服务器对所述扣费金额进行扣费。

在本发明实施例中，所述第三扣款服务器可以包括公司在银行办理的备付金账户(即押金账户)，根据所述ETC账户对应的第二扣款服务器以及所述第一扣款服务器的特征对所述扣费金额进行扣费失败可以表示充值金额大于第二扣款服务器的最大充值金额或对充值金额的合理性验证不通过。当根据所述ETC账户对应的第二扣款服务器以及所述第一扣款服务器的特征对所述扣费金额进行扣费失败时，从ETC账户对应的包括公司在银行办理的备付金账户的第三扣款服务器中进行扣费，减少银行的垫款。

进一步地，根据本发明的一个实施例，根据所述ETC账户对应的第三扣款服务器对所述扣费金额进行扣费进一步包括，根据所述第三扣款服务器的最大扣费金额从所述第三扣款服务器中进行所述扣费金额的扣费。

在本发明实施例中，第三扣款服务器中还可以包括最大扣费金额，第三扣款服务器的最大扣费金额可以通过公司在银行的最小备付金金额以及公司的备付金总额得到，当ETC账户的扣费请求中的扣费金额大于第三扣款服务器的最大扣费金额时，则停止从第三扣款服务器中进行ETC的扣费。

在本发明的一些其他实施例中，还可以根据公司的财务规定，当从所述第一扣款服务器中扣费失败时，直接从第三扣款服务器中进行ETC扣费，从而减少银行的垫款。

在本发明实施例的应用场景中，同一ETC账户所属的公务车辆可以由多个部门共同所有，因此该ETC账户下需要包括多个部门的交通费账户，当该公务车辆产生ETC费用时，从各部门的交通费账户中进行ETC扣费。针对上述情况，根据本发明的一个实施例，所述第一扣款服务器包括多个子扣款服务器；

根据所述ETC账户的扣费请求中的扣费金额，从所述ETC账户对应的第一扣款服务器中进行扣费进一步包括，

根据所述扣费金额以及各子扣款服务器的扣费优先级或扣费比例进行扣费。

在本发明实施例中，第一扣款服务器包括的多个子扣款服务器中分别包括各部门的交通费账户，即子扣款服务器与部门的交通费账户一一对应，子扣款服务器的扣费优先级可以表示优先从哪个子扣款服务器中进行扣款，子扣款服务器的扣费比例可以表示按照一定比例从各子扣款服务器中进行ETC扣费。通过上述步骤，实现了对各部门共同所有的公务车辆的ETC扣费。

在本发明的一些其他实施例中，还可以将ETC扣费识失败的ETC账户列入黑名单，当对ETC账户的扣费请求中的扣费金额进行补缴之后，将该ETC账户从黑名单中删除，实现了对ETC扣费失败的ETC账户的管理。

需要说明的是，ETC扣费失败可以表示从第二扣款服务器向第一扣款服务器(例如包括部门的交通费账户)进行充值失败，例如充值金额大于第二扣款服务器(例如包括公司的交通费账户)的最大充值金额或对充值金额的合理性验证结果为不通过且未收到第二扣款服务器的充值请求，也可以表示从第三扣款服务器(例如包括公司在银行的备付金账户)进行扣费失败，例如ETC扣费金额大于第三扣款服务器的最大扣费金额。此外，由于第三扣款服务器包括的备付金账户为公司在银行的押金，因此当从第三扣款服务器中支付ETC费用后，也可以将该ETC账户拉入黑名单，当对备付金账户进行充值之后，从黑名单中将该ETC账户删除，便于银行对公司的备付金账户的管理，进一步地减少了银行的垫款。

基于同一发明构思，本发明实施例还提供了一种车辆多账户扣费装置，如图5所示，包括，

扣费请求接收单元501，用于接收ETC账户的扣费请求；

第一扣费单元502，用于根据所述ETC账户的扣费请求中的扣费金额，从所述ETC账户对应的第一扣款服务器中进行扣费；

第二扣费单元503，用于当从所述第一扣款服务器中扣费失败时，根据所述第一扣款服务器的特征、所述扣费金额以及所述ETC账户对应的第二扣款服务器，从所述第一扣款服务器或所述第二扣款服务器中进行扣费，其中每个所述第二扣款服务器对应多个所述第一扣款服务器。

通过上述装置所取得的有益效果与上述方法所取得的有益效果一致，本说明书实施例不做赘述。

如图6所示为本发明实施例计算机设备的结构示意图，本发明中装置可以为本实施例中的计算机设备，执行上述本发明的方法。计算机设备601可以包括一个或多个处理器602，诸如一个或多个中央处理单元(CPU)，每个处理单元可以实现一个或多个硬件线程。计算机设备601还可以包括任何存储器603，其用于存储诸如代码、设置、数据等之类的任何种类的信息。非限制性的，比如，存储器603可以包括以下任一项或多种组合：任何类型的RAM，任何类型的ROM，闪存设备，硬盘，光盘等。更一般地，任何存储器都可以使用任何技术来存储信息。进一步地，任何存储器可以提供信息的易失性或非易失性保留。进一步地，任何存储器可以表示计算机设备601的固定或可移除部件。在一种情况下，当处理器602执行被存储在任何存储器或存储器的组合中的相关联的指令时，计算机设备601可以执行相关联指令的任一操作。计算机设备601还包括用于与任何存储器交互的一个或多个驱动机构604，诸如硬盘驱动机构、光盘驱动机构等。

计算机设备601还可以包括输入/输出模块605(I/O)，其用于接收各种输入(经由输入设备606)和用于提供各种输出(经由输出设备607)。一个具体输出机构可以包括呈现设备608和相关联的图形用户接口(GUI)609。在其他实施例中，还可以不包括输入/输出模块605(I/O)、输入设备606以及输出设备607，仅作为网络中的一台计算机设备。计算机设备601还可以包括一个或多个网络接口610，其用于经由一个或多个通信链路611与其他设备交换数据。一个或多个通信总线612将上文所描述的部件耦合在一起。

通信链路611可以以任何方式实现，例如，通过局域网、广域网(例如，因特网)、点对点连接等、或其任何组合。通信链路611可以包括由任何协议或协议组合支配的硬连线链路、无线链路、路由器、网关功能、名称服务器等的任何组合。

对应于图2至图4中的方法，本发明实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述步骤。

本发明实施例还提供一种计算机可读指令，其中当处理器执行所述指令时，其中的程序使得处理器执行如图2至图4所示的方法。

本发明实施例还提供一种计算机程序产品，所述计算机程序产品被计算机设备的处理器运行时，执行根据如图2至图4所示的方法。

应理解，在本发明的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

还应理解，在本发明实施例中，术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系。例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本发明中字符“/”，一般表示前后关联对象是一种“或”的关系。

本领域普通技术人员可以意识到，结合本发明中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的***、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本发明所提供的几个实施例中，应该理解到，所揭露的***、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接，也可以是电的，机械的或其它的形式连接。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本发明实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本发明中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (15)

1.一种车辆多账户扣费方法，其特征在于，适用于对公ETC账户，所述方法包括，

接收ETC账户的扣费请求；

根据所述ETC账户的扣费请求中的扣费金额，从所述ETC账户对应的第一扣款服务器中进行扣费；

当从所述第一扣款服务器中扣费失败时，根据所述第一扣款服务器的特征、所述扣费金额以及所述ETC账户对应的第二扣款服务器，从所述第一扣款服务器或所述第二扣款服务器中进行扣费，其中每个所述第二扣款服务器对应多个所述第一扣款服务器。

2.根据权利要求1所述的车辆多账户扣费方法，其特征在于，所述第一扣款服务器的特征包括所述第一扣款服务器的余额；

根据所述第一扣款服务器的特征、所述扣费金额以及所述ETC账户对应的第二扣款服务器，从所述第一扣款服务器或所述第二扣款服务器中进行扣费进一步包括，

根据所述扣费金额和/或所述第一扣款服务器的余额确定充值金额；

根据所述充值金额从所述第二扣款服务器向所述第一扣款服务器进行充值；

充值完成后，从所述第一扣款服务器中进行所述扣费金额的扣费。

3.根据权利要求2所述的车辆多账户扣费方法，其特征在于，根据所述充值金额从所述第二扣款服务器向所述第一扣款服务器进行充值进一步包括，

根据所述第二扣款服务器的最大充值金额向所述第一扣款服务器中进行充值。

4.根据权利要求2所述的车辆多账户扣费方法，其特征在于，所述第一扣款服务器的特征包括所述第一扣款服务器的历史扣费数据；

所述方法还包括，

根据所述第一扣款服务器的历史扣费数据以及历史充值数据构建所述ETC账户的消费模型；

根据所述消费模型处理所述ETC账户的扣费请求。

5.根据权利要求4所述的车辆多账户扣费方法，其特征在于，所述消费模型包括所述第一扣款服务器的预定充值金额和充值时间；

根据所述消费模型处理所述ETC账户的扣费请求之前，所述方法还包括，根据所述预定充值金额和所述充值时间从所述第二扣款服务器向所述第一扣款服务器进行充值。

6.根据权利要求4所述的车辆多账户扣费方法，其特征在于，根据所述消费模型处理所述ETC账户的扣费请求进一步包括，

当根据所述扣费金额和/或所述第一扣款服务器的余额确定充值金额后，根据所述充值金额、所述ETC账户的扣费请求的时间以及所述ETC账户的消费模型对所述充值金额进行合理性验证，根据所述合理性验证的结果对所述第一扣款服务器进行充值。

7.根据权利要求6所述的车辆多账户扣费方法，其特征在于，根据所述充值金额、所述ETC账户的扣费请求的时间以及所述ETC账户的消费模型对所述充值金额进行合理性验证进一步包括，

根据所述ETC账户的扣费请求的时间以及所述ETC账户的消费模型计算预测充值金额；

根据所述预测充值金额对所述充值金额进行合理性验证。

8.根据权利要求7所述的车辆多账户扣费方法，其特征在于，当根据所述预测充值金额对所述充值金额进行合理性验证的验证结果为不通过时，所述方法还包括，

接收所述第二扣款服务器的充值请求；

根据所述充值请求中的充值金额从所述第二扣款服务器向所述第一扣款服务器进行充值。

9.根据权利要求1所述的车辆多账户扣费方法，其特征在于，当根据所述第一扣款服务器的特征、所述扣费金额以及所述ETC账户对应的第二扣款服务器，从所述第一扣款服务器或所述第二扣款服务器中进行扣费失败时，所述方法还包括，根据所述ETC账户对应的第三扣款服务器对所述扣费金额进行扣费。

10.根据权利要求9所述的车辆多账户扣费方法，其特征在于，根据所述ETC账户对应的第三扣款服务器对所述扣费金额进行扣费进一步包括，根据所述第三扣款服务器的最大扣费金额从所述第三扣款服务器中进行所述扣费金额的扣费。

11.根据权利要求1所述的车辆多账户扣费方法，其特征在于，所述第一扣款服务器包括多个子扣款服务器；

根据所述ETC账户的扣费请求中的扣费金额，从所述ETC账户对应的第一扣款服务器中进行扣费进一步包括，

根据所述扣费金额以及各子扣款服务器的扣费优先级或扣费比例进行扣费。

12.一种车辆多账户扣费装置，其特征在于，包括，

扣费请求接收单元，用于接收ETC账户的扣费请求；

第一扣费单元，用于根据所述ETC账户的扣费请求中的扣费金额，从所述ETC账户对应的第一扣款服务器中进行扣费；

第二扣费单元，用于当从所述第一扣款服务器中扣费失败时，根据所述第一扣款服务器的特征、所述扣费金额以及所述ETC账户对应的第二扣款服务器，从所述第一扣款服务器或所述第二扣款服务器中进行扣费，其中每个所述第二扣款服务器对应多个所述第一扣款服务器。

13.一种计算机设备，包括存储器、处理器、以及存储在所述存储器上的计算机程序，其特征在于，所述处理器执行所述计算机程序时，实现权利要求1至11任意一项所述的方法。

14.一种计算机存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被计算机设备的处理器运行时，执行权利要求1至11任意一项所述的方法。

15.一种计算机程序产品，其特征在于，所述计算机程序产品被计算机设备的处理器运行时，执行根据权利要求1至11任意一项所述方法的指令。

Images