批准和追踪打车的系统和方法与流程

本申请一般涉及计算机技术，尤其涉及批准和追踪打车的系统和方法。

背景技术：

公司员工通常需要与业务相关的交通运输。传统上，员工将不得不花费个人资金来支付运输费用并申请公司的报销。这种过程复杂且耗时。

技术实现要素：

本申请的各种实施例包括批准和追踪打车的系统、方法和非暂时性计算机可读介质。

根据本申请的一个方面，一种批准和追踪打车的计算机实现的方法，包括：获取通过申请人账户提交的计划行程信息，所述信息包括以下至少一项：计划时间段、计划出发地、计划目的地、预算或在所述计划时间段中的计划旅程次数；响应于从一个或以上审批计算设备接收对所述计划行程的批准，授权所述申请人账户能够为实际行程订购一个或以上旅程，所述批准包括以下至少一个条件：批准的时间段、批准的出发地、批准的目的地、批准的预算或在所述批准的时间段中的批准的旅程次数；在所述实际行程中，追踪与所述申请人账户相关的申请人计算设备的信息，以确定以下至少一个：所述旅程的开始时间是否在所述批准的时间段内、所述旅程的结束时间是否在所述批准的时间段内、所述旅程的出发地是否在距所述批准的出发地的第一阈值距离内、所述旅程的目的地是否在距所述批准的目的地的第二阈值距离内、所述旅程的费用是否在所述批准的预算内，或所述旅程的旅程次数是否在所述批准的旅程次数内；以及响应于任何不满足的确定结果，将所述追踪信息发送到所述一个或以上审批计算设备，以审核所述批准。

在一些实施例中，在所述实际行程中，追踪与所述申请人账户相关的所述申请人计算设备的信息包括：获取对应于上车位置的与所述申请人账户相关的所述申请人计算设备的全球定位系统gps位置，所述上车位置作为所述旅程的所述出发地，以及获取对应于下车位置的与所述申请人账户相关的所述申请人计算设备的gps位置，所述下车位置作为所述旅程的目的地。

在一些实施例中，所述方法还包括：响应于确定所述申请人计算设备正在为所述实际行程订购当前旅程，并确定以下至少一个：当前时间不在所述批准的时间段内、所述申请人的计算设备的当前位置不在距所述批准的出发地的所述第一阈值距离内、或所述批准的时间段中所述实际行程的过去的旅程次数不在所述批准的旅程次数内，禁止所述申请人计算设备通过所述申请人账户订购所述当前旅程。

在一些实施例中，所述方法还包括：响应于任何不满足的确定结果，通过所述申请人账户获取不匹配的解释，并将所述解释与所述追踪信息一起传送至所述一个或以上审批计算设备，以审核所述批准。

在一些实施例中，所述一个或以上审批计算设备包括第一审批计算设备和第二审批计算设备。从一个或以上审批计算设备接收所述计划行程的所述批准包括：从所述第一审批计算设备接收第一批准；将所述计划行程转发到所述第二审批计算设备；以及从所述第二审批计算设备接收第二批准。

在一些实施例中，所述申请人账户由与实体有关的申请人使用，所述审批计算设备由所述实体的审批人使用，以及所述方法还包括从所述实体的资金中支付所述实际行程的费用。

在一些实施例中，在获取通过所述申请人账户提交的所述计划行程的所述信息之前，所述方法还包括：从配置计算设备获取作为所述预算上限的阈值、作为所述计划行程的地理边界的区域限定，以及用于确定一个或以上审批人账户的一个或以上审批人的信息，其中，所述审批计算设备分别与所述审批人账户关联。

根据本申请的另一方面，一种批准和追踪打车的系统，包括处理器和存储指令的非暂时性计算机可读存储介质，当所述处理器执行所述指令时，使所述处理器执行方法。所述方法包括：获取通过申请人账户提交的计划行程信息，所述信息包括以下至少一项：计划时间段、计划出发地、计划目的地、预算或在所述计划时间段中的计划旅程次数；响应于从一个或以上审批计算设备接收对所述计划行程的批准，授权所述申请人账户能够为实际行程订购一个或以上旅程，所述批准包括以下至少一个条件：批准的时间段、批准的出发地、批准的目的地、批准的预算或在所述批准的时间段中的批准的旅程次数；在所述实际行程中，追踪与所述申请人账户相关的申请人计算设备的信息，以确定以下至少一个：所述旅程的开始时间是否在所述批准的时间段内、所述旅程的结束时间是否在所述批准的时间段内、所述旅程的出发地是否在距所述批准的出发地的第一阈值距离内、所述旅程的目的地是否在距所述批准的目的地的第二阈值距离内、所述旅程的费用是否在所述批准的预算内，或所述旅程的旅程次数是否在所述批准的旅程次数内；以及响应于任何不满足的确定结果，将所述追踪信息发送到所述一个或以上审批计算设备，以审核所述批准。

