订单标签添加方法、装置、电子设备及可读存储介质与流程

本公开的实施例涉及订单处理技术领域，尤其涉及一种订单标签添加方法、装置、电子设备及计算机可读存储介质。

背景技术：

随着经济水平的提高和生活节奏的加快，打车已经成为人们生活中的一种常见的出行方式。

在用户需要开具打车发票时，在常见的一些app(application，应用程序)中均是通过在打车订单的筛选页面内支持日期、金额、车型、归属地来进行筛选，而在用户打车频次较高时，可能会将日常打车、出差打车和加班打车等情况的订单混淆在一起，用户在查找订单时需要逐页一一查找，导致用户时间的浪费，降低了用户使用体验。

技术实现要素：

本公开的实施例提供了一种订单标签添加方法、装置、电子设备及计算机可读存储介质，用以帮助用户快速查找需要开具发票的订单，节省用户的时间。

根据本公开的实施例的第一方面，提供了一种订单标签添加方法，包括：

接收用户在订单页面针对第一订单执行的标记操作；

根据所述标记操作，确定所述第一订单对应的第一发票场景类型；

根据所述第一发票场景类型，为所述第一订单添加相应的发票场景标签。

可选地，所述接收用户在订单页面针对第一订单执行的标记操作，包括：

接收用户在所述订单页面执行发票标记的触发操作；

基于所述触发操作，将与所述用户关联的至少一个订单和所述至少一个订单对应的发票场景类型推送至所述订单页面；所述至少一个订单包括所述第一订单；

获取所述用户对所述第一订单执行的发票场景类型的标记操作。

可选地，在所述基于所述触发操作，将与所述用户关联的至少一个订单和所述至少一个订单对应的发票场景类型推送至所述订单页面之后，还包括：

获取所述用户对所述至少一个订单中的第二订单执行的发票场景类型的标记删除操作；

根据所述标记删除操作，取消对所述第二订单已添加的发票场景类型标签；

接收所述用户对所述第二订单执行的发票场景类型标记操作；

根据所述发票场景类型标记操作，确定所述第二订单对应的第二发票场景类型；

根据所述第二发票场景类型，为所述第二订单添加相应的发票场景标签。

可选地，所述根据所述第一发票场景类型，为所述第一订单添加相应的发票场景标签，包括：

获取所述第一订单对应的下单时间；

根据所述下单时间和所述第一发票场景类型，为所述第一订单添加相应的时间标签和发票场景标签。

可选地，在所述根据所述第一发票场景类型，为所述第一订单添加所述相应的发票场景标签之后，还包括：

获取所述用户所需查询的第一发票场景类型；

将标记为所述第一发票场景类型的至少一个订单展示于与所述用户关联的查询界面；所述至少一个订单包括所述第一订单。

可选地，在所述根据所述第一发票场景类型，为所述第一订单添加所述相应的发票场景标签之后，还包括：

接收所述用户对所述第一订单对应的发票场景标签执行的编辑操作；

根据所述编辑操作，确定所述第一订单对应的编辑场景标签；

为所述第一订单添加所述编辑场景标签。

根据本公开的实施例的第二方面，提供了一种订单标签添加装置，包括：

标记操作接收模块，用于接收用户在订单页面针对第一订单执行的标记操作；

第一类型确定模块，用于根据所述标记操作，确定所述第一订单对应的第一发票场景类型；

发票标签添加模块，用于根据所述第一发票场景类型，为所述第一订单添加相应的发票场景标签。

可选地，所述标记操作接收模块包括：

触发操作接收单元，用于接收用户在所述订单页面执行发票标记的触发操作；

发票类型推送单元，用于基于所述触发操作，将与所述用户关联的至少一个订单和所述至少一个订单对应的发票场景类型推送至所述订单页面；所述至少一个订单包括所述第一订单；

标记操作获取单元，用于获取所述用户对所述第一订单执行的发票场景类型的标记操作。

可选地，还包括：

标记删除操作获取模块，用于获取所述用户对所述至少一个订单中的第二订单执行的发票场景类型的标记删除操作；

发票标签取消模块，用于根据所述标记删除操作，取消对所述第二订单已添加的发票场景类型标签；

