CN108876578A - 打车报销方法、装置、计算机设备和存储介质 - Google Patents

Abstract

本申请揭示了一种打车报销方法、装置、计算机设备和存储介质，其中方法包括：接收员工输入的打车订单；判断所述打车订单的开始时间是否在预设的时间段内；若是，判定所述打车订单可报销；打车订单完成后，发送所述打车订单至财务端，用于所述财务端安排报销。本申请通过在打车软件中对员工因公或加班打车的地点、时间等进行限制，从而使得员工按照规定的方式进行打车。自动对符合规则的打车订单进行报销，既节省了员工报销打车费用的流程，也避免了员工私事打车进行报销。

Description

打车报销方法、装置、计算机设备和存储介质

技术领域

本申请涉及到计算机技术领域，特别是涉及到一种打车报销方法、装置、计算机设备和存储介质。

背景技术

公司的员工在上班时间因公事外出或者加班之后需要及时回家，一般需要进行打车，而员工是因为工作原因导致需要打车，因此对于打车产生的开销，公司会允许员工可以进行报销。为了保证报销的方便，一些较大的公司通过开发相应的打车软件来辅助员工进行报销，但是现有的打车软件没有对打车的地点、时间等进行限制，因此无法很好的管控员工行为，导致员工可以在任意打车(不是因公事打车)后都进行报销，因此如何提供一种能限制员工在任意打车之后进行报销的方法成为亟待解决的问题、浪费人力，因此如何提供一种能自动对打车产生的报销单进行报销的方法成为亟待解决的问题。

发明内容

本申请的主要目的为提供一种在预设时间段内打车就可以自动报销的打车报销方法、装置、计算机设备和存储介质。

为了实现上述发明目的，本申请提出一种打车报销方法，包括：

接收员工输入的打车订单；

判断所述打车订单的开始时间是否在预设的时间段内；

若是，判定所述打车订单可报销；

打车订单完成后，发送所述打车订单至财务端，用于所述财务端安排报销。

进一步地，所述判断所述打车订单的开始时间是否在预设的时间段内的步骤之前，包括：

判断所述打车订单的打车起点是否在预设的地域范围内；

若所述打车起点在预设的地域范围内，生成判断所述打车订单的开始时间是否在预设的时间段内的指令。

进一步地，所述判断所述打车订单的打车起点是否在预设的地域范围内的步骤之前，还包括：

根据所述员工的个人信息与地域范围的映射关系，获取所述员工对应的所述地域范围作为所述预设的地域范围。

进一步地，所述判断打车订单的打车起点是否在预设的地域范围内的步骤之后，包括：

若所述打车起点未在预设的地域范围内，则判断所述员工是否有出差申请单；

若所述员工具有出差申请单，则判断所述打车起点是否是所述出差申请单中的出差城市；

若所述打车起点位于所述出差城市，则生成判断所述打车订单的开始时间是否在预设的时间段内的指令。

进一步地，所述判断所述打车订单的开始时间是否在预设的时间段内的步骤之前，包括：

获取所述打车订单的网约车类型，所述网约车类型包括不同等级的网约车；

根据预设的职位等级与网约车类型的映射关系，获取所述员工对应的网约车类型范围；

判断所述打车订单的网约车类型是否属于所述员工对应的网约车类型范围；

若是，生成判断所述打车订单的开始时间是否是预设的时间段内的指令。

进一步地，所述判断所述打车订单的开始时间是否在预设的时间段内的步骤之后，还包括：

若否，显示可以报销打车费用的时间段。

进一步地，所述打车订单完成后，发送所述打车订单至财务端的步骤包括：

所述打车订单完成后，将所述打车订单添加可报销的标记；

定期发送具有可报销的标记的打车订单至所述财务端报销。

本申请还提供一种打车报销装置，包括：

接收模块，用于接收员工输入的打车订单；

判断模块，用于判断所述打车订单中的开始时间是否在预设的时间段内；

判定模块，用于若是，判定所述打车订单可报销；

发送模块，用于打车订单完成后，发送所述打车订单至财务端，用于所述财务端安排报销。