根据本申请的另一方面，一种存储指令的非暂时性计算机可读存储介质，当所述处理器执行所述指令时，使得所述处理器执行方法。所述方法包括获取通过申请人账户提交的计划行程信息，所述信息包括以下至少一项：计划时间段、计划出发地、计划目的地、预算或在所述计划时间段中的计划旅程次数；响应于从一个或以上审批计算设备接收对所述计划行程的批准，授权所述申请人账户能够为实际行程订购一个或以上旅程，所述批准包括以下至少一个条件：批准的时间段、批准的出发地、批准的目的地、批准的预算或在所述批准的时间段中的批准的旅程次数；在所述实际行程中，追踪与所述申请人账户相关的申请人计算设备的信息，以确定以下至少一个：所述旅程的开始时间是否在所述批准的时间段内、所述旅程的结束时间是否在所述批准的时间段内、所述旅程的出发地是否在距所述批准的出发地的第一阈值距离内、所述旅程的目的地是否在距所述批准的目的地的第二阈值距离内、所述旅程的费用是否在所述批准的预算内，或所述旅程的旅程次数是否在所述批准的旅程次数内；以及响应于任何不满足的确定结果，将所述追踪信息发送到所述一个或以上审批计算设备，以审核所述批准。

通过参考附图来考虑以下描述和所附权利要求，本文披露的系统、方法和非暂时性计算机可读介质的这些和其他特征，以及结构的相关元件的操作方法和功能以及部件的组合和制造经济的功能将更加显而易见，本发明的所有附图均构成说明书的一部分，其中相同的附图标记表示各个附图中的相应部分。然而，应清楚地理解，附图仅用于说明和描述的目的，并不旨在作为本发明范围的界定。

附图说明

本技术的各种实施例的某些特征在所附权利要求中具体阐述。通过参考以下具体实施方式及其附图，将更好地理解本技术的特征和优点，其中具体实施方式详尽介绍了利用本发明原理的说明性实施例，所述附图包括：

图1示出了根据各种实施例的批准和追踪打车的示例性环境。

图2示出了根据各种实施例的批准和追踪打车的示例性系统交互。

图3a示出了根据各种实施例的配置打车申请的示例性界面。

图3b示出了根据各种实施例的配置审批人的示例性界面。

图3c示出了根据各种实施例的申请行程审批的示例性界面。

图3d示出了根据各种实施例的显示申请状态的示例性界面。

图3e示出了根据各种实施例的批准申请的示例性界面。

图3f示出了根据各种实施例的显示批准的申请的示例性界面。

图4示出了根据各种实施例的批准和追踪打车的示例性方法的流程图。

图5示出了可以实现本文描述的任何实施例的示例性计算机系统的框图。

具体实施方式

公司员工通常需要与业务相关的交通运输。传统上，员工必须申请报销批准，花费个人资金来支付运输费用，并提交行程证据以进行报销。一些公司审批人可能会筛选这些申请并作出报销决定。这种过程复杂且耗时。此外，审批人可以批准具有特定条件的特定运输的申请，这些条件难以基于仅具有有限信息(例如，时间和费用)的提交证据来验证。因此，随着越来越多的员工，管理报销程序变得繁重。缺乏核查机制进一步为错用、滥用和欺诈创造了空间。

本申请所披露的系统和方法可以至少减轻当前通用做法的上述技术问题。本申请的各种实施例包括批准和追踪打车的系统、方法和非暂时性计算机可读介质。可以通过具有服务器端和/或客户端功能的软件来实现示例性方法，以使得实体能够简化员工打车申请、批准和追踪。客户端可以具有针对不同用户组的不同接口和功能：企业经理、审批人、申请人等。客户端可以与服务器端交互以实现各种功能。可报销的行程申请可以由企业管理者配置，以定义收集计划行程的申请信息的各种字段(例如，时间段、位置、审批人)。员工申请人可以提交计划行程，但须经一个或以上的审批人批准。审批人可以审查以及批准/拒绝申请。一旦申请获得批准，申请人可以根据授权的批准直接订购交通运输服务，运输费用由实体承担。通过追踪申请人的计算设备，可以确保订购的运输服务符合批准的计划。因此，可以有效地处理、追踪和管理交通报销，并且可以防止公司资金的不当使用和滥用。

图1示出了根据各种实施例的批准和追踪打车的示例性环境100。如图1所示，示例性环境100可以包括至少一个计算系统102，其包括一个或以上处理器104和内存106。内存106可以是非暂时性的并且是计算机可读的。内存106可以存储指令，当指令被一个或以上处理器104执行时，使得一个或以上处理器104执行本文描述的各种操作。系统102可以在诸如移动电话、平板电脑、服务器、计算机、可穿戴设备等各种设备上实现，或者作为上述各种设备实现。上述系统102可以安装有适当的软件和/或硬件(例如，电线、无线连接等)以访问环境100的其他设备。