场景标记操作接收模块，用于接收所述用户对所述第二订单执行的发票场景类型标记操作；

第二类型确定模块，用于根据所述发票场景类型标记操作，确定所述第二订单对应的第二发票场景类型；

发票场景标签添加模块，用于根据所述第二发票场景类型，为所述第二订单添加相应的发票场景标签。

可选地，所述发票标签添加模块包括：

下单时间获取单元，用于获取所述第一订单对应的下单时间；

发票标签添加单元，用于根据所述下单时间和所述第一发票场景类型，为所述第一订单添加相应的时间标签和发票场景标签。

可选地，还包括：

第一类型查询模块，用于获取所述用户所需查询的第一发票场景类型；

订单推送模块，用于将标记为所述第一发票场景类型的至少一个订单展示于与所述用户关联的查询界面；所述至少一个订单包括所述第一订单。

可选地，还包括：

编辑操作接收模块，用于接收所述用户对所述第一订单对应的发票场景标签执行的编辑操作；

编辑场景标签确定模块，用于根据所述编辑操作，确定所述第一订单对应的编辑场景标签；

编辑场景标签添加模块，用于为所述第一订单添加所述编辑场景标签。

根据本公开的实施例的第三方面，提供了一种电子设备，包括：

处理器、存储器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序时实现上述任一项所述的订单标签添加方法。

根据本公开的实施例的第四方面，提供了一种计算机可读存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行上述任一项所述的订单标签添加方法。

本公开的实施例提供了一种订单标签添加方案，通过接收用户在订单页面针对第一订单执行的标记操作，根据标记操作确定第一订单对应的第一发票场景类型，根据第一发票场景类型为第一订单添加相应的发票场景标签。本公开的实施例通过为订单添加相应的发票场景标签，从而实现了订单的发票场景标记，即实现订单在不同场景下的发票归类，进而，在后续用户查找的过程中，可以直接根据所需发票的场景快速查找到开票订单，无需用户在行程订单中逐页查找，节省了用户查找开票订单的时间，提高了用户的使用体验。

附图说明

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

图1示出了本公开实施例提供的一种订单标签添加方法的步骤流程图；

图2示出了本公开实施例提供的另一种订单标签添加方法的步骤流程图；

图2a示出了本公开实施例提供的一种查找加班场景下的订单的示意图；

图2b示出了本公开实施例提供的一种内部交互逻辑的示意图；

图3示出了本公开实施例提供的一种订单标签添加装置的结构示意图；

图4示出了本公开实施例提供的另一种订单标签添加装置的结构示意图。

具体实施方式

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

实施例一

参照图1，示出了本公开实施例提供的一种订单标签添加方法的步骤流程图，该订单标签添加方法可以应用于服务器，也可以是安装于移动终端中的客户端，如图1所示，该订单标签添加方法具体可以包括如下步骤：

步骤101：接收用户在订单页面针对第一订单执行的标记操作。

本公开实施例可以应用于对所需开发票的订单进行发票场景类型标记的场景中。

第一订单是指需要进行发票场景类型标记的订单。在本实施例中，第一订单可以为打车的订单，也可以为餐厅消费的订单等等，具体地，可以根据实际情况而定，本实施例对此不加以限制。

标记操作是指对第一订单执行的标记该订单的发票场景的操作。

在用户执行完一个订单(如打车订单等)之后或者之前，可以在该订单对应的页面内对该订单所属发票的场景类型添加标记，具体地，在订单页面内设置有发票标记助手(即一个按钮)，在用户需要对某个订单添加发票场景类型标记时，可以先在该订单页面内点击发票标记助手，进而在订单页面内可以显示第一订单，及第一订单对应的多个发票场景类型，用户可以根据第一订单对应的场景，点击相应的发票场景类型，以触发点击操作，例如，在第一订单的生成场景为加班场景时，可以点击第一订单对应的发票场景类型：加班场景类型。

可以理解地，上述示例仅是为了更好地理解本公开实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

在接收到用户在订单页面针对第一订单执行的标记操作之后，执行步骤102。

步骤102：根据所述标记操作，确定所述第一订单对应的第一发票场景类型。