本申请还提供一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述任一项所述方法的步骤。

本申请还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任一项所述的方法的步骤。

本申请的打车报销方法、装置、计算机设备和存储介质，通过在打车软件中对员工因公或加班打车的地点、时间等进行限制，从而使得员工按照规定的方式进行打车。自动对符合规则的打车订单进行报销，既节省了员工报销打车费用的流程，也避免了员工私事打车进行报销。

附图说明

图1为本申请一实施例的打车报销方法的流程示意图；

图2为本申请一实施例的打车报销方法的流程示意图；

图3为本申请一实施例的打车报销方法的流程示意图；

图4为本申请一实施例的打车报销方法的流程示意图；

图5为本申请一实施例的上述打车报销方法中步骤S4的具体流程示意图；

图6为本申请一实施例的打车报销装置的结构示意框图；

图7为本申请一实施例的打车报销装置的结构示意框图；

图8为本申请一实施例的打车报销装置的结构示意框图；

图9为本申请一实施例的打车报销装置的结构示意框图；

图10为本申请一实施例的打车报销装置的发送模块的结构示意框图；

图11为本申请一实施例的计算机设备的结构示意框图。

本申请目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

参照图1，本申请实施例提供一种打车报销方法，包括步骤：

S1、接收员工输入的打车订单；

S2、判断所述打车订单的开始时间是否在预设的时间段内；

S3、若是，判定所述打车订单可报销；

S4、打车订单完成后，发送所述打车订单至财务端，用于所述财务端安排报销。

本申请中执行方法的主体为一个应用软件的服务器，如上述步骤S1所述，员工输入的打车订单所依赖的是一个终端中的应用软件(财酷APP)，上述终端可以为手机或者平板等可联网电子移动设备。当员工需要打车时，可以直接通过终端中的应用软件(财酷APP)来输入对应的乘车信息，形成打车订单，其中上述乘车信息包括起点位置、终点位置、打车类型信息以及员工信息。然后服务器接收到该打车订单。终端中的应用软件(财酷APP)需要登录相应的账号，每个员工都设置有相应的登录账号，便于员工进行登录。员工在使用应用软件(财酷APP)进行打车时，首先需要登录相应的账号，服务器将判断输入的账号信息是否有效，其中具体是将输入的账号信息与预存的所有员工账号信息进行匹配。当判断得到输入的账号信息有效时，将执行登录操作；在登录账号后，便于员工进行打车操作。而员工在注册账号的过程中，需要填写员工的一些个人信息，其中员工的个人信息包括部门、职位、姓名、工号以及性别等信息，其中具体的账号名称可以为员工的工号。

如上述步骤S2所述，预设的时间段是后台人员根据公司自身的营业状况设定的属于因公事而需要用车的时间段。后台人员将公司的工作时间段输入到奇酷APP对应的服务器；或者，后台工作人员将公司的工作时间段的链接输入到服务器中。打车订单中的开始时间是指打车订单中的行程开始的时间，需要说明的是，开始时间与订单时间是不一样的，例如A员工与客户约好星期三上午10点在客户公司见面，然后A员工星期二下午5点约顺风车，约星期三上午9点半从员工的公司出发，此时生成了一个打车订单，该打车订单的订单时间是星期二下午5点，而该订单的开始时间是星期三上午9点半。然后判断开始时间是不是在预设的时间段内，在判断时，先获取到预设的时间段的日期，比如预设的时间段是工作日的上午9点到下午6点，然后判断星期三是否是工作日，如果是，再判断上午9点半是否在在上午9点到下午6点之间。在另一具体实施例中，公司还规定加班到指定时间后可以打车回家；对应的预设的时间段还包括晚上9点到第二天早上6点。

如上述步骤S3所述，当打车订单的开始时间是在预设的时间段内，则说明员工的打车符合公司的要求，是属于因公事打车，该打车产生的费用由公司承担，因而判定该打车订单是可以报销的。

如上述步骤S4所述，打车订单完成，即员工使用了网约车到达目的地，支付了费用。服务器将打车订单发送给财务端，该打车订单中包含了员工的账户信息以及费用信息，便于财务端根据账户信息以及费用信息安排打款报销。