环境100可以包括一个或以上数据存储器(例如，数据存储器108)和可访问系统102的一个或以上计算设备(例如，计算设备109)。在一些实施例中，系统102可以被配置为从数据存储器108中获取数据(例如，地图数据、用户数据)和/或将数据存储到数据存储器108(例如，用户数据集、地图数据库)和/或计算设备109(例如，计算机、服务器、移动电话)中。

环境100还可以包括耦合到系统102的一个或以上计算设备(例如，计算设备107、110、111和112)。例如，每个计算设备可以是移动电话、平板电脑、计算机、可穿戴设备(智能手表)等。计算设备可以各自向系统102发送数据和/或从系统102接收数据。传输的数据可以包括用户信息数据、时间数据、位置数据等。位置数据可以包括gps(全球定位系统)坐标。计算设备107可以与实体的监督行程报销的个人(例如，负责财务和预算的企业管理者)相关联。计算设备110可以与申请人(例如，申请行程报销并且也是实际行程的乘客的公司员工)相关联。计算设备111可以与审批人(例如，企业的管理者)相关联。计算设备112可以与另一个审批人(例如，企业的另一个管理者)相关联。计算设备107、110、111和112可以具有针对相应用户组定制的不同界面和功能。

在一些实施例中，系统102可以实现在线信息或服务平台(例如，以软件应用程序的形式)。所述平台可以被称为车辆平台(或打车服务平台、乘车订单调度平台)。所述服务可以与车辆(例如，汽车、自行车、船、飞机等)相关联。平台可以接受对运输的请求、识别满足请求的车辆、安排接载以及处理交易。例如，用户可以使用计算设备110(例如，安装有与平台相关联的软件应用程序的移动电话)来从平台请求运输。系统102可以接收所述请求(例如，包括上车时间、上车位置和目的地)并将其转送给各个车辆驾驶员(例如，通过将请求发布到由驾驶员携带的移动电话)。车辆驾驶员可以使用计算设备(例如，安装有与平台相关联的应用程序的另一个移动电话)来接受所发布的运输请求，行驶到上车位置，并将用户运送到目的地。费用(例如，运输费用)可以在系统102、计算设备110和驾驶员的计算设备之间进行交易。一些平台数据可以存储在内存106中，或者可以从数据存储器108和/或计算设备107、109、110和111中读取。例如，对于每次行程，起点和目的地的位置(例如，由计算设备110和/或驾驶员的计算设备发送)、费用(例如，由系统102确定)和时间可以由系统102获得。

在一些实施例中，软件应用程序可以提供各种用户模式。对于一种用户模式，用户可以在未经授权及未经第三方(例如，用户的企业雇主)报销的情况下使用车辆平台。用户可以订购行程并用自己的资金支付。对于这里描述的另一个用户模式，用户可以使用车辆平台申请报销计划的(未来的)行程。经过批准，用户可以通过软件应用程序直接订购部分或全部由第三方报销的行程。

在一些实施例中，系统102和一个或以上计算设备(例如，计算设备109)可以集成在一个单独的设备或系统中。或者，系统102和一个或以上计算设备可以是分离的设备。数据存储器可以位于可访问系统102的任何位置，例如，在内存106中、在计算设备109中、在耦合到系统102的另一设备(例如，网络存储设备)中，或其他存储位置(例如，基于云的存储系统、网络文件系统等)等。尽管在该图中系统102和计算设备109被示为独立的组件，但是应当理解，系统102和计算设备109可以由独立设备或耦合在一起的多个设备实现。系统102可以由一个独立系统或耦合在一起的多个系统实现。一般地，通过一个或以上有线或无线网络(例如，因特网)，系统102、计算设备109、数据存储器108和计算设备110、111和112能够相互通信，以传送数据。下面参考图2至图5描述环境100的各个方面。

图2示出了根据各种实施例的批准和追踪打车的示例性系统交互。图2中所示并在下文呈现的操作旨在用于说明。取决于实施方式，图2中示出并在下文呈现的操作可以包括附加的、减少的或替代性的步骤，这些步骤可以以各种顺序执行或并行执行。在本申请中，公司和企业被广泛地定义，并且可以包括任何类型的组织或多个组织。尽管在整个本申请中使用员工申请人作为示例，但是也可以应用其他类型的申请人-组织关系。

