CN108510295A - 用于生成行程账单信息的方法及装置 - Google Patents

Abstract

本申请实施例是关于一种用于生成行程账单信息的方法及装置，应用于互联网技术领域。方法包括：根据所述第一用户的始发地信息和目的地信息，确定获取从始发地到目的地的目标行程路线；确定所述目标行程路线中包含的收费路线；根据所述收费路线，计算所述第一用户在通过所述目标行程路线后产生的附加费信息；向所述第一用户对应的第一终端设备推送包含所述附加费信息的提示信息；若接收到所述第一终端设备发送的对于所述附加费信息的确认指令，则生成包含所述附加费信息的行程账单信息，以提高行程账单信息生成的效率。

Description

用于生成行程账单信息的方法及装置

技术领域

本申请涉及互联网技术领域，尤其涉及一种用于生成行程账单信息的方法及装置。

背景技术

目前，通过互联网进行打车服务已成为人们日常所需之一。

打车服务是基于打车服务器、服务提供端设备和服务请求端设备之间的交互来实现的。其中，服务提供端设备是司机使用的移动设备，服务请求端设备是乘客使用的移动设备。在打车过程中，车辆行驶过程中难免会因各种因素产生附加费，一般地，在产生附加费之后，需要向乘客额外收取一定的费用。在相关技术中，司机在将乘客从指定的始发地送达目标地之后，需要司机在服务提供端设备上手动输入本次行程中所产生的附加费的数额，此后，由打车服务器将包含上述数额的附加费的行程账单信息推送到服务请求端设备上，以完成行程费用结算。

可见，由于需要司机手动输入附加费的数额，造成司机操作繁琐，且造成生成行程账单信息的过程效率较低。

发明内容

为克服相关技术中存在的问题，本申请实施例提供一种用于生成行程账单信息的方法及其装置。

根据本申请实施例的第一方面，提供一种用于生成行程账单信息的方法，包括：

在确定第一用户和第二用户间的承运关系后，根据所述第一用户的始发地信息和目的地信息，确定从始发地到目的地的目标行程路线；

确定所述目标行程路线中包含的收费路线；

根据所述收费路线，计算所述第一用户在通过所述目标行程路线后产生的附加费信息；

向所述第一用户对应的第一终端设备推送包含所述附加费信息的提示信息；

若接收到所述第一终端设备发送的对于所述附加费信息的确认指令，则生成包含所述附加费信息的行程账单信息。

根据本申请实施例的第二方面，提供一种用于生成行程账单信息的信息推送装置，包括：

获取路线确定单元，用于在确定第一用户和第二用户间的承运关系后，根据所述第一用户的始发地信息和目的地信息，确定从始发地到目的地的目标行程路线；

收费路线确定单元，用于确定所述目标行程路线中包含的收费路线；

附加费信息确定单元，用于根据所述收费路线，计算所述第一用户在通过所述目标行程路线后产生的附加费信息；

提示信息推送单元，用于向所述第一用户对应的第一终端设备推送包含所述附加费信息的提示信息；

生成单元，用于在接收到所述第一终端设备发送的对于所述附加费信息的确认指令后，生成包含所述附加费信息的行程账单信息。

本申请实施例中，可根据目标行程路线，确定该目标行程路线中包含的收费路线，并根据收费路线自动计算通过该行程所产生的附加费，计算结果较为准确；并且，最终自动生成包含所述附加费信息的行程账单信息，并推送给用户，这在一定程度上可以避免用户手动添加附加费信息的操作繁琐，提高打车服务器生成行程账单信息的效率。

另一方面，通过向所述第一用户(乘客)对应的第一终端设备推送包含所述附加费信息的提示信息，并在接收到所述第一终端设备发送的对于所述附加费信息的确认指令的前提下，才会最终生成包含所述附加费信息的行程账单信息。这就避免出现在乘客不知情或不愿意通过收费路线的情况下，司机单方面选择通过收费路线，造成乘客多花钱并向平台投诉的问题，减少用户之间的纠纷，缓解服务器为应对乘客投诉而产生的处理压力。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。

图1是本申请实施例中用于实现打车事件的场景示意图；

图2是根据一示例性实施例示出的一种用于生成行程账单信息的方法的流程图；

图3是根据一示例性实施例示出的在第一终端设备上显示的用于提示乘客产生附加费的页面；