参照图2，在一个实施例中，上述判断所述打车订单的开始时间是否在预设的时间段内的步骤S2之前，包括：

S21、判断所述打车订单的打车起点是否在预设的地域范围内；

S22、若所述打车起点在预设的地域范围内，生成判断所述打车订单的开始时间是否在预设的时间段内的指令。

本实施例中，打车起点是指员工预约汽车时的起点位置。公司为了更准确的确定员工是因公而外出打车，对打车的起点均有设置。在一具体实施例中，设置起点位置的预设的地域范围是距离公司位置附近的一公里以内。服务器先获取预设的地域范围，然后获取到打车订单中的起点位置信息，判断该起点位置信息是否在地域范围内。如果打车订单中的起点位置是在预设的地域范围内，说明员工的打车符合公司的要求，是属于因公事打车，因而需要继续下一步的判断，生成用于判断打车时间是否在预设的时间段内的指令。

在一个实施例中，上述判断所述打车订单的打车起点是否在预设的地域范围内的步骤S21之前，还包括：

S211、根据所述员工的个人信息与地域范围的映射关系，获取所述员工对应的所述地域范围作为所述预设的地域范围。

本实施例中，员工的个人信息包括员工所在的部门、固定工作地点、职位级别。因每个员工的固定地点或者工作性质或者职位级别不一样，因此，每个员工因公用车的起点范围也是不一样的。服务器调用员工的账户信息，提取出其中的个人信息。后台工作人员根据各员工的工作性质以及职位等级等信息设置出每个员工的打车起点的范围，形成员工与打车起点的地域范围的映射关系。服务器调用出该映射关系，获取到该员工对应的地域范围作为上述预设的地域范围。例如，该员工是属于市场部的员工，经常需要外出陌生拜访客户，经常拜访完一个陌生客户后再去另一个陌生客户前往拜访，因而该员工的打车起点是其拓展市场的市场范围，比如是该公司所在的市辖区均是其地域范围。另一员工的等级级别较高，为部门主管级别，需要经常与其他部门或其他相关的机构进行交流，因此其打车的起点不受到限制。然后根据员工对应的地域范围来判断打车起点是否在该地域范围内。

在一个实施例中，上述判断打车订单的打车起点是否在预设的地域范围内的步骤S21之后，包括：

S23、若所述打车起点未在预设的地域范围内，则判断所述员工是否有出差申请单；

S24、若所述员工有出差申请单，则判断所述打车起点是否是所述出差申请单中的出差城市；

S25、若所述打车起点位于所述出差城市，则生成判断所述打车订单的开始时间是否在预设的时间段内的指令。

本实施例中，如果打车订单中的打车起点不在预设的地域范围内，服务器获取到员工的个人信息后，访问该员工账户的出差记录，即员工的出差申请单。出差申请单中包含有出差时间以及出差地点。服务器读取出差申请单，判断员工的出差申请单中的出差时间包含打车订单中的开始时间。因员工不在预设的地域范围内打车，也有可能是去外地出差引起的因公事而打车。服务器还读取出差申请单中的出差地点，即员工的出差城市，然后判断打车起点是不是在出差城市。如果打车起点是在出差申请单中的出差城市，说明员工确实是在出差的城市打车，进而判断是在因公出差。因而，需要继续下一步的判断，生成用于判断打车时间是否在预设的时间段内的指令。

参照图3，在一个实施例中，上述判断所述打车订单的开始时间是否在预设的时间段内的步骤之前，包括：

S26、获取所述打车订单的网约车类型，所述网约车类型包括不同等级的网约车；

S27、根据预设的职位等级与网约车类型的映射关系，获取所述员工对应的网约车类型范围；

S28、判断所述打车订单的网约车类型是否属于所述员工对应的网约车类型范围；

S29、若是，生成判断打车订单的开始时间是否是预设的时间段内的指令。