图2示出了上面参考图1描述的系统102(例如，服务器)、配置计算设备107(例如，企业管理者或控制者使用的笔记本电脑)、申请人计算设备110(例如，企业员工申请人使用的移动电话)、第一审批计算设备111(例如，企业管理者使用的移动电话)，以及第二审批计算设备112(例如，另一企业管理器的计算机)。为了访问计算设备107、110、111或112，用户可能需要登录相应的帐户或以其他方式验证身份。例如，可能需要配置帐户认证以通过配置计算设备107执行各种步骤(下面描述)，可能需要申请人账户认证以通过申请人计算设备110执行各种步骤(下面描述)，可能需要第一管理员账户认证以通过第一审批计算设备111执行各种步骤(下面描述)，以及可能需要第二管理员账户认证以通过第二审批计算设备112执行各种步骤(如下所述)。因此，该图中所示的计算设备107、110、111或112可以各自代表一个或以上的计算设备，并且只要通过相应的账户进行认证，用户就可以访问任何计算设备以执行所描述的步骤。例如，申请人可以从个人笔记本电脑申请行程报销(例如，步骤202)，然后从个人移动电话订购实际行程(例如，在步骤206之后)。

在一些实施例中，计算设备107、110、111和112可各自安装有用于车辆平台的软件(例如，移动电话app、桌面软件)。该软件可以具有针对不同用户组的不同界面和功能。例如，计算设备107可以安装企业端软件版本，并且企业管理者可以通过登录配置帐户来访问软件。计算设备110可以安装申请人/乘客端软件版本，并且申请人可以通过登录申请人账户来访问该软件。计算设备111和112可以安装审批人端软件版本，并且审批人可以通过登录审批人账户来访问软件。安装在计算设备110上的软件可以提供上述打车功能。诸如驾驶员的移动电话之类的运输提供者的计算设备(未示出)可以安装驾驶员端软件版本。系统102可以托管软件应用程序的服务器端。安装在系统102和各种计算设备上的软件可以提供下面更详细讨论的申请、批准和追踪功能。

图2示出了系统102与计算设备107、110、111和112之间的交互。以下呈现的交互操作旨在用于说明性。取决于实施方式，操作可以包括附加的、减少的、或替代性的步骤，这些步骤可以以各种顺序执行或并行执行。

在一些实施例中，在步骤201，用户(例如，企业管理者)可以通过配置计算设备107访问配置账户以配置行程报销申请的设置。例如，系统102可以从配置计算设备107获取作为预算上限的阈值、作为计划行程的地理边界的区域定义，以及用于确定一个或以上审批人账户的一个或以上审批人的信息。在此配置中选择的审批人将被委派审查和批准申请。下面参考图3a和图3b描述用于配置的示例性界面的更多细节。系统102可以使申请人计算机设备110上的申请人/乘客端软件显示用于获取申请信息的相应界面。在步骤202，系统102可以获取通过申请人账户提交的计划行程的信息。该信息可以包括：计划时间段、计划出发地、计划目的地、预算和/或计划时间段内的计划旅程次数。下面参考图3c描述用于获取信息的示例性界面的更多细节。系统102可以基于所获取的信息自动编译申请，并将该申请转发给一个或以上的审批人。例如，在步骤203，系统102将申请转发到第一审批人帐户。基于示例性批准配置，如果第一审批人从计算设备111批准申请，并在步骤204通知系统102，则系统102可以在步骤205将该申请转发到第二审批人帐户。下面参考图3d描述在申请人端查看申请状态的示例性界面的更多细节。下面参考图3e描述在审批人端批准申请的示例性界面的更多细节。如果第二审批人在步骤206也批准了申请，则系统102可以在步骤207向申请人账户通知该批准。下面参考图3f描述基于批准订购行程的示例性界面的更多细节。

仍然参考图2，响应于从一个或以上审批计算设备111和112接收对计划行程的批准，系统102可以使申请人账户能够为实际行程订购一个或以上的旅程。该批准可以包括以下条件的一个或以上：批准的时间段、批准的出发地、批准的目的地、批准的预算以及在批准的时间段中批准的旅程次数。这些条件可以通过追踪申请人的计算设备来验证。在步骤208，系统102可以在实际行程期间，追踪与申请人账户相关的申请人的计算设备(例如，申请人计算设备110)信息以确定：所述旅程的开始时间是否在所述批准的时间段内、所述旅程的结束时间是否在所述批准的时间段内、所述旅程的出发地是否在距所述批准的出发地的第一阈值距离内、所述旅程的目的地是否在距所述批准的目的地的第二阈值距离内、所述旅程的费用是否在所述批准的预算内，或所述旅程的旅程次数是否在所述批准的旅程次数内。如果存在任何确定结果不满足，则系统102可以在步骤209a通知申请人账户并寻求对该差异的解释，并在步骤209b和209c将追踪信息发送到一个或以上审批计算设备111和112，以便审核批准。也就是说，系统102可以通过申请人账户获取对不匹配的解释，并将解释与追踪信息一起发送到一个或以上审批计算设备，以审核批准。审批人可以根据解释，确定不匹配的申请是否被允许。如果该订购行程符合条件，则系统102可以将实际行程的费用从实体的资金中支付给驾驶员的账户。