图4是根据一示例性实施例示出的在第二终端设备上显示的行程账单信息页面；

图5是根据一示例性实施例示出的用于生成行程账单信息的方法的流程图；

图6是根据一示例性实施例示出的在第二终端设备上显示的用于更改附加费金额的页面；

图7是根据一示例性实施例示出的一种电子设备的结构示意图；

图8是根据一示例性实施例示出的一种用于生成行程账单信息的装置的框图；

图9是根据一示例性实施例示出的另一种用于生成行程账单信息的装置的框图；

图10是根据一示例性实施例示出的又一种用于生成行程账单信息的装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请实施例的一些方面相一致的装置和方法的例子。

在本申请实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请实施例。在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

图1是本申请实施例中用于实现打车事件的场景示意图。如图1所示，在打车事件中，由乘客和司机两种角色来参与，为便于区分，本文可定义乘客为“第一用户”，定义司机为“第二用户”。从电子设备角度来讲，需通过打车服务器20(或称“网约车服务器”)、一个或多个由第一用户使用的第一终端设备10、及一个或多个由第二用户使用的第二终端设备30之间的交互来实现打车过程。其中终端设备可包括：手机、电脑、PDA等。在打车事件中，某一乘客可通过第一终端设备10发起从某始发地到某目的地的打车请求，此后，打车服务器20收到该打车请求后，可按照一定的规则(如距离优先规则)向一个或多个满足规则的第二终端设备30推送所述打车请求对应的打车订单，司机可以通过第二终端设备30来确认是否愿意接单，若确认愿意接单，则开始打车过程。

目前，在打车过程中，交通工具因某些因素可能会导致行驶过程中产生附加费(如：高速行驶费、过桥费)，这一类附加费通常会导致交通工具的行驶成本提高，为此，一般在产生附加费时，需要向乘客额外收取一定的费用。然而，在相关技术中，由于需要司机手动输入附加费的数额，造成司机操作繁琐。另一方面，在相关技术中，乘客一般是到达行程终点之后才被告知本次行程产生了一定的附加费，这种情况容易因乘客不知情而造成司机和乘客双方对产生的附加费金额存在分歧，甚至有些乘客会觉得司机单方面选择走收费路段而造成乘客行程费用的增加。无论何种情况，都会造成乘客的不满，甚至造成用户向平台的投诉事件的频发，造成平台服务器的处理压力大。为解决以上问题，本申请实施例提出一种用于生成行程账单信息的方法及其装置。

图2是根据一示例性实施例示出的一种用于生成行程账单信息的方法的流程图。参照图2所示，该用于生成行程账单信息的方法可应用于上述打车服务器20，该方法包括如下步骤101～106，其中：

在步骤101中，在确定第一用户和第二用户间的承运关系后，根据所述第一用户的始发地信息和目的地信息，确定从始发地到目的地的目标行程路线。

在使用“网约车”出行的场景下，第一用户为乘客，第二用户为司机，乘客可以通过第一终端设备中安装的打车软件乘客端发布出行需求，第一终端设备将乘客的出行需求发送给打车服务器，打车服务器在接收到第一终端设备发送的出行需求后，基于该出行需求中的由乘客预先输入的始发地信息及目的地信息，生成车辆调度订单，并向满足一定调度规则(如距离优先等)的若干司机发布。若某个司机通过其使用的第二终端设备中安装的打车软件司机端确认接单后，该司机与发起请求的那位乘客便建立承运关系，此后，该司机驾车去接那位乘客。

本申请一可选实施例中，步骤101可以具体包括：

根据所述第一用户的始发地信息和目的地信息并利用预设规则，规划出从始发地到目的地的最优行程路线，并将最优行程路线确定为目标行程路线。

一般地，根据始发地信息和目的地信息，打车服务器可以根据导航地图数据，规划出至少一条可行的从始发地前往目的地的行程路线。然而，通常乘客和司机均倾向于选择一条最优的行程路径开始行程，而最优行程路径的过程可以根据预设规则来确定。其中，预设规则可以是：费用最低原则、或耗时最短原则、或避免拥堵原则、或高速优先原则等或上述原则的任意组合。这些预设原则可以是打车平台来设定的，也可以是乘客或司机预先设定的。

本申请另一可选实施例中，步骤101可以具体包括：

根据所述第一用户的始发地信息和目的地信息，规划至少一条从始发地到目的地的可选行程路线，并将所述第一用户从所述至少一条可选行程路线中选择的行程路线确定为目标行程路线。