本实施例中，打车订单包括多个网约车类型，比如出租车、顺风车、快车、专车、豪华车等，其中，上述出租车也是指员工通过APP上约的网约车。服务器读取打车订单，读取网约车类型。网约车按照价格分成四个等级，低级的是顺风车，初级是出租车、快车，中级是专车，高级是豪华车。公司会为中高层员工提供更好的待遇，对应的设置了更优质的网约车类型的出行服务。职位等级越高，对应的网约车类型的范围更广，比如部门主管可以使用中级的专车类型的网约车以及中级以下类型的网约车，部门经理可以使用任意类型的订单。普通员工只可以使用低级和初级类型的如出租车、顺风车和快车类型的网约车。后台人员根据各职位等级对应的网约车类型设置了对应的映射关系。服务器根据员工的个人信息中的职位等级，调用该职位等级与网约车类型的映射关系后，获取到员工的可用网约车类型的范围，比如，获取到员工的等级是普通职员，则对应的网约车类型范围是出租车、顺风车和快车。然后判断订单中的网约车类型是否属于该员工对应的网约车类型范围，如果是的，则需要继续下一步的判断，生成用于判断打车订单的开始时间是否在预设的时间段内的指令。

参照图4，在一个实施例中，上述判断所述打车订单的开始时间是否在预设的时间段内的步骤S2之后，还包括：

S5、若否，显示可以报销打车费用的时间段。

如上述步骤S5所述，当判定打车订单不在预设的时间段内，则该订单不可报销。服务器弹出不可报销的信息提醒员工，避免员工因公用车而无法报销产生的费用问题，或者提醒员工使用该订单后再走其他程序进行报销。服务器还在员工的APP端显示预设的时间段，提醒员工还没有到可以报销打车费用的时间，有利于员工合理的安排出行时间。

参照图5，在一个实施例中，上述订单完成后，发送所述打车订单至财务端的步骤包括：

S41、打车订单完成后，将所述打车订单添加可报销的标记；

S42、定期发送具有可报销的标记的打车订单至财务端报销。

本实施例中，当打车订单完成，判定该打车订单是可以报销的后，将该订单添加可报销的标记。具体的添加方式是，服务器建立一个存储区，将判定为可报销的打车订单放置在该存储区。每隔一段时间，将存储区内的所有打车订单发送给财务端，便于财务端进行汇款报销事宜。定期的具体时间设置为一个月，与员工的工资同时发放，便于财务端批量审核，减小财务端的计算工作量。

综上所述，本申请的打车报销方法，通过在打车软件中对员工因公或加班打车的地点、时间等进行限制，从而使得员工按照规定的方式进行打车。自动对符合规则的打车订单进行报销，既节省了员工报销打车费用的流程，也避免了员工私事打车进行报销。

参照图6，本申请实施例中还提供一种打车报销装置，包括：

接收模块1，用于接收员工输入的打车订单；

判断模块2，用于判断所述打车订单中的开始时间是否在预设的时间段内；

判定模块3，用于若是，判定所述打车订单可报销；

发送模块4，用于打车订单完成后，发送所述打车订单至财务端，用于所述财务端安排报销。

本实施例中，打车报销装置为一个应用软件的服务器。员工输入的打车订单所依赖的是一个终端中的应用软件(财酷APP)，上述终端可以为手机或者平板等可联网电子移动设备。当员工需要打车时，可以直接通过终端中的应用软件(财酷APP)来输入对应的乘车信息，形成打车订单，其中上述乘车信息包括起点位置、终点位置、打车类型信息以及员工信息。然后服务器的接收模块1接收到该打车订单。终端中的应用软件(财酷APP)需要登录相应的账号，每个员工都设置有相应的登录账号，便于员工进行登录。员工在使用应用软件(财酷APP)进行打车时，首先需要登录相应的账号，服务器将判断输入的账号信息是否有效，其中具体是将输入的账号信息与预存的所有员工账号信息进行匹配。当判断得到输入的账号信息有效时，将执行登录操作；在登录账号后，便于员工进行打车操作。而员工在注册账号的过程中，需要填写员工的一些个人信息，其中员工的个人信息包括部门、职位、姓名、工号以及性别等信息，其中具体的账号名称可以为员工的工号。