在一些实施例中，如果系统102确定申请人计算设备110正在为实际行程订购当前旅程并且确定以下中的至少一个：当前时间不在所述批准的时间段内、所述申请人的计算设备的当前位置不在距所述批准的出发地的所述第一阈值距离内、或所述批准时间段中所述实际行程的过去的旅程次数不在所述批准的旅程次数内，系统102可以禁止所述申请人的计算设备通过所述申请人账户订购所述当前旅程。也就是说，申请人可能不能订购不符合批准条件的报销旅程。尽管如此，申请人仍可以通过个人账户订购旅程，而不通过报销。

在一些实施例中，为了在实际行程期间，追踪与申请人账户相关的申请人的计算设备110的信息，系统102可以获取对应于上车位置的与申请人相关的申请人计算设备110的全球定位系统(gps)位置，该上车位置作为所述旅程的出发地，以及获取对应于下车位置的与申请人账户相关的申请人计算设备110的gps位置，该下车位置作为所述旅程的目的地。例如，当发出订单用于实际行程时，计算设备110可以指示计划的上车位置并将该位置发送到系统102。该计划位置可以用作实际上车位置。附加地或替代地，当用户被接载时，驾驶员可以通过驾驶员终端软件指示用户已被接载，并且计算设备110或者驾驶员的计算设备的当前位置也可以用作行程的出发地。当到达目的地时，驾驶员可以通过驾驶员终端软件指示用户被放下，并且计算设备110或驾驶员的计算设备的当前位置可以用作行程的目的地。

图3a-3f示出了根据各种实施例的批准和追踪打车的应用程序的示例性界面。图3a-3f中所示并在下面给出的操作旨在说明。

图3a示出了根据各种实施例的配置打车申请的示例性界面300。可以在配置计算设备107的企业端软件上提供界面300。因此，具有访问配置帐户权限的企业管理员可以在此界面配置设置，以反映行程报销申请和批准的企业标准。如图3a所示，界面300可以为企业可能报销的各种员工旅行场景提供配置设置，例如，加班、通勤到工作场所、商务旅行、机场接送、以及商务车租赁等。在此图中，显示了报销商务旅行的配置设置。其他场景可以具有类似的配置设置。

配置设置可以包括：申请类型、计划旅程次数、旅程阈值、个人限制、计划时间段、计划路线、区域限定、可用车辆类型、审批人等。申请类型可以包括，例如，“按旅程次数申请”或“按时间段”。“按旅程次数申请”可以适用于申请人可能需要一个或以上旅程的单日旅行。“按时间段的申请”可适用于多日旅行。如增厚的边界线所示，在该示例中选择“按旅程次数”作为示例。可以另外或替代地使用其他申请类型和配置设置。每个申请可以申请高级“行程”，其可以包括在各个位置之间的一个或以上的旅程。计划旅程的次数可以由申请人输入或由企业管理者限制。旅程阈值可以用作每次旅程的报销预算的上限。个人限制可以指可以为单个人报销的最大金额，例如，对于每个行程、对于每个时间段等。计划时间段可由申请人填写或由企业管理员限制。计划路线(例如，就出发地和目的地位置而言)可以由申请人填写或由企业管理员限制。例如，企业管理员可以将出发地限制在离企业公司位置一英里的范围内。区域定义可以提供限制同一城市的起点和终点的选项，以防止来自城市间长途旅行的高成本。可用的车辆类型可以定义批准供申请人订购的一种或以上类型的车辆。审批人配置可用于配置负责审查申请的一个或以上审批人的信息。每位审批人都有一个审批人账户，申请可以转发给他们批准。

图3b示出了根据各种实施例的配置审批人的示例性界面311-313。可以从配置计算设备107在企业端软件上提供界面311-313。如图3b所示，界面311可以提供配置一个或以上审批人的选项。审批人可以由不同级别组成。例如，对于两级结构，申请需要由第一级审批人批准后，然后才能转发给第二级审批人进行审批。在每个级别，审批人可以被配置为“上级审批人”或“特别审批人”。对于上级审批人，企业管理员可以设置一个审批人库，申请人在准备申请时可选择适当的审批人。对于特别审批人，企业管理员可以为申请人配置审批人。如图所示，在第一级，johndoe由企业管理员配置为特别审批人。如果企业管理员试图删除johndoe，则可以触发界面312或313。如果johndoe有待批准的申请，则界面312可以提供将申请退还给申请人或提醒johndoe的选项。如果johndoe没有待批准的申请，则界面313可以指示johndoe是唯一剩余的审批人，并且提供添加替换审批人以保持该配置有效的选项。