例如，始发地为A小区，目的地为B小区，打车服务器自动规划出3条行程路线分别为路线1、路线2和路线3，并向乘客端的导航地图上展示这三条路线，并提示乘客选择一条路线，此后，若第一用户选择路线3，则将路线3确定为第一用户的目标行程路线。

在步骤102中，确定所述目标行程路线中包含的收费路线。

在一实施例中，可根据预设的地图数据库，确定所述行程路线中包含的收费路线，其中所述地图数据库中存储有与收费路线对应的位置信息。

本申请实施例中，预设的地图数据库可以为GIS(Geographic InformationSystem，地理信息系统)地图，其中，GIS地图中包含多个地理实体，具体的包括：饭店、酒店、大厦、收费站、道路、街道、乡镇、城市等。其中，对于收费路线，如某条高速，由于路线是由若干个地理点组成，可以确定与该收费路线对应的位置点集合，从而得到地图上所有收费路线对应的位置信息集合。

在步骤103中，根据所述收费路线，计算所述第一用户在通过所述目标行程路线后产生的附加费。

本申请实施例中，预设的地图数据库中也可以记录有各个收费路线的收费标准，此时可以从预设的地图数据库中获得所涉及的收费路线的收费标准。此外，也可以从其他的途径获得所涉及的收费标准，本申请实施例对此不作限定。

在一实施例中，上述步骤103可包括：

根据所述收费路线的长度和收费规则，计算所述第一用户在通过所述目标行程路线后产生的附加费。

例如，乘客的行程中包含20公里长的高速，则根据该条高速的收费规则：7座以下车辆0.5元/公里，计算得到附加费是10元。

在另一实施例中，上述步骤103可包括：

根据所述收费路线包括的收费站信息和收费规则，计算所述第一用户在通过所述目标行程路线后产生的附加费。

例如，收费路线中包含收费站A和收费站B，确定从收费站A上高速、并收费站B下高速，高速费是10元。当然，如果此路线中还包括其他收费标准，则累加计算。需说明的是，本文所述的附加费可包括但不限于高速费或过桥费，如地方级收费公路、或其他形式的收费公路、特定区域的山路等。

在步骤104中，向所述第一用户对应的第一终端设备推送包含所述附加费信息的提示信息。

如上文所提到的，在“网约车”场景中，为确保乘客在行程开始之前对行程产生附加费信息有一定知情权，可以在计算出附加费信息时，向乘客使用的第一终端设备推送包含该附加费信息的提示信息的方式，来确保用户能够在行程开始前便知道这一情况。

在步骤105中，若接收到所述第一终端设备发送的对于所述附加费信息的确认指令，则生成包含所述附加费信息的行程账单信息。

乘客在行程开始之前，可以收到打车服务器推送的上述提示信息，如：“本次行程可能因走高速路段需要产生20元的行程附加费”。并向乘客提供“同意”和“不同意”的选项，当乘客选择“同意”时，则通知司机开始行程，并在最终乘客被送到目的地之后，生成包含上述附加费的行程账单信息，完成费用支付。否则，则无法生成行程账单信息。从而可避免在乘客不知情的情况下产生一笔包含行程附加费的账单，合理避免纠纷事件。

并且，最终自动生成包含所述附加费信息的行程账单信息，并推送给用户，这在一定程度上可以避免用户手动添加附加费信息的操作繁琐，提高打车服务器生成行程账单信息的效率。

与上述过程对应的，在可选的实施方式中，方法还可以包括步骤106，其中：

在步骤106中，将所述行程账单信息发送至所述第二用户对应的第二终端设备，以让司机查看到所生成的行程账单信息。

当司机将乘客送达到目的地之后，需要由打车服务器生成本次打车事件对应的行程账单信息，以完成由乘客向司机支付打车费用的过程，该过程是从乘客使用的移动设备关联的乘客账户中，将一定数额的打车费用支付到司机使用的移动设备关联的司机账户内，上述“乘客账户”和“司机账户”可以是任意形式的互联网金融账户。通常，行程账单信息可包括：始发地信息，目的地信息，耗用时长、打车费用的总额、司机车辆信息等。