判断模块2中的预设的时间段是后台人员根据公司自身的营业状况设定的属于因公事而需要用车的时间段。后台人员将公司的工作时间段输入到奇酷APP对应的服务器；或者，后台工作人员将公司的工作时间段的链接输入到服务器中。打车订单中的开始时间是指打车订单中的行程开始的时间，需要说明的是，开始时间与订单时间是不一样的，例如A员工与客户约好星期三上午10点在客户公司见面，然后A员工星期二下午5点约顺风车，约星期三上午9点半从员工的公司出发，此时生成了一个打车订单，该打车订单的订单时间是星期二下午5点，而该订单的开始时间是星期三上午9点半。然后判断模块2判断开始时间是不是在预设的时间段内，判断模块2在判断时，先获取到预设的时间段的日期，比如预设的时间段是工作日的上午9点到下午6点，然后判断模块2判断星期三是否是工作日，如果是，判断模块2再判断上午9点半是否在在上午9点到下午6点之间。在另一具体实施例中，公司还规定加班到指定时间后可以打车回家；对应的预设的时间段还包括晚上9点到第二天早上6点。

当打车订单的开始时间是在预设的时间段内，则说明员工的打车符合公司的要求，判定模块3判定该打车是属于因公事打车，该打车产生的费用由公司承担，因而判定模块3判定该打车订单是可以报销的。

打车订单完成，即员工使用了网约车到达目的地，支付了费用。发送模块4将打车订单发送给财务端，该打车订单中包含了员工的账户信息以及费用信息，便于财务端根据账户信息以及费用信息安排打款报销。

参照图7，在一个实施例中，上述打车报销装置还包括：

判断起点模块21，用于判断所述打车订单的打车起点是否在预设的地域范围内；

第一指令模块22，用于若所述打车起点在预设的地域范围内，则生成判断所述打车订单的开始时间是否在预设的时间段内的指令。

本实施例中，打车起点是指员工预约汽车时的起点位置。公司为了更准确的确定员工是因公而外出打车，对打车的起点均有设置。在一具体实施例中，设置起点位置的预设的地域范围是距离公司位置附近的一公里以内。服务器先获取预设的地域范围，然后获取到打车订单中的起点位置信息，判断起点模块21判断该起点位置信息是否在地域范围内。如果打车订单中的起点位置是在预设的地域范围内，说明员工的打车符合公司的要求，是属于因公事打车，因而需要继续下一步的判断，第一指令模块22生成用于判断打车时间是否在预设的时间段内的指令。

在一个实施例中，上述打车报销装置还包括：

获取模块211，用于根据所述员工的个人信息与地域范围的映射关系，获取所述员工对应的所述地域范围作为上述预设的地域范围。

本实施例中，员工的个人信息包括员工所在的部门、固定工作地点、职位级别。因每个员工的固定地点或者工作性质或者职位级别不一样，因此，每个员工因公用车的起点范围也是不一样的。服务器调用员工的账户信息，提取出其中的个人信息。后台工作人员根据各员工的工作性质以及职位等级等信息设置出每个员工的打车起点的范围，形成员工与打车起点的地域范围的映射关系。服务器调用出该映射关系，获取模块211获取到该员工对应的地域范围作为上述预设的地域范围。例如，该员工是属于市场部的员工，经常需要外出陌生拜访客户，经常拜访完一个陌生客户后再去另一个陌生客户前往拜访，因而该员工的打车起点是其拓展市场的市场范围，比如是该公司所在的市辖区均是其地域范围。另一员工的等级级别较高，为部门主管级别，需要经常与其他部门或其他相关的机构进行交流，因此其打车的起点不受到限制。

在一个实施例中，上述打车报销装置还包括：

判断出差模块23，用于若所述打车起点未在预设的地域范围内，则判断所述员工是否有出差申请单；

判断城市模块24，用于若所述员工具有出差申请单，则判断所述打车起点是否是所述出差申请单中的出差城市；

第二指令模块25，用于若所述打车起点位于所述出差城市，则生成判断打车订单的开始时间是否在预设的时间段内的指令。