图3c示出了根据各种实施例的申请行程审批的示例性界面320。可以在申请人计算设备110的申请人端软件上提供界面320。因此，有权访问申请人账户的申请人可以提交申请以供批准。如图3c所示，界面320可以获取通过申请人账户提交的计划行程信息。获取的信息可以包括：计划时间段(例如，在日期段和/或时段)、计划出发地、计划目的地、往返设置、预算(未示出)、在计划时间段内的旅程次数(例如，两次出发和两次返回旅程)、申请理由等。在界面320上，可以自动生成费用中心信息，例如，以指示企业内的部门以报销运输。审批人可以为自动生成的特殊审批人，也可以为由申请人选择的上级审批人。

图3d示出了根据各种实施例的用于显示申请状态的示例性界面330。可以在申请人计算设备110的申请人端软件上提供界面330。因此，有权访问申请人账户的申请人可以查看申请批准程序。如图3d所示，界面330可以指示所提交的申请的细节以及完成和待批准的批准阶段。如图所示，在提交申请后，johndoe已经批准了xyz的申请，目前申请正在等待jamessmith的批准。

图3e示出了根据各种实施例的批准申请的示例性界面340。可以在申请人计算设备112的审批人端软件上提供界面340。因此，有权访问审批人账户的审批人可以查看待批准的申请。如图3e所示，界面340可以指示已提交的申请的细节和已批准该申请的审批人(johndoe)。通过此界面，jamessmith可以批准申请或退还给申请人。由于jamessmith是批准此申请的最后审批人，因此他无需批准申请后将该申请转发给下一个审批人。

图3f示出了根据各种实施例的显示已批准的申请的示例性界面350。可以在申请人计算设备110的申请人端软件上提供界面350。如图3f所示，界面350可以指示批准的申请的细节，其可以与提交的计划行程的细节相同。通过此界面，xyz可以直接通过批准的授权和报销订购实际行程，或切换到个人帐户并使用个人资金订购行程。

如上所述，具有服务器和客户端的软件系统可以实现行程报销程序。企业可以从企业端软件轻松配置和管理行程报销申请、审批和追踪，并保证计算系统根据批准的条件验证行程订单。员工申请人和审批人可以方便地简化申请审批流程。因此，可以防止报销被不当使用、滥用和用于欺诈。现在可以节省先前在报销项目管理上花费的公司资源并将其用于其他地方。

图4示出了根据本申请的各种实施例的批准和追踪打车的示例性方法400的流程图。方法400可以在各种环境中实现，包括例如图1的环境100。示例性方法400可以由系统102的一个或以上组件(例如，处理器104、内存106)实现。示例性系统102可以包括服务器。示例性方法400可以由类似于系统102的多个系统实现。下文呈现的方法400的操作旨在用于说明。取决于实现方式，示例性方法400可以包括附加的、减少的、或替代性步骤，这些步骤可以以各种顺序执行或并行执行。

方框402包括获取通过申请人账户提交的计划行程的信息，该信息包括以下中的至少一个：计划时间段、计划出发地、计划目的地、预算或在计划时间段中计划的旅程数量。方框404包括响应于从一个或以上审批计算设备接收对计划行程的批准，使申请人账户能够为实际行程订购一个或以上的旅程，该批准包括至少一个条件：批准的时间段、批准的出发点、批准的目的地、批准的预算或在批准的时间段中的批准的旅程次数。方框406包括在实际行程期间追踪与申请人账户相关的申请人计算设备的信息，以确定以下中的至少一个：该旅程的开始时间是否在批准的时间段内、该旅程的结束时间是否在批准的时间段内、该旅程的出发地是否在距批准的出发地的第一阈值距离内、该旅程的目的地是否在距批准的目的地的第二阈值距离内、该旅程的费用是否在批准的预算内，或该旅程的旅程次数是否在批准的旅程次数内。方框408包括响应于不满足的任何确定结果，将追踪信息发送到一个或以上审批计算设备以审核批准。

在一些实施例中，在实际运输期间，追踪与申请人账户相关的申请人计算设备的信息包括：获取对应于上车位置的与申请人账户相关的申请人计算设备的全球定位系统gps位置，该位置作为所述旅程的出发地，以及获取对应于下车位置的与申请人账户相关的申请人计算设备的gps位置，该位置作为所述旅程的目的地。

在一些实施例中，该方法还包括：响应于确定申请人的计算设备正在为实际行程订购当前旅程，并确定以下至少一个：当前时间不在所述批准的时间段内、该申请人的计算设备的当前位置不在距批准的出发地的第一阈值距离内、或批准时间段中实际行程的过去的旅程次数不在批准的旅程次数内，禁止该申请人的计算设备通过申请人账户订购当前旅程。