第一发票场景类型是指第一订单所对应的发票场景类型。发票场景类型是指在指定场景下生成的所需开具发票的类型，例如，在订单为加班场景下生成的订单时，则该订单对应的发票场景类型为加班场景类型；而在订单为出差行程中生成的订单时，则该订单对应的发票场景类型为差旅场景类型。

当然，在具体实现中，订单的发票场景类型是由用户自主标记的，上述示例仅是作为解释发票场景类型而列举的示例，不作为对本实施例的唯一限定。

在接收到用户对第一订单执行的标记操作时，可以获取用户执行标记操作时选择的发票场景类型，以作为第一订单的第一发票场景类型。

在根据标记操作确定第一订单对应的第一发票场景类型之后，执行步骤103。

步骤103：根据所述第一发票场景类型，为所述第一订单添加相应的发票场景标签。

发票场景标签是指为第一订单添加的用于指示第一订单的开具发票的场景的标签。例如，在第一订单为用户加班时打车创建的订单时，用户可以标记第一订单的发票场景类型为：加班场景类型，此时可以为第一订单添加加班场景类型对应的标签，如“加班”等。

在确定用户为第一订单标记的第一发票场景类型之后，可以根据第一发票场景类型为第一订单添加相应的发票场景标签，即实现对第一订单在开具发票时的归类，进而，在后续过程中，用户需要开具某个场景下的订单对应的发票时，可以直接根据预先添加的标签实现订单快速查找，以达到快速开具发票的目的。

本公开实施例提供的订单标签添加方法，通过接收用户在订单页面针对第一订单执行的标记操作，根据标记操作确定第一订单对应的第一发票场景类型，根据第一发票场景类型为第一订单添加相应的发票场景标签。本公开的实施例通过为订单添加相应的发票场景标签，从而实现了订单的发票场景标记，即实现订单在不同场景下的发票归类，进而，在后续用户查找的过程中，可以直接根据所需发票的场景快速查找到开票订单，无需用户在行程订单中逐页查找，节省了用户查找开票订单的时间，提高了用户的使用体验。

实施例二

参照图2，示出了本公开实施例提供的另一种订单标签添加方法的步骤流程图，该订单标签添加方法可以应用于服务器，也可以是安装于移动终端中的客户端，如图2所示，该订单标签添加方法具体可以包括如下步骤：

步骤201：接收用户在所述订单页面执行发票标记的触发操作。

本公开实施例可以应用于对所需开发票的订单进行发票场景类型标记的场景中。

触发操作是指用户在订单页面对订单执行发票标记时触发的操作。

在某些示例中，触发操作可以是用户点击发票标记对应的按钮触发的操作，例如，在订单页面内预先设置有“发票标记助手”按钮，在用户需要对订单执行发票场景类型标记，可以通过点击该“发票标记助手”按钮，以生成发票标记的触发操作。

在某些示例中，触发操作可以是用户输入的语音触发的操作，例如，在订单页面内预先设置有语音输入接口，用户可以通过该语音输入接口输入“发票标记”等语音，以生成发票标记的触发操作。

当然，不仅限于此，在具体实现中，还可以采用其它方式生成执行发票标记的触发操作，具体地，可以根据业务需求而定，本实施例对此不加以限制。

在接收到用户在订单页面执行发票标记的触发操作之后，执行步骤202。

步骤202：基于所述触发操作，将与所述用户关联的至少一个订单和所述至少一个订单对应的发票场景类型推送至所述订单页面。

至少一个订单是指预先存储的用户已经下单的订单，可以理解地，至少一个订单可以为用户已下单还未完成的订单，如，用户打车的订单，下单且被司机接单但是还未将用户送往指定地点的订单等。至少一个订单还可以为已经完成的订单，如，用户点外卖的订单，且该订单已经送达给用户等。

可以理解地，上述示例仅是为了更好地理解本公开实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

发票场景类型是指在指定场景下生成的所需开具发票的类型，例如，在订单为加班场景下生成的订单时，则该订单对应的发票场景类型为加班场景类型；而在订单为出差行程中生成的订单时，则该订单对应的发票场景类型为差旅场景类型。

在本实施例中，可以预先为某种类型的订单设置一种或多种发票场景类型，例如，订单以打车订单为例，可以设置相应的发票场景类型，如“加班”、“差旅”、“其它”等类型，具体可以根据实际情况而定，本实施例对此不加以限制。