本实施例中，如果打车订单中的打车起点不在预设的地域范围内，服务器获取到员工的个人信息后，判断出差模块23访问该员工账户的出差记录，即员工的出差申请单。出差申请单中包含有出差时间以及出差地点。判断出差模块23读取出差申请单，判断员工的出差申请单中的出差时间包含打车订单中的开始时间。因员工不在预设的地域范围内打车，也有可能是去外地出差引起的因公事而打车。判断城市模块24还读取出差申请单中的出差地点，即员工的出差城市，然后判断城市模块24判断打车起点是不是在出差城市。如果打车起点是在出差申请单中的出差城市，说明员工确实是在出差的城市打车，进而判断是在因公出差。因而，需要继续下一步的判断，第二指令模块25生成用于判断打车时间是否在预设的时间段内的指令。

参照图8，在一个实施例中，上述打车报销装置还包括：

获取类型模块26，用于获取所述打车订单的网约车类型，所述网约车类型包括不同等级的网约车；

类型范围模块27，用于根据预设的职位等级与网约车类型的映射关系，获取所述员工对应的网约车类型范围；

判断类型模块28，用于判断所述打车订单的网约车类型是否属于所述员工对应的网约车类型范围；

第三指令模块29，用于若打车订单的网约车类型属于所述员工对应的网约车类型范围，则生成判断打车订单的开始时间是否是预设的时间段内的指令。

本实施例中，打车订单包括多个网约车类型，比如出租车、顺风车、快车、专车、豪华车等，其中，上述出租车也是指员工通过APP约的网约车。服务器读取打车订单，获取类型模块26读取网约车类型。网约车按照价格分成四个等级，低级的是顺风车，初级是出租车、快车，中级是专车，高级是豪华车。公司会为中高层员工提供更好的待遇，对应的设置了更优质的网约车类型的出行服务。职位等级越高，对应的网约车类型的范围更广，比如部门主管可以使用中级的专车类型的网约车以及中级以下类型的网约车，部门经理可以使用任意类型的订单。普通员工只可以使用低级和初级类型的如出租车、顺风车和快车类型的网约车。后台人员根据各职位等级对应的网约车类型设置了对应的映射关系。类型范围模块27根据员工的个人信息中的职位等级，调用该职位等级与网约车类型的映射关系后，获取到员工的可用网约车类型的范围，比如，获取到员工的等级是普通职员，则对应的网约车类型范围是出租车、顺风车和快车。然后判断类型模块28判断订单中的网约车类型是否属于该员工对应的网约车类型范围，如果是的，则需要继续下一步的判断，第三指令模块29生成用于判断打车订单的开始时间是否在预设的时间段内的指令。

参照图9，在一个实施例中，上述打车报销装置还包括：

显示模块5，用于若所述打车订单的开始时间不在预设的时间段内，则显示可以报销打车费用的时间段。

本实施例中，当判定打车订单不在预设的时间段内，则该订单不可报销。显示模块5弹出不可报销的信息提醒员工，避免员工因公用车而无法报销产生的费用问题，或者提醒员工使用该订单后再走其他程序进行报销。显示模块5还在员工的APP端显示预设的时间段，提醒员工还没有到可以报销打车费用的时间，有利于员工合理的安排出行时间。

参照图10，在一个实施例中，上述发送模块4包括：

添加单元41，用于打车订单完成后，将所述打车订单添加可报销的标记；

定期单元42，用于定期发送具有可报销的标记的打车订单至财务端报销。

本实施例中，当打车订单完成，判定该打车订单是可以报销的后，添加单元41将该订单添加可报销的标记。具体的添加方式是，添加单元41建立一个存储区，将判定为可报销的打车订单放置在该存储区。定期单元42每隔一段时间，将存储区内的所有打车订单发送给财务端，便于财务端进行汇款报销事宜。定期的具体时间设置为一个月，与员工的工资同时发放，便于财务端批量审核，减小财务端的计算工作量。