在一些实施例中，该方法还包括：响应于任何不满足的确定结果，通过申请人账户获取对不匹配的解释，并将解释与该追踪信息一起发送到一个或以上审批计算设备以审核批准。

在一些实施例中，一个或以上审批计算设备包括第一审批计算设备和第二审批计算设备。从一个或以上审批计算设备获取计划行程的批准包括：从第一审批计算设备接收第一批准；将计划行程转发至第二审批计算设备；并从第二审批计算设备接收第二批准。

在一些实施例中，申请人账户由与实体相关的申请人使用，审批计算设备由该实体的审批人使用，并且该方法还包括从实体的资金中支付实际行程的费用。

在一些实施例中，在获取通过申请人账户提交的计划行程的信息之前，该方法还包括：从配置计算设备，获取一个阈值作为预算的上限，一个区域限定作为计划行程的地理边界，以及用于确定一个或以上审批人账户的一个或以上审批人的信息，其中审批计算设备分别与审批人账户关联。方法400的进一步细节可以参考上面的图1-3f。

这里描述的技术由一个或以上专用计算设备实现。专用计算设备可以是台式计算机系统、服务器计算机系统、便携式计算机系统、手持设备、网络设备或包含硬连线和/或程序逻辑以实现该技术的任何其他设备或设备的组合。计算设备通常由操作系统软件控制和协调。传统的操作系统控制和安排计算机进程以用于执行、执行存储器管理、提供文件系统、网络、输入/输出服务、以及提供用户界面功能，例如，图形用户界面(“gui”)等。

图5是示出示例性的可以实现本文描述的任何实施例的计算机系统500的框图。系统500可以对应于上述系统102。计算机系统500包括总线502或用于交流信息的其他通信机制、一个或以上与总线502耦合的用于处理信息的硬件处理器504。硬件处理器504可以是例如，一个或以上通用微处理器。处理器504可以对应于上述处理器104。

计算机系统500还包括与总线502耦合的用于存储由处理器504执行的信息和指令的主存储器506，例如，随机存取存储器(ram)、缓存和/或其他动态存储设备。主存储器506还可以用于在处理器504执行待执行指令期间存储临时变量或其他中间信息。当上述指令存储在处理器504可访问的存储介质中时，可使计算机系统500成为专用机器，该专用机器被定制为执行指令中指定的操作。计算机系统500还包括只读存储器(rom)508或耦合到总线502的其他静态存储器，用于存储处理器504的静态信息和指令。提供了存储器510，例如，磁盘、光盘或usb拇指驱动器(闪存驱动器)等，并将其耦合到总线502，用于存储信息和指令。主存储器506、rom508和/或存储器510可以对应于上述内存106。

计算机系统500可以使用定制的硬连线逻辑、一个或以上的专用集成电路(asic)或现场可编程门阵列(fpga)、固件和/或程序逻辑来实现本文描述的技术，其与计算机系统组合使计算机系统500成为或被编程为特殊用途机器。根据一个实施例，响应于处理器504执行主存储器506中包含的一个或以上指令中的一个或以上序列，计算机系统500可以执行本披露书中的技术。这些指令可以从另一存储介质(例如，存储器510)读入主存储器506。执行主存储器506中包含的指令的序列使得处理器504执行本文描述的处理步骤。在备选实施例中，可以使用硬连线电路代替软件指令或与软件指令组合。

主存储器506、rom508和/或存储器510可以包括非暂时性存储介质。这里使用的术语“非暂时性介质”和类似术语是指存储使机器以特定方式操作的数据和/或指令的介质。所述介质不包括暂时信号。这种非暂时性介质可以包括非易失性介质和/或易失性介质。非易失性介质包括，例如光盘或磁盘，如存储器510。易失性介质包括动态存储器，例如，主存储器506。非暂时性介质的常见形式包括，例如，软盘、软性磁盘、硬盘、固态驱动器、磁带、或任何其他磁性数据存储介质、只读光盘驱动器(cd-rom)、任何其他光学数据存储介质、具有孔图案的任何物理介质、ram、可编程序只读存储器(prom)和可擦除可编程只读存储器(eprom)、快擦编程只读存储器(flash-eprom)、非易失性随机访问存储器(nvram)、任何其他存储器芯片或盒式磁带、以及它们的网络版本。

计算机系统500还包括耦合到总线502的网络接口518。网络接口518提供耦合到一个或以上网络链路的双向数据通信，所述一个或以上网络链路连接到一个或以上本地网络。例如，网络接口518可以是综合业务数字网(isdn)卡、线缆调制解调器、卫星调制解调器、或用于提供与相应类型的电话线路进行数据通信连接的调制解调器。又例如，网络接口518可以是局部区域网络(lan)卡以提供与兼容的lan之间的数据通信连接(或wan组件以与wan通信)。网络接口518也可以实现无线链路。在任何这样的实施方式中，网络接口518发送和接收携带代表各类信息的数字数据流的电信号、电磁信号或光信号。