在接收到用户在订单页面执行发票标记的触发操作之后，可以根据触发操作，将与用户关联的至少一个订单和至少一个订单对应的发票场景类型推送至订单页面，具体地，可以将与用户关联的至少一个订单展示于订单页面，并在每个订单后展示相应的发票场景类型。

可以理解地，至少一个订单中包含有下述步骤中提及的第一订单。

在基于触发操作，将与用户关联的至少一个订单和至少一个订单对应的发票类型推送至订单页面之后，执行步骤203。

步骤203：获取所述用户对所述第一订单执行的发票场景类型的标记操作。

第一订单是指需要进行发票场景类型标记的订单。在本实施例中，第一订单可以为打车的订单，也可以为餐厅消费的订单等等，具体地，可以根据实际情况而定，本实施例对此不加以限制。

标记操作是指对第一订单执行的标记该订单的发票场景的操作。

在用户执行完一个订单(如打车订单等)之后或者之前，可以在该订单对应的页面内对该订单所属发票的场景类型添加标记，具体地，在订单页面内设置有发票标记助手(即一个按钮)，在用户需要对某个订单添加发票场景类型标记时，可以先在该订单页面内点击发票标记助手，进而在订单页面内可以显示第一订单，及第一订单对应的多个发票场景类型，用户可以根据第一订单对应的场景，点击相应的发票场景类型，以触发点击操作，例如，在第一订单的生成场景为加班场景时，可以点击第一订单对应的发票场景类型：加班场景类型。

可以理解地，上述示例仅是为了更好地理解本公开实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

在获取到用户在订单页面针对第一订单执行的标记操作之后，执行步骤204。

步骤204：根据所述标记操作，确定所述第一订单对应的第一发票场景类型。

第一发票场景类型是指第一订单所对应的发票场景类型。发票场景类型是指在指定场景下生成的所需开具发票的类型，例如，在订单为加班场景下生成的订单时，则该订单对应的发票场景类型为加班场景类型；而在订单为出差行程中生成的订单时，则该订单对应的发票场景类型为差旅场景类型。

当然，在具体实现中，订单的发票场景类型是由用户自主标记的，上述示例仅是作为解释发票场景类型而列举的示例，不作为对本实施例的唯一限定。

在接收到用户对第一订单执行的标记操作时，可以获取用户执行标记操作时选择的发票场景类型，以作为第一订单的第一发票场景类型。

此外，在本实施例中，还可以由用户自行编辑订单的发票场景标签，具体地，可以结合下述具体实现方式进行详细描述。

在本实施的一种具体实现方式中，在上述步骤204之后，还可以包括：

步骤m1：接收所述用户对所述第一订单对应的发票场景标签执行的编辑操作。

在本实施例中，编辑操作是指用户执行的对订单已添加发票场景标签进行手动编辑的操作。

在某些示例中，编辑操作可以是用户单击或者双击订单已添加的发票场景标签触发的操作，例如，在第一订单添加了发票场景标签之后，可以在订单页面内，第一订单的上方或者左方显示第一订单的发票场景标签，在用户单击或者双击该发票场景标签时，即可触发该发票场景标签的编辑操作。

在某些示例中，编辑操作可以是用户输入的发票场景标签编辑语音触发的操作，例如，在订单页面内预先设置有语音输入接口，用户可以通过该语音输入接口输入一段语音，如“编辑xx订单的发票场景标签”等，以触发对该订单的发票场景标签的编辑操作。

可以理解地，上述示例仅是为了更好地理解本实施例而列举的示例，不作为对本实施例的唯一限制。

在接收到用户对第一订单执行的编辑操作之后，执行步骤m2。

步骤m2：根据所述编辑操作，确定所述第一订单对应的编辑场景标签。

编辑场景标签是指用户对第一订单重新编辑的发票场景标签。

在接收到用户对第一订单执行的编辑操作之后，可以实时获取用户为第一订单重新编辑的发票场景标签，即编辑场景标签。

在确定第一订单对应的编辑场景标签之后，执行步骤m3。

步骤m3：为所述第一订单添加所述编辑场景标签。