以下将结合图3和图4来说明，如图3所示，在确定司机和乘客之间的承运关系之后，在乘客使用的第一终端设备上可以显示第一页面11，该第一页面11的路线选择区域110用于展示规划到的至少一条可选行程路线，并且，可以预估每一可选行程路线可能产生的打车费用，在打车费用中包含附加费时也一并列出。如果乘客选定的是路线2，第一终端设备会由第一页面11跳转到第二页面12，并且于此同时，打车服务器可以向该第一终端设备推送一则提示消息120并在该第二页面12内显示。例如，所述提示消息120的内容是：“通过路线2需要产生高速费，XX元。”，此后，如果乘客点击确认按键122，则表明乘客同意走包含高速路的路线2来完成打车过程，也避免了和司机间的沟通。如果乘客没有点击同意按键122，则司机可以提醒用户查看一下APP的消息，并进行确认。

在乘客预先点击了确认按键122之后，打车服务器收到第一终端设备发送的确认指令，此后，当打车服务器监测到乘客被送达到指定的行程终点之后，则可以自动生成行程账单信息，并将行程中实际产生的附加费添加到上述行程账单信息内。接着，打车服务器将行程账单信息发送到司机使用的第二终端设备上，以供司机查看并确认。如图4所示，第二终端设备上可显示第三页面31，该第三页面31包括：行程费用的总额、行程费用中包含的附加费金额、用于修改附加费的修改按键310、用于确认费用信息无误的“完成，继续接单”按键312，等等。当司机点击“完成，继续接单”按键312后，完成打车过程并支付费用，并将行程账单信息发给乘客。

图5是根据一示例性实施例示出的另一种用于生成行程账单信息的方法的流程图。在实际情况下，由于各种突发状况行程开始前所确定的目标行程路线和实际的行程路线可能会不一致，例如，因修路而临时更改行程路线。这样，若最终还是按照行程开始前确定的目标行程路线来计算最终的附加费，并生成账单信息，显然是不合理的。为此，出现了乘客或司机在行程结束或行程进行中对行程附加费金额进行修改的需求。参照图5所示，本实施例便是对附加费信息进行修改的实现过程，该方法仍然可被应用于打车服务器，在以上步骤106之后，该方法还可包括如下步骤107至步骤112，其中：

在步骤106中，将所述行程账单信息发送至所述第二用户对应的第二终端设备，以让司机查看到所生成的行程账单信息，并便于司机进行修改。

在步骤107中，第二用户确认所述行程账单信息是否有误。其中，若打车服务器是否接收到第二终端设备反馈的用于指示第二用户对行程账单信息确认无误的反馈信息，则表明第二用户确认所述行程账单信息无需修改，进入步骤112；反之，若打车服务器是否接收到第二终端设备反馈的用于指示第二用户对行程账单信息确认有误的反馈信息，则表明第二用户确认所述行程账单信息需要修改，进入步骤108。在步骤108中，接收所述第二终端设备发送的包含修改值的费用修改指令；

在步骤109中，将所述行程账单信息中的附加费的数额修改为所述修改值；在修改完成之后进入下述步骤110。

在步骤110中，将所述行程账单信息发送至所述第一终端设备。

在步骤111中，第一用户确认修改后的所述行程账单信息是否有误。同上，若打车服务器接收到第一终端设备反馈的用于指示确认无误的信息，则进入步骤112，结束行程并完成费用支付。反之，若打车服务器接收到第一终端设备反馈的用于指示确认有误的信息，则流程返回步骤107，由司机和乘客继续协商双方认可的附加费信息。

如图6所示，在一种示例性的网约车场景中，在行程结束时，司机端和乘客端均可以显示最终的行程账单信息，并可以查看到附加费的金额，此时若乘客对附加费存在异议，可以与司机协商修改。若司机同意修改，则可以在页面中点击“修改附加费”，此后调整到修改页面，司机可以输入修改后的金额，并点击“确认修改”，完成附加费修改过程。

与用于生成行程账单信息的方法的实施例对应，本申请实施例还提供了用于生成行程账单信息的装置的实施例，以下将结合图7～图10进行介绍。

图7是根据一示例性实施例示出的一种电子设备的示意图。请参考图7，在硬件层面，该电子设备包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成上述用于生成行程账单信息的装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

图8是根据一示例性实施例示出的一种用于生成行程账单信息的装置的框图。如图8所示，在本实施例中，一种用于生成行程账单信息的装置，可以包括路线确定单元301、收费路线确定单元302、附加费信息确定单元303、提示信息推送单元304及生成单元305。其中：