综上所述，本申请的打车报销装置，通过在打车软件中对员工因公或加班打车的地点、时间等进行限制，从而使得员工按照规定的方式进行打车。自动对符合规则的打车订单进行报销，既节省了员工报销打车费用的流程，也避免了员工私事打车进行报销。

参照图11，本申请实施例中还提供一种计算机设备，该计算机设备可以是服务器，其内部结构可以如图11所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设计的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储员工的个人信息、公司地址、职位等级与网约车类型的映射关系等数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种打车报销方法。

上述处理器执行上述打车报销方法的步骤：接收员工输入的打车订单；判断所述打车订单的开始时间是否在预设的时间段内；若是，判定所述打车订单可报销；打车订单完成后，发送所述打车订单至财务端，用于财务端安排报销。

在一个实施例中，上述处理器判断所述打车订单的开始时间是否在预设的时间段内的步骤之前，包括：判断所述打车订单的打车起点是否在预设的地域范围内；若所述打车起点在预设的地域范围内，生成判断所述打车订单的开始时间是否在预设的时间段内的指令。

在一个实施例中，上述处理器判断所述打车订单的打车起点是否在预设的地域范围内的步骤之前，还包括：根据所述员工的个人信息与地域范围的映射关系，获取所述员工对应的所述地域范围作为所述预设的地域范围。

在一个实施例中，上述处理器判断打车订单的打车起点是否在预设的地域范围内的步骤之后，包括：若所述打车起点未在预设的地域范围内，则判断所述员工是否有出差申请单；若所述员工具有出差申请单，则判断所述打车起点是否是所述出差申请单中的出差城市；若所述打车起点位于所述出差城市，则生成判断所述打车订单的开始时间是否在预设的时间段内的指令。

在一个实施例中，上述处理器判断所述打车订单的开始时间是否在预设的时间段内的步骤之前，包括：获取所述打车订单的网约车类型，所述网约车类型包括不同等级的网约车；根据预设的职位等级与网约车类型的映射关系，获取所述员工对应的网约车类型范围；判断所述打车订单的网约车类型是否属于所述员工对应的网约车类型范围；若是，生成判断所述打车订单的开始时间是否是预设的时间段内的指令。

在一个实施例中，上述处理器判断所述打车订单的开始时间是否在预设的时间段内的步骤之后，还包括：若否，显示可以报销打车费用的时间段。

在一个实施例中，上述处理器执行打车订单完成后，发送所述打车订单至财务端的步骤包括：所述打车订单完成后，将所述打车订单添加可报销的标记；定期发送具有可报销的标记的打车订单至所述财务端报销。

本领域技术人员可以理解，图11中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定。

综上所述，本申请的计算机设备，通过在打车软件中对员工因公或加班打车的地点、时间等进行限制，从而使得员工按照规定的方式进行打车。自动对符合规则的打车订单进行报销，既节省了员工报销打车费用的流程，也避免了员工私事打车进行报销。

本申请一实施例还提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现一种打车报销方法，具体为：接收员工输入的打车订单；判断所述打车订单的开始时间是否在预设的时间段内；若是，判定所述打车订单可报销；打车订单完成后，发送所述打车订单至财务端，用于财务端安排报销。

在一个实施例中，上述处理器判断所述打车订单的开始时间是否在预设的时间段内的步骤之前，包括：判断所述打车订单的打车起点是否在预设的地域范围内；若所述打车起点在预设的地域范围内，生成判断所述打车订单的开始时间是否在预设的时间段内的指令。

在一个实施例中，上述处理器判断所述打车订单的打车起点是否在预设的地域范围内的步骤之前，还包括：根据所述员工的个人信息与地域范围的映射关系，获取所述员工对应的所述地域范围作为所述预设的地域范围。

在一个实施例中，上述处理器判断打车订单的打车起点是否在预设的地域范围内的步骤之后，包括：若所述打车起点未在预设的地域范围内，则判断所述员工是否有出差申请单；若所述员工具有出差申请单，则判断所述打车起点是否是所述出差申请单中的出差城市；若所述打车起点位于所述出差城市，则生成判断所述打车订单的开始时间是否在预设的时间段内的指令。