在获取到用户为第一订单重新编辑的编辑场景标签之后，可以为第一订单添加编辑场景标签，从而实现第一订单的发票场景标签的更新，可以达到用户自定义设置订单的发票场景标签的。

在根据标记操作确定第一订单对应的第一发票场景类型之后，执行步骤205。

步骤205：获取所述第一订单对应的下单时间。

下单时间是指用户开始创建第一订单时的时间，也即用户下单的时间，例如，在第一订单为用户在2020年3月29日，12:30创建时，则第一订单对应的下单时间即为2020年3月29日，12:30。

可以理解地，上述示例仅是为了更好地理解本公开实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

在后台系统中，除了保存与用户关联的第一订单外，还可以保存第一订单的创建时间，即下单时间，进而，在确定用户对第一订单标记的第一发票场景类型后，还可以从系统中获取第一订单对应的下单时间。

在获取到第一订单对应的下单时间之后，执行步骤206。

步骤206：根据所述下单时间和所述第一发票场景类型，为所述第一订单添加相应的时间标签和发票场景标签。

时间标签是指为第一订单添加的用于指示第一订单的创建时间的标签。

发票场景标签是指为第一订单添加的用于指示第一订单的开具发票的场景的标签。例如，在第一订单为用户加班时打车创建的订单时，用户可以标记第一订单的发票场景类型为：加班场景类型，此时可以为第一订单添加加班场景类型对应的标签，如“加班”等。

在获取第一订单对应的下单时间和第一发票场景类型之后，可以根据下单时间和第一发票场景类型为第一订单添加相应的时间标签和发票场景标签，具体地底部实现过程可以如图2b所示：用户在订单页面点击发票标记助手，通过点击发票场景类型可以生成相应的标记请求，并将该标记请求通过api(applicationprogramminginterface，应用程序接口)(api接口为客户端与服务器交互的接口)将与用户关联的订单的订单号和标记号(标记号用于区分订单的发票场景类型)发送给订单系统，并在订单内记录相应的订单号和标记号字段。

在为第一订单添加了相应的时间标签和发票场景标签之后，用户可以在后续过程中，需要开具第一订单对应的发票时，可以根据时间标签和/或发票场景标签实现订单的快速查找，从而能够达到快速开具发票的目的。

步骤207：获取所述用户所需查询的第一发票场景类型。

在为订单添加了相应的发票场景标签之后，在用户需要查询第一发票场景类型下的订单时，可以由用户输入所需查询的发票场景类型，此步骤中将第一发票场景类型作为用户所需查询的发票场景类型。如图2b所示，在用户进入发票标记界面之后，可以通过输入所需查询的发票场景类型，如h5标记号等，api以该发票场景类型作为索引，查询该发票场景类型下的所有订单。

在获取用户所需查询的第一发票场景类型之后，执行步骤208。

步骤208：将标记为所述第一发票场景类型的至少一个订单展示于与所述用户关联的查询界面；所述至少一个订单包括所述第一订单。

在获取到用户所需查询的第一发票场景类型之后，可以将标记为第一发票场景类型的至少一个订单展示于与用户关联的查询界面，在至少一个订单中包含了上述已经添加了标签的第一订单。如图2a所示，在用户需要开具加班场景的发票时，可以输入“加班场景”，从而获取位于加班场景的订单显示于终端界面内，如图所示。

在将标记为第一发票场景类型的至少一个订单展示于与用户关联的查询界面之后，执行步骤209。

步骤209：获取所述用户对所述至少一个订单中的第二订单执行的发票场景类型的标记删除操作。

第二订单是指需要取消发票场景类型标记的订单。可以理解地，本实施例中的第二订单可以为与第一订单相同的订单，也可以为与第一订单不相同的订单，具体地，可以根据实际情况而定，本实施例对此不加以限制。

标记删除操作是指用于取消对订单添加的发票类型标签的操作。

在某些示例中，标记删除操作可以为用户点击第二订单的第二发票场景类型的标签触发的操作，例如，用户点击订单的加班标签，标签消失等。

在某些示例中，标记删除操作可以为用户输入的语音控制取消发票场景类型对应的标签的操作，例如，用户通过查询页面内的语音输入接口，输入一段语音“取消xx订单的加班标签”等，通过该语音可以取消该订单的加班标签等。