路线确定单元301，用于在确定第一用户和第二用户间的承运关系后，根据所述第一用户的始发地信息和目的地信息，确定从始发地到目的地的目标行程路线。

在一可选实施例中，所述路线确定单元301具体用于：

根据所述第一用户的始发地信息和目的地信息并利用预设规则，规划出从始发地到目的地的最优行程路线，并将最优行程路线确定为目标行程路线；

一般地，根据始发地信息和目的地信息，打车服务器可以根据导航地图数据，规划出至少一条可行的从始发地前往目的地的行程路线。然而，通常乘客和司机均倾向于选择一条最优的行程路径开始行程，而最优行程路径的过程可以根据预设规则来确定。其中，预设规则可以是：费用最低原则、或耗时最短原则、或避免拥堵原则、或高速优先原则等或上述原则的任意组合。这些预设原则可以是打车平台来设定的，也可以是乘客或司机预先设定的。

在另一可选实施例中，所述路线确定单元301具体用于：

根据所述第一用户的始发地信息和目的地信息，规划至少一条从始发地到目的地的可选行程路线，并将所述第一用户从所述至少一条可选行程路线中选择的行程路线确定为目标行程路线。

收费路线确定单元302，用于确定所述目标行程路线中包含的收费路线。

在一实施例中，所述收费路线确定单元302具体用于：

根据预设的地图数据库，确定所述目标行程路线中包含的收费路线；其中所述地图数据库中存储有与收费路线对应的位置信息。

附加费信息确定单元303，用于根据所述收费路线，计算所述第一用户在通过所述目标行程路线后产生的附加费信息。

所述附加费信息确定单元303可以具体用于：

根据所述收费路线的长度和收费规则，计算所述第一用户在通过所述目标行程路线后产生的附加费信息；或，

根据所述收费路线包括的收费站信息和收费规则，计算所述第一用户在通过所述目标行程路线后产生的附加费信息。

提示信息推送单元304，用于向所述第一用户对应的第一终端设备推送包含所述附加费信息的提示信息。

如上文所提到的，在“网约车”场景中，为确保乘客在行程开始之前对行程产生附加费信息有一定知情权，可以在计算出附加费信息时，向乘客使用的第一终端设备推送包含该附加费信息的提示信息的方式，来确保用户能够在行程开始前便知道这一情况。

生成单元305，用于在接收到所述第一终端设备发送的对于所述附加费信息的确认指令后，生成包含所述附加费信息的行程账单信息。通过上述存在于打车服务器上的装置，乘客在行程开始之前，可以收到打车服务器推送的上述提示信息，如：“本次行程可能因走高速路段需要产生20元的行程附加费”。并向乘客提供“同意”和“不同意”的选项，当乘客选择“同意”时，则通知司机开始行程，并在最终乘客被送到目的地之后，生成包含上述附加费的行程账单信息，完成费用支付。否则，则无法生成行程账单信息。从而可避免在乘客不知情的情况下产生一笔包含行程附加费的账单，合理避免纠纷事件。

并且，最终自动生成包含所述附加费信息的行程账单信息，并推送给用户，这在一定程度上可以避免用户手动添加附加费信息的操作繁琐，提高打车服务器生成行程账单信息的效率。

图9是根据一示例性实施例示出的另一种用于生成行程账单信息的装置的框图。如图9所示，在上述图8所示的实施例的基础上，所述装置还包括：

账单信息发送单元306，用于将所述行程账单信息发送至所述第二用户对应的第二终端设备。

图10是根据一示例性实施例示出的另一种用于生成行程账单信息的装置的框图。如图10所示，在上述图9所示的实施例的基础上，为了满足乘客或司机在行程结束或行程进行中对行程附加费金额进行修改的需求，所述装置还可以包括：

接收单元307，用于接收所述第二终端设备发送的包含修改值的费用修改指令；

修改单元308，用于将所述行程账单信息中的附加费的数额修改为所述修改值；

第二发送单元309，用于将修改后的所述行程账单信息发送至所述第一终端设备。对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本领域技术人员在考虑说明书及实践这里公开的公开后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims (12)

1.一种用于生成行程账单信息的方法，其特征在于，包括：

在确定第一用户和第二用户间的承运关系后，根据所述第一用户的始发地信息和目的地信息，确定从始发地到目的地的目标行程路线；

确定所述目标行程路线中包含的收费路线；