在一个实施例中，上述处理器判断所述打车订单的开始时间是否在预设的时间段内的步骤之前，包括：获取所述打车订单的网约车类型，所述网约车类型包括不同等级的网约车；根据预设的职位等级与网约车类型的映射关系，获取所述员工对应的网约车类型范围；判断所述打车订单的网约车类型是否属于所述员工对应的网约车类型范围；若是，生成判断所述打车订单的开始时间是否是预设的时间段内的指令。

在一个实施例中，上述处理器判断所述打车订单的开始时间是否在预设的时间段内的步骤之后，还包括：若否，显示可以报销打车费用的时间段。

在一个实施例中，上述处理器执行打车订单完成后，发送所述打车订单至财务端的步骤包括：所述打车订单完成后，将所述打车订单添加可报销的标记；定期发送具有可报销的标记的打车订单至所述财务端报销。

综上所述，本申请的计算机可读存储介质，通过在打车软件中对员工因公或加班打车的地点、时间等进行限制，从而使得员工按照规定的方式进行打车。自动对符合规则的打车订单进行报销，既节省了员工报销打车费用的流程，也避免了员工私事打车进行报销。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的和实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可以包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双速据率SDRAM(SSRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchl ink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、装置、物品或者方法不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、装置、物品或者方法所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、装置、物品或者方法中还存在另外的相同要素。

以上所述仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (10)

1.一种打车报销方法，其特征在于，包括：

接收员工输入的打车订单；

判断所述打车订单的开始时间是否在预设的时间段内；

若是，判定所述打车订单可报销；

打车订单完成后，发送所述打车订单至财务端，用于所述财务端安排报销。

2.如权利要求1所述的打车报销方法，其特征在于，所述判断所述打车订单的开始时间是否在预设的时间段内的步骤之前，包括：

判断所述打车订单的打车起点是否在预设的地域范围内；

若所述打车起点在预设的地域范围内，生成判断所述打车订单的开始时间是否在预设的时间段内的指令。

3.如权利要求2所述的打车报销方法，其特征在于，所述判断所述打车订单的打车起点是否在预设的地域范围内的步骤之前，还包括：

根据所述员工的个人信息与地域范围的映射关系，获取所述员工对应的地域范围作为所述预设的地域范围。

4.如权利要求2所述的打车报销方法，其特征在于，所述判断打车订单的打车起点是否在预设的地域范围内的步骤之后，包括：

若所述打车起点未在预设的地域范围内，则判断所述员工是否有出差申请单；

若所述员工具有出差申请单，则判断所述打车起点是否是所述出差申请单中的出差城市；

若所述打车起点位于所述出差城市，则生成判断所述打车订单的开始时间是否在预设的时间段内的指令。

5.如权利要求1所述的打车报销方法，其特征在于，所述判断所述打车订单的开始时间是否在预设的时间段内的步骤之前，包括：

获取所述打车订单的网约车类型，所述网约车类型包括不同等级的网约车；

根据预设的职位等级与网约车类型的映射关系，获取所述员工对应的网约车类型范围；

判断所述打车订单的网约车类型是否属于所述员工对应的网约车类型范围；

若是，生成判断所述打车订单的开始时间是否是预设的时间段内的指令。

6.如权利要求1所述的打车报销方法，其特征在于，所述判断所述打车订单的开始时间是否在预设的时间段内的步骤之后，还包括：

若否，显示可以报销打车费用的时间段。

7.如权利要求1所述的打车报销方法，其特征在于，所述打车订单完成后，发送所述打车订单至财务端的步骤包括：

所述打车订单完成后，将所述打车订单添加可报销的标记；

定期发送具有可报销的标记的打车订单至所述财务端报销。

8.一种打车报销装置，其特征在于，包括：

接收模块，用于接收员工输入的打车订单；

判断模块，用于判断所述打车订单中的开始时间是否在预设的时间段内；

判定模块，用于若是，判定所述打车订单可报销；

发送模块，用于打车订单完成后，发送所述打车订单至财务端，用于所述财务端安排报销。

9.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至7中任一项所述方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任一项所述的方法的步骤。