可以理解地，上述示例仅是为了更好地理解本公开实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

在获取到用户对至少一个订单中的第二订单执行的发票场景类型的标记删除操作之后，执行步骤210。

步骤210：根据所述标记删除操作，取消对所述第二订单已添加的发票场景类型标签。

在接收到用户对第二订单执行标记删除操作之后，可以根据该标记删除操作，取消对第二订单已经添加的发票场景类型标签。该过程实现了对发票场景类型标签的删除过程，可以由用户自定义更改设置订单的发票场景类型标签。

步骤211：接收所述用户对所述第二订单执行的发票场景类型标记操作。

发票场景类型标记操作是指用户执行的对第二订单执行的添加发票场景类型的操作。

在用户对第二订单执行标记删除操作之后，先前为第二订单添加的发票场景类型的标签即被取消，此时用户可以自定义设置第二订单的其它标签，即实现对第二订单的发票场景类型的标签更改操作。

在某些示例中，发票场景类型标记操作可以是用户通过点击第二订单后的发票场景类型按钮触发的操作，例如，在订单页面显示有第二订单，在第二订单后可以预先显示至少一个发票场景类型对应的按钮，用户可以通过点击某个发票场景类型对应的按钮，以触发生成发票场景类型标记操作。

在某些示例中，发票场景类型标记可以是用户输入的语音触发的操作，例如，在订单页面内预先设置有语音输入接口，用户可以通过该接口输入触发第二订单的发票场景类型标记的语音，以生成发票场景类型标记操作。

可以理解地，上述示例仅是为了更好地理解本实施例的技术方案而列举的示例，在具体实现中，还可以采用其它方式触发生成发票场景类型标记操作，具体地，可以根据业务需求而定，本实施例对此不加以限制。

在接收到用户对第二订单执行的发票场景类型标记操作之后，执行步骤212。

步骤212：根据所述发票场景类型标记操作，确定所述第二订单对应的第二发票场景类型。

第二发票场景类型是指第二订单的发票场景类型。

在接收到用户对第二订单执行的发票场景类型标记操作之后，可以根据该发票场景类型标记操作，确定第二订单对应的第二发票场景类型。进而，执行步骤213。

步骤213：根据所述第二发票场景类型，为所述第二订单添加相应的发票场景标签。

在确定第二订单对应的第二发票场景类型之后，可以根据第二发票场景类型，为第二订单添加相应的发票场景标签，例如，在第二发票场景类型为加班场景类型时，可以为第二订单添加“加班”标签；而在第二发票场景类型为差旅场景类型时，可以为第二订单添加“差旅”标签等等。通过上述过程，可以实现对订单对应的发票场景标签的删除和更改，可以由用户自定义设置，更能满足用户的需求。

本公开实施例提供的订单标签添加方法，通过接收用户在订单页面针对第一订单执行的标记操作，根据标记操作确定第一订单对应的第一发票场景类型，根据第一发票场景类型为第一订单添加相应的发票场景标签。本公开的实施例通过为订单添加相应的发票场景标签，从而实现了订单的发票场景标记，即实现订单在不同场景下的发票归类，进而，在后续用户查找的过程中，可以直接根据所需发票的场景快速查找到开票订单，无需用户在行程订单中逐页查找，节省了用户查找开票订单的时间，提高了用户的使用体验。

实施例三

参照图3，示出了本公开实施例提供的一种订单标签添加装置的结构示意图，如图3所示，该订单标签添加装置具体可以包括如下模块：

标记操作接收模块310，用于接收用户在订单页面针对第一订单执行的标记操作；

第一类型确定模块320，用于根据所述标记操作，确定所述第一订单对应的第一发票场景类型；

发票标签添加模块330，用于根据所述第一发票场景类型，为所述第一订单添加相应的发票场景标签。

本公开实施例提供的订单标签添加装置，通过接收用户在订单页面针对第一订单执行的标记操作，根据标记操作确定第一订单对应的第一发票场景类型，根据第一发票场景类型为第一订单添加相应的发票场景标签。本公开的实施例通过为订单添加相应的发票场景标签，从而实现了订单的发票场景标记，即实现订单在不同场景下的发票归类，进而，在后续用户查找的过程中，可以直接根据所需发票的场景快速查找到开票订单，无需用户在行程订单中逐页查找，节省了用户查找开票订单的时间，提高了用户的使用体验。