根据所述收费路线，计算所述第一用户在通过所述目标行程路线后产生的附加费信息；

向所述第一用户对应的第一终端设备推送包含所述附加费信息的提示信息；

若接收到所述第一终端设备发送的对于所述附加费信息的确认指令，则生成包含所述附加费信息的行程账单信息。

2.根据权利要求1所述的方法，其特征在于，在生成包含所述附加费信息的行程账单信息之后，所述方法还包括：

将所述行程账单信息发送至所述第二用户对应的第二终端设备。

3.根据权利要求1所述的方法，其特征在于，所述确定所述目标行程路线中包含的收费路线，包括：

根据预设的地图数据库，确定所述目标行程路线中包含的收费路线；其中所述地图数据库中存储有与收费路线对应的位置信息。

4.根据权利要求1所述的方法，其特征在于，所述根据所述第一用户的始发地信息和目的地信息，确定从始发地到目的地的目标行程路线，包括：

根据所述第一用户的始发地信息和目的地信息并利用预设规则，规划出从始发地到目的地的最优行程路线，并将最优行程路线确定为目标行程路线；

或，

根据所述第一用户的始发地信息和目的地信息，规划至少一条从始发地到目的地的可选行程路线，并将所述第一用户从所述至少一条可选行程路线中选择的行程路线确定为目标行程路线。

5.根据权利要求1所述的方法，其特征在于，所述根据所述收费路线，计算所述第一用户在通过所述目标行程路线后产生的附加费信息，包括：

根据所述收费路线的长度和收费规则，计算所述第一用户在通过所述目标行程路线后产生的附加费信息；或，

根据所述收费路线包括的收费站信息和收费规则，计算所述第一用户在通过所述目标行程路线后产生的附加费信息。

6.根据权利要求2所述的方法，其特征在于，在将所述行程账单信息发送至所述第二用户对应的第二终端设备后，所述方法还包括：

接收所述第二终端设备发送的包含修改值的费用修改指令；

将所述行程账单信息中的附加费的数额修改为所述修改值；

将修改后的所述行程账单信息发送至所述第一终端设备。

7.一种用于生成行程账单信息的装置，其特征在于，包括：

路线确定单元，用于在确定第一用户和第二用户间的承运关系后，根据所述第一用户的始发地信息和目的地信息，确定从始发地到目的地的目标行程路线；

收费路线确定单元，用于确定所述目标行程路线中包含的收费路线；

附加费信息确定单元，用于根据所述收费路线，计算所述第一用户在通过所述目标行程路线后产生的附加费信息；

提示信息推送单元，用于向所述第一用户对应的第一终端设备推送包含所述附加费信息的提示信息；

生成单元，用于在接收到所述第一终端设备发送的对于所述附加费信息的确认指令后，生成包含所述附加费信息的行程账单信息。

8.根据权利要求7所述的装置，其特征在于，所述装置还包括：

账单信息发送单元，用于将所述行程账单信息发送至所述第二用户对应的第二终端设备。

9.根据权利要求7所述的装置，其特征在于，所述收费路线确定单元具体用于：

根据预设的地图数据库，确定所述目标行程路线中包含的收费路线；其中所述地图数据库中存储有与收费路线对应的位置信息。

10.根据权利要求7所述的装置，其特征在于，所述路线确定单元具体用于：

根据所述第一用户的始发地信息和目的地信息并利用预设规则，规划出从始发地到目的地的最优行程路线，并将最优行程路线确定为目标行程路线；

或，

根据所述第一用户的始发地信息和目的地信息，规划至少一条从始发地到目的地的可选行程路线，并将所述第一用户从所述至少一条可选行程路线中选择的行程路线确定为目标行程路线。

11.根据权利要求7所述的装置，其特征在于，所述附加费信息确定单元用于：

根据所述收费路线的长度和收费规则，计算所述第一用户在通过所述目标行程路线后产生的附加费信息；或，

根据所述收费路线包括的收费站信息和收费规则，计算所述第一用户在通过所述目标行程路线后产生的附加费信息。

12.根据权利要求8所述的装置，其特征在于，所述装置还包括：

接收单元，用于接收所述第二终端设备发送的包含修改值的费用修改指令；

修改单元，用于将所述行程账单信息中的附加费的数额修改为所述修改值；

第二发送单元，用于将修改后的所述行程账单信息发送至所述第一终端设备。