计算机系统500可以通过网络、网络链路和网络接口518发送消息并接收包括程序代码的数据。以因特网为例，服务器可以通过因特网、互联网服务提供商(isp)、本地网络和网络接口518为应用程序发送请求代码。

所接收的代码可以在被收到后由处理器504执行、和/或存储在存储器510或其他非易失性存储器中以供稍后执行。

在前面部分中描述的每个过程、方法和算法可以由代码模块实现，并且通过该代码模块实现完全自动化或半自动化。所述代码模块通过一个或以上包括计算机硬件的计算机系统或计算机处理器执行。上述过程和算法可由应用特定电路部分地或完全地实现。

上述各种特征和过程可以彼此独立地使用，或者可以以各种方式组合。所有可能的组合和子组合旨在落入本申请的范围内。另外，在一些实现中可以省略某些方法或过程块。本文描述的方法和过程也不限于任何特定顺序，与其相关的框或状态可以以其他合适顺序执行。例如，所描述的块或状态可以以不同于具体披露的顺序执行，或者多个块或状态可以组合为单个块或状态。示例性框或状态可以串行、并行或以其他方式执行。可以向所披露的示例性实施例添加块或状态或从中移除块或状态。本文描述的示例性系统和组件可以通过不同于本文所描述的方式进行配置。例如，相比于与所披露的示例性实施例，可以添加、移除或重新布置元件。

可以至少部分地通过算法来执行本文描述的示例性方法中的各种操作。该算法可以被包括在存储于存储器(例如，上述的非暂时性计算机可读存储介质)中的程序代码或指令中。这种算法可以包括机器学习算法。在一些实施例中，机器学习算法可以不明确地对计算机进行编程以执行某个功能，但是可以学习训练数据以生成执行该功能的预测模型。

这里描述的示例性方法的各种操作可以至少部分由临时配置(例如，通过软件)或永久用于执行相关操作的一个或多个处理器执行。无论是临时配置还是永久配置，所述处理器都可以构成由处理器实现的引擎，其运行以执行本文描述的一个或以上操作或功能。

类似地，本文描述的方法可以至少部分地由一个特定处理器或一组处理器(作为硬件示例)实现。例如，方法的至少一部分操作可以由一个或以上处理器或处理器实现的引擎来执行。此外，一个或以上处理器还可以运行以发挥“云计算”环境中的相关操作的支护性能或实现“软件即服务”(saas)。

本文所述和/或附图中描绘的流程图中的任何过程描述、元素或框应理解为潜在地表示模块、部件、或部分代码，这些模块、部件、或部分代码包括用于实现特定逻辑功能或过程步骤的一个或以上可执行指令。本领域技术人员可以理解的是，本文描述的实施例的范围内还包括备选实施方式，在这些备选实施方式中，元件或功能可以被删除，或取决于所涉及的功能而不由所示出的或论述的顺序来执行，包括实质上同时执行或以相反的顺序执行。

如本文所用，术语“或”可以解释为包含性或排他性含义。此外，可以为在此描述为单个实例的资源、操作或结构提供多个实例。另外，各种资源、操作、引擎和数据存储之间的边界在某种程度上是任意的，并且在特定说明性配置的上下文中示出了特定操作。设想的其他功能的分配可以落入本申请的各种实施例的范围内。通常，在示例性配置中作为单独资源呈现的结构和功能可以以组合结构或组合资源实现。类似地，作为单独资源呈现的结构和功能可以以多个分离的资源实现。这些以及其他变化、修改、添加和改进均落入由所附权利要求表示的本申请的实施例的范围内。相应地，说明书和附图应被视为说明性的而非限制性的。

尽管已经参考特定示例性实施例概述了本文主题，但是可以在不脱离本申请的实施例的较宽范围的情况下对这些实施例进行各种修改和改变。本文主题的这些实施例可单独地或共同地由术语“发明”指代，此举仅为描述方便，而不旨在当实际有多余一个披露或概念被披露时主动将本申请的范围限制于任何单个的披露或概念。

本文所示的实施例已被描述的足够详尽，使得本领域技术人员能够实践所披露的教导。其他实施例也可以从所披露的教导中推出并使用，使得可以在不脱离本申请的范围的情况下，对本文实施例作出结构和逻辑上的替换和改变。因此，具体实施方式不应被视为具有限制意义，并且各种实施例的范围仅由所附权利要求以及这些权利要求所赋予的等价物的全部范围来限定。