实施例四

参照图4，示出了本公开实施例提供的另一种订单标签添加装置的结构示意图，如图4所示，该订单标签添加装置具体可以包括如下模块：

标记操作接收模块410，用于接收用户在订单页面针对第一订单执行的标记操作；

第一类型确定模块420，用于根据所述标记操作，确定所述第一订单对应的第一发票场景类型；

发票标签添加模块430，用于根据所述第一发票场景类型，为所述第一订单添加相应的发票场景标签；

第一类型查询模块440，用于获取所述用户所需查询的第一发票场景类型；

订单推送模块450，用于将标记为所述第一发票场景类型的至少一个订单展示于与所述用户关联的查询界面；所述至少一个订单包括所述第一订单；

标记删除操作获取模块460，用于获取所述用户对所述至少一个订单中的第二订单执行的发票场景类型的标记删除操作；

发票标签取消模块470，用于根据所述标记删除操作，取消对所述第二订单已添加的发票场景类型标签；

场景标记操作接收模块480，用于接收所述用户对所述第二订单执行的发票场景类型标记操作；

第二类型确定模块490，用于根据所述发票场景类型标记操作，确定所述第二订单对应的第二发票场景类型；

发票场景标签添加模块4100，用于根据所述第二发票场景类型，为所述第二订单添加相应的发票场景标签。

可选地，所述标记操作接收模块410包括：

触发操作接收单元411，用于接收用户在所述订单页面执行发票标记的触发操作；

发票类型推送单元412，用于基于所述触发操作，将与所述用户关联的至少一个订单和所述至少一个订单对应的发票场景类型推送至所述订单页面；所述至少一个订单包括所述第一订单；

标记操作获取单元413，用于获取所述用户对所述第一订单执行的发票场景类型的标记操作。

可选地，所述发票标签添加模块430包括：

下单时间获取单元431，用于获取所述第一订单对应的下单时间；

发票标签添加单元432，用于根据所述下单时间和所述第一发票场景类型，为所述第一订单添加相应的时间标签和发票场景标签。

可选地，所述装置还包括：

编辑操作接收模块，用于接收所述用户对所述第一订单对应的发票场景标签执行的编辑操作；

编辑场景标签确定模块，用于根据所述编辑操作，确定所述第一订单对应的编辑场景标签；

编辑场景标签添加模块，用于为所述第一订单添加所述编辑场景标签。

本公开实施例提供的订单标签添加装置，通过接收用户在订单页面针对第一订单执行的标记操作，根据标记操作确定第一订单对应的第一发票场景类型，根据第一发票场景类型为第一订单添加相应的发票场景标签。本公开的实施例通过为订单添加相应的发票场景标签，从而实现了订单的发票场景标记，即实现订单在不同场景下的发票归类，进而，在后续用户查找的过程中，可以直接根据所需发票的场景快速查找到开票订单，无需用户在行程订单中逐页查找，节省了用户查找开票订单的时间，提高了用户的使用体验。

本公开的实施例还提供了一种电子设备，包括：处理器、存储器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序时实现前述实施例的订单标签添加方法。

本公开的实施例还提供了一种计算机可读存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行前述实施例的订单标签添加方法。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本公开的实施例也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本公开的实施例的内容，并且上面对特定语言所做的描述是为了披露本公开的实施例的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本公开的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本公开的示例性实施例的描述中，本公开的实施例的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本公开的实施例要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本公开的实施例的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的替代特征来代替。

本公开的实施例的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(dsp)来实现根据本公开的实施例的动态图片的生成设备中的一些或者全部部件的一些或者全部功能。本公开的实施例还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序。这样的实现本公开的实施例的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本公开的实施例进行说明而不是对本公开的实施例进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本公开的实施例可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

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

以上所述仅为本公开的实施例的较佳实施例而已，并不用以限制本公开的实施例，凡在本公开的实施例的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本公开的实施例的保护范围之内。

以上所述，仅为本公开的实施例的具体实施方式，但本公开的实施例的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本公开的实施例揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本公开的实施例的保护范围之内。因此，本公开的实施例的保护范围应以权利要求的保护范围为准。