账单处理方法及装置与流程

账单处理方法及装置
1.本发明专利申请是申请日为2021年05月25日、申请号为cn202110573905.8、名称为“账单处理方法及装置”的中国发明专利申请的分案申请。
技术领域
2.本说明书涉及数据处理技术领域，尤其涉及一种账单处理方法及装置。


背景技术：

3.在日常的社会生活中，经常涉及到票据的处理，例如可能涉及到票据的申请，开具，提交以及审核等处理。票据通常具有一定的凭据效力，例如票据作为企业中会计核算的原始依据，同时也是审计机构、税务机构执法检查的重要依据。
4.在用户进行费用报销的过程中，常常需要用户提供与账单的金额数值以及账单种类相匹配的票据作为报销凭证。商家的纸质票据不足等原因可能导致用户无法在支付后马上获得商家开具的票据，使得用户需要花费较多的时间和精力归集需要报销的票据。


技术实现要素：

5.本说明书一个或多个实施例提供了一种账单处理方法。所述账单处理方法包括：确定用户提交的账单访问请求的请求类别。根据所述请求类别对所述用户的因公支付账单进行归集，获得账单列表。在所述用户的票据集合中查询与所述账单列表中各因公支付账单关联的票据。根据查询结果在所述账单列表中配置各因公支付账单的票据状态。
6.本说明书一个或多个实施例提供了一种账单处理装置。所述账单处理装置包括：类别确定模块，被配置为确定用户提交的账单访问请求的请求类别。列表获取模块，被配置为根据所述请求类别对所述用户的因公支付账单进行归集，获得账单列表。票据查询模块，被配置为在所述用户的票据集合中查询与所述账单列表中各因公支付账单关联的票据。状态配置模块，被配置为根据查询结果在所述账单列表中配置各因公支付账单的票据状态。
7.本说明书一个或多个实施例提供了一种电子设备，包括：处理器；以及，被配置为存储计算机可执行指令的存储器，所述计算机可执行指令在被执行时使所述处理器：确定用户提交的账单访问请求的请求类别。根据所述请求类别对所述用户的因公支付账单进行归集，获得账单列表。在所述用户的票据集合中查询与所述账单列表中各因公支付账单关联的票据。根据查询结果在所述账单列表中配置各因公支付账单的票据状态。
8.本说明书一个或多个实施例提供了一种存储介质，用于存储计算机可执行指令，所述计算机可执行指令在被执行时实现以下流程：确定用户提交的账单访问请求的请求类别。根据所述请求类别对所述用户的因公支付账单进行归集，获得账单列表。在所述用户的票据集合中查询与所述账单列表中各因公支付账单关联的票据。根据查询结果在所述账单列表中配置各因公支付账单的票据状态。
附图说明
9.为了更清楚地说明本说明书一个或多个实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
10.图1为本说明书一个或多个实施例提供的一种账单处理方法的处理流程图；
11.图2为本说明书一个或多个实施例提供的一种账单处理方法的账单报销场景的示意图；
12.图3为本说明书一个或多个实施例提供的一种应用于账单报销场景的账单处理方法的处理流程图；
13.图4为本说明书一个或多个实施例提供的一种账单处理装置的结构示意图；
14.图5为本说明书一个或多个实施例提供的一种电子设备的结构示意图。
具体实施方式
15.为了使本技术领域的人员更好地理解本说明书一个或多个实施例中的技术方案，下面将结合本说明书一个或多个实施例中的附图，对本说明书一个或多个实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书的一部分实施例，而不是全部的实施例。基于本说明书一个或多个实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本文件的保护范围。
16.本说明书提供的一种账单处理方法实施例：
17.图1为本说明书一个或多个实施例提供的一种账单处理方法的处理流程图。
18.本实施例提供的账单处理方法的执行主体可以是服务器。
19.参照图1所示，本实施例提供的账单处理方法具体包括下述步骤s102至步骤s108。
20.本实施例提供的账单处理方法，通过归集因公支付账单并配置其票据状态，从账单视角帮助用户直观感知已获取的票据和尚未获取的票据，从而避免遗漏部分票据导致的报销资损。
21.步骤s102，确定用户提交的账单访问请求的请求类别。
22.在本实施例中，用户可以是企业员工，也可以是机构成员。账单访问请求可以是针对用户在进行因公支付后生成的因公支付账单的访问请求。请求类别包括且不限于：账单标签或账单分组对应的第一请求类别，申请单对应的第二请求类别以及自定义条件对应的第三请求类别。前述的各请求类别仅为几种示例，请求类别还可以包括结合多种账单获取规则的请求类别等，此处不再赘述。
23.其中，该第一请求类别的账单访问请求可以通过指定的账单标签或指定的账单分组从个人账户中筛选因公支付账单；该第二请求类别的账单访问请求可以通过预先填写的目标申请单，从个人账户和/或企业账户中筛获取因公支付账单；该第三请求类别的账单访问请求可以通过指定的筛选条件，从个人账户和/或企业账户中筛选得到因公支付账单。
24.因公支付可以出现在出差场景中，例如，购买出差地点与原地之间往返的火车票；也可以出现在采购工作所需物品时，例如，购买办公用品；还可以出现在招待客户的场景下，例如，请客户吃饭。以上几种场景仅为几种示例，还有其他的因公支付的场景，此处不再
一一赘述。
25.可选的，账单处理方法应用于支付应用程序；确定用户提交的账单访问请求的请求类别，包括：获取用户在支付应用程序提交的账单访问请求；账单访问请求中携带有被用户选中的请求类别的请求类别标识；根据请求类别标识，从多种预设请求类别中确定账单访问请求的请求类别。
26.多种预设请求类别包括且不限于：账单标签或账单分组对应的第一请求类别，申请单对应的第二请求类别以及自定义条件对应的第三请求类别。多种预设请求类别也可以仅包括第一请求类别、第二请求类别以及第三请求类别中的任意两项。
27.请求类别标识与预设请求类别之间存在一一对应关系，通过请求类别标识与预设请求类别之间的对应关系，可以确定账单访问请求的请求类别。
28.从用户终端的角度看，用户终端可以执行如下步骤：用户终端获取用户在第一请求类别、第二请求类别以及第三请求类别中提交的请求类别选择动作和账单访问动作；用户终端根据所述账单访问动作，向服务器发送账单访问请求；所述账单访问请求携带有被所述请求类别选择动作选中的目标请求类别的请求类别标识。
29.步骤s104，根据请求类别对用户的因公支付账单进行归集，获得账单列表。
30.可选的，根据请求类别对用户的因公支付账单进行归集，获得账单列表，包括：若请求类别为账单标签或账单分组对应的第一请求类别，则在用户的个人账户中筛选并归集指定账单标签或指定账单分组对应的因公支付账单，获得账单列表。
31.在一个实施例中，在用户的个人账户中筛选并归集指定账单标签或指定账单分组对应的因公支付账单之前，还可以执行如下操作：根据用户对待处理账单的标签添加请求，将指定的账单标签关联至待处理账单。例如，用户为出差过程中购买火车票的账单手动添加差旅标签。
32.在另一个实施例中，在用户的个人账户中筛选并归集指定账单标签或指定账单分组对应的因公支付账单之前，还可以执行如下操作：根据用户对待处理账单的分组请求，将待处理账单关联至指定的账单分组。
33.根据用户对待处理账单的分组请求，将待处理账单关联至指定的账单分组，可以理解为，待处理账单原本没有与任何账单分组关联，在服务器获取用户对待处理账单的分组请求后，服务器将待处理账单与指定的账单分组关联。
34.在又一个实施例中，在用户的个人账户中筛选并归集指定账单标签或指定账单分组对应的因公支付账单之前，还可以执行如下操作：根据用户对待处理账单的分组更新请求，将待处理账单关联的账单分组更新至指定的账单分组。
35.具体实施时，若请求类别为账单标签或账单分组对应的第一请求类别，则在用户的个人账户中筛选并归集指定账单标签或指定账单分组对应的因公支付账单，获得账单列表，包括：若请求类别为账单标签或账单分组对应的第一请求类别，则读取指定账单标签或指定账单分组；将指定账单标签或指定账单分组作为筛选条件，对用户的个人账户进行筛选，得到因公支付账单。
36.需要理解的是，个人账户需要按照账单标签或账单分组筛选并归集因公支付账单，是因为个人账户既可能进行因公支付，又可能进行私人支付，即个人账户的账单中既包括个人支付账单，又可能包括因公支付账单。通常情况下，通过企业账户进行支付后获得的
账单均为因公支付账单，因此，第一请求类别适用于个人账户。
37.在另一个实施例中，若请求类别为账单标签或账单分组对应的第四请求类别，则在用户的个人账户中筛选并归集指定账单标签或指定账单分组对应的第一因公支付账单，在用户所使用的企业账户中获取第二因公支付账单。
38.可选的，根据请求类别对用户的因公支付账单进行归集，获得账单列表，包括：若请求类别为申请单对应的第二请求类别，则根据预先填写的目标申请单，确定至少一个目标账单种类以及各目标账单种类的账单数量；针对任一目标账单种类，根据目标账单种类，对用户的个人账户和/或用户所使用的企业账户进行筛选，得到待处理账单；按照预设规则对待处理账单排序，按照账单数量选取对应的待处理账单作为因公支付账单；归集因公支付账单，得到账单列表。
39.根据目标账单种类，对用户的个人账户和/或用户所使用的企业账户进行筛选，可以是，确定与目标账单种类对应的目标账单标签或目标账单分组，按照指定时间段、目标账单标签或目标账单分组对个人账户和/或企业账户进行筛选，得到待处理账单。
40.目标申请单可以是采购申请单，也可以是出差申请单，还可以是招待申请单。该目标申请单可以理解为根据申请规则预先配置好的一个包含多个待填充区域的模板。例如，采购申请单，包括：采购个文具和个家用电器；出差申请单，包括：酒店住宿晚，火车票张，飞机票张。
41.例如，用户预先填写的目标申请单为采购申请单，其内容包括：采购“5”个文具和“1”个家用电器。则根据采购申请单，确定两个目标账单种类，分别为文具和家用电器。确定与文具对应的目标账单标签为“文体用品”，根据目标账单标签“文体用品”对个人账户和/或企业账户进行筛选，得到10个待处理账单。
42.按照预设规则对待处理账单排序，其中，预设规则可以是根据账单的生成时间从后到前进行排序，也可以是在指定的时间段内根据账单的生成时间从前到后或从后到前进行排序。
43.按照预设规则对待处理账单排序，按照账单数量选取对应的待处理账单作为因公支付账单，例如，对前述步骤中筛选得到的10个待处理账单，根据待处理账单的生成时间从后到前进行排序，文具对应的账单数量为5，则基于排序结果从后往前选取5个待处理账单作为因公支付账单。获取家用电器对应的1个因公支付账单的方法与获取文具对应的5个因公支付账单的方法类似，此处不再赘述。
44.归集因公支付账单，得到账单列表，可以理解为，对各个目标账单种类对应的因公支付账单归集到一个账单列表中。
45.可选的，根据预先填写的目标申请单，确定至少一个目标账单种类以及各目标账单种类的账单数量，包括：根据预先填写的目标申请单，确定目标申请单中填写的至少一个申请数量以及各申请数量所处的待填充区域的区域标识；根据各区域标识确定对应的目标账单种类；将各待填充区域中填写的申请数量作为待填充区域的区域标识对应的目标账单种类的账单数量。
46.根据预先填写的目标申请单，确定目标申请单中填写的至少一个申请数量以及各申请数量所处的待填充区域的区域标识，可以理解为，目标申请单包括文字部分和多个待填充区域，每个待填充区域的区域标识对应于一个账单种类。
47.例如，采购申请单包括：采购3个文具和1个家用电器，其中，“采购”、“个文具和”“个家用电器”为该采购申请单中的文字部分，“采购”与“个文具和”之间用下划线标识的区域为待填充区域，该待填充区域的区域标识，假设该区域标识为“a1”，“a1”与账单种类“文具”之间存在对应关系。则该“a1”对应的待填充区域中填写的数值“3”即为目标账单种类“文具”的账单数量。同理，“文具和”与“个家用电器”之间的待填充区域中填写的数值“1”为目标账单种类“家用电器”的账单数量。
48.需要注意的是，尽管通过企业账户进行支付后获得的账单均为因公支付账单，但通过申请单对应的第二请求类别的账单访问请求获得的账单列表为由符合目标申请单的因公支付账单构成的账单列表，因此，需要根据目标账单种类，对用户所使用的企业账户进行筛选，而不是将企业账户的账单全部添加进账单列表。
49.在另一实施例中，根据预先填写的目标申请单，确定至少一个目标账单种类以及各目标账单种类的账单数量，还可以是，根据预先填写的目标申请单，确定目标申请单中填写的至少一个申请数量以及与申请数量对应的被用户选中的目标账单种类。该目标申请单可以预先设置多种待选择账单种类。
50.通过第二请求类别的账单访问请求获得账单列表，能够针对性地获得符合预先填写的申请单的因公支付账单，有利于用户直观地查看一个完整的因公支出活动中所产生的各个因公支付账单，因公支出活动包括且不限于：差旅活动、采购活动或招待活动。
51.可选的，根据请求类别对用户的因公支付账单进行归集，获得账单列表，包括：若请求类别为自定义条件对应的第三请求类别，则根据指定的筛选条件，在用户的个人账户中筛选并归集因公支付账单，获得账单列表；筛选条件包括以下至少一项：账单所属的时间段、账单标签、账单分组、账单报销状态。
52.账单所属的时间段，指的是账单的生成时间所属的时间段。因公支付账单的账单报销状态包括已报销和未报销。非因公支付账单不存在账单报销需求，故也不存在账单报销状态，账单报销状态可以在步骤s104执行的过程中生成，例如，在根据请求类别对用户的因公支付账单进行归集的过程中，在得到因公支付账单时，生成该因公支付账单对应的账单报销状态，并将该账单报销状态设置为初始值“未报销”。当因公支付账单被提交到报销系统后，该因公支付账单的账单报销状态从“未报销”更新为“已报销”。
53.例如，根据指定的账单所属的时间段“x月y日-x月z日”、指定的账单分组“差旅”在用户的个人账户中筛选并归集因公支付账单，获得账单列表。
54.步骤s106，在用户的票据集合中查询与账单列表中各因公支付账单关联的票据。
55.可选的，账单处理方法还包括：获取用户上传的票据和用户的用户标识；根据票据和用户标识，将票据添加到用户的票据集合中；根据用户对选中的至少一个账单与票据的账单票据关联操作，将票据关联到至少一个账单。
56.获取用户上传的票据和用户的用户标识，可以发生在步骤s102之前，也可以发生在步骤s102之后。即，服务器获取用户上传的与因公支付账单关联的票据可以发生在服务器获得账单访问请求之前，也可以发生在服务器获得账单访问请求。
57.根据用户标识，确定用户的票据集合，将票据添加到票据集合中。
58.在关联票据与账单时，需要考虑到，账单与票据可能是一对一的关联关系，也可能是多对一的关联关系。例如，用户在某一餐厅进行多次因公支付，获取对应的多个因公支付
账单，用户为方便起见，向餐厅仅索取一个票据，该票据为餐厅根据多个因公支付账单开具得到。具体地，员工在该餐厅第一次因公支付a元，第二次因公支付b元，第三次因公支付c元，则餐厅根据三个因公支付账单开具的票据数值为(a b c)元。
59.用户上传的票据可以是纸质票据，也可以是通过邮件接收的电子票据。上传纸质票据的方式可以是通过摄像头或扫描仪采集纸质票据的图像。
60.可选的，账单处理方法还包括：获取商家发送的票据、与票据绑定的至少一个账单标识以及用户的用户标识；根据用户标识，将票据添加到用户的票据集合中；将票据关联到账单标识对应的至少一个账单。
61.获取商家发送的票据，可以理解为，在用户针对因公支付账单向商家发出票据请求信息后，商家根据因公支付账单的账单标识开具关联的票据并发送给用户。
62.若用户针对多个因公支付账单向同一商家发出合并票据请求信息，商家根据该多个因公支付账单的账单标识开具一个关联的票据并发送给用户。根据用户标识，将票据添加到用户的票据集合中；将票据关联到账单标识对应的至少一个账单。
63.可选的，账单处理方法还包括：针对任一票据，根据票据关联的任一关联账单的账单标识，判断关联账单是否属于账单列表；若属于，则更新关联账单的票据状态。
64.因公支付账单的票据状态包括：“已回票”和“未回票”。在任一时间点，一个因公支付账单的票据状态只能是在“已回票”和“未回票”中的一项。
65.在获取用户上传的票据且将票据关联到至少一个账单之后，确定该票据关联的关联账单是否属于账单列表，若属于，则将该关联账单的票据状态从“未回票”更新为“已回票”。
66.在获取商家发送的票据且将票据关联到账单标识对应的至少一个账单之后，确定该票据关联的关联账单是否属于账单列表，若属于，则将该关联账单的票据状态从不存在关联的票据更新为存在关联的票据。
67.步骤s108，根据查询结果在账单列表中配置各因公支付账单的票据状态。
68.可选的，根据查询结果在账单列表中配置各因公支付账单的票据状态，包括：根据各因公支付账单关联的票据的查询结果，确定与查询结果对应的票据状态；将各因公支付账单的票据状态确定为因公支付账单的展示页面的配置参数；根据配置参数，渲染并生成因公支付账单的展示页面。
69.票据的查询结果包括关联的票据存在和关联的票据不存在。此处的存在，指的是，根据服务器中存储的票据与至少一个因公支付账单之间的关联关系，确定某一因公支付账单关联的票据存在，该票据可以是用户上传到服务器中的，也可以是商家向该用户账户发送的。此处的不存在，指的是，根据服务器中存储的票据与至少一个因公支付账单之间的关联关系，确定某一因公支付账单关联的票据不存在。
70.若某个因公支付账单的票据的查询结果为关联的票据存在，则该因公支付账单的票据状态为“已回票”；若某个因公支付账单的票据的查询结果为关联的票据不存在，则该因公支付账单的票据状态为“未回票”。
71.将各因公支付账单的票据状态确定为因公支付账单的展示页面的配置参数，根据配置参数，渲染并生成因公支付账单的展示页面，以使该展示页面中票据状态不同的因公支付账单区分显示。例如，账单1的票据状态为“已回票”，则账单1的右侧显示有文字“已回
票”；账单5的票据状态为“未回票”，则账单5的右侧显示有文字“未回票”。
72.通过区分显示不同票据状态的因公支付账单，能够帮助用户更直观地感知未回票的账单，以提示用户及时上传或向商家索要票据。
73.本实施例提供的账单处理方法，还可以根据用户的报销报表生成请求，确定被用户选中的目标因公支付账单以及关联的目标票据，再根据目标因公支付账单以及关联的目标票据生成报表，以上传到报销系统。
74.综上，本实施例提供的账单处理方法，首先，确定用户提交的账单访问请求的请求类别；其次，根据请求类别对用户的因公支付账单进行归集，获得账单列表；接着，在用户的票据集合中查询与账单列表中各因公支付账单关联的票据；最后，根据查询结果在账单列表中配置各因公支付账单的票据状态。通过该技术方案，能够灵活地根据用户需求归集因公支付账单，通过配置各因公支付账单的票据状态，使得用户能够从账单视角直观地感知各因公支付账单关联的票据是否被遗漏。
75.下文结合账单报销场景进一步说明本说明书的实施例提供的账单处理方法。
76.图2为本说明书一个或多个实施例提供的一种账单处理方法的账单报销场景的示意图。
77.参照图2所示，在账单报销场景下，用户进行因公支付操作后，可以通过两种方式获取票据：一种是用户通过商户在线下开票。另一种是用户通过个人账户进行因公支付操作后，先获得个人账单，再基于个人账单获取因公支付账单的账单列表，用户根据账单列表通过商家开票。通过两种方式获得的票据被归集于票据夹。在票据被归集到票据夹时，服务器在票据与至少一个因公支付账单之间建立关联关系。根据票据和至少一个因公支付账单之间的关联关系，确定各因公支付账单的票据状态。用户可以根据各因公支付账单的票据状态确定是否报销以及将哪些因公支付账单确定为待报销账单。服务器可以根据待报销账单以及关联的票据生成报表，将报表上传至报销系统。
78.如图2所示的方法实施例，可以实现前述方法实施例中的各个过程，此处不再赘述。
79.图3为本说明书一个或多个实施例提供的一种应用于账单报销场景的账单处理方法的处理流程图。
80.参照图3所示，本实施例提供的账单处理方法，包括步骤s302至步骤s318。
81.本实施例的执行主体可以是服务器。
82.步骤s302，获取用户的因公支付账单确定请求。
83.具体实施时，用户终端获取用户的因公支付账单确定操作，用户终端根据因公支付账单确定操作生成向服务器发送的因公支付账单确定请求。服务器接收由用户终端发送的因公支付账单确定请求。其中，因公支付账单确定操作可以包括因公支付账单选择操作和/或因公支付账单确认操作。
84.下文通过两个具体的例子来说明因公支付账单确定操作：
85.例如，用户的个人账单的展示界面用于展示个人账单列表，该个人账单列表包括账单1、账单2、账单3、账单4以及账单5。用户单击因公支付账单的账单生成控件后，进入账单多选模式，在该账单多选模式下，各个人账单的左侧出现对应的多选框。用户单击账单1、账单3以及账单5左侧的多选框，再单击确认控件。
86.又例如，用户的个人账单的展示界面用于展示个人账单列表，该个人账单列表包括账单1、账单2、账单3、账单4以及账单5。用户单击账单3的编辑控件，编辑控件右侧弹出编辑菜单，该编辑菜单包括多个编辑选项，例如，“添加至因公支付账单”，用户单击该“添加至因公支付账单”的编辑选项。此处的添加至因公支付账单，实际上指的是，将账单3确定为因公支付账单，并将账单3添加到因公支付账单的账单列表中。
87.因公支付账单确定请求为用户终端基于因公支付账单确定操作生成的，携带有被用户选中的个人账单的账单标识。
88.在步骤s302被服务器执行之后，服务器执行步骤s310。
89.步骤s304，获取用户对个人账单的标记添加请求。
90.具体实施时，用户终端获取用户对个人账单的标记添加操作，用户终端根据标记添加操作生成向服务器发送的标记添加请求。服务器接收由用户终端发送的标记添加请求，该标记添加请求携带有被用户选中的个人账单的账单标识。
91.在步骤s304被服务器执行之后，服务器执行步骤s308。
92.步骤s306，获取用户的申请单创建请求。
93.具体实施时，用户终端获取用户的申请单创建操作，用户终端根据申请单创建操作生成向服务器发送的申请单创建请求。服务器接收由用户终端发送的申请单创建请求。
94.用户创建的申请单可以是采购申请单，也可以是出差申请单，还可以是招待申请单。该申请单可以理解为根据申请规则预先配置好的一个包含多个待填充区域的模板。例如，采购申请单，包括：采购个文具和个家用电器；出差申请单，包括：酒店住宿晚，火车票张，飞机票张。
95.申请单创建操作，可以是在预设的申请单模板的基础上进行的申请单填写操作。
96.在步骤s306被服务器执行之后，服务器执行步骤s308。
97.步骤s308，确定个人账单的筛选规则。
98.根据标记添加请求或申请单创建请求确定个人账单的筛选规则。
99.例如，用户的个人账单的展示界面用于展示个人账单列表，该个人账单列表包括账单1、账单2、账单3、账单4以及账单5。用户给账单1、账单4添加了“差旅”标签，则根据标签添加请求确定个人账单的筛选规则为，从个人账单列表中按照标签“差旅”对各个人账单进行筛选处理。
100.又例如，用户基于预设的采购申请单模板，创建采购申请单，则根据申请单创建请求确定个人账单的筛选规则为，根据用户创建的采购申请单，确定至少一个目标账单种类以及各目标账单种类的账单数量；针对任一目标账单种类，根据目标账单种类，对用户的个人账户进行筛选，得到待处理账单；按照预设规则对待处理账单排序，按照账单数量选取对应的待处理账单。
101.步骤s310，获得账单列表，根据各因公支付账单关联的票据的查询结果配置票据状态。
102.根据通过步骤s302确定的一个或多个因公支付账单，或者，通过步骤s308中的筛选规则对用户的个人账单进行筛选后获得的一个或多个因公支付账单，构建得到因公支付账单的账单列表。在用户的票据夹对应的票据集合中查询账单列表中各因公支付账单关联的票据，根据票据查询结果，在账单列表中配置各因公支付账单的票据状态。
103.票据的查询结果包括关联的票据存在或关联的票据不存在。此处的存在，指的是，根据服务器中存储的票据与至少一个因公支付账单之间的关联关系，确定某一因公支付账单关联的票据存在，该票据可以是用户上传到服务器中的，也可以是商家向该用户账户发送的。此处的不存在，指的是，根据服务器中存储的票据与至少一个因公支付账单之间的关联关系，某一因公支付账单关联的票据不存在。
104.若某个因公支付账单的票据的查询结果为关联的票据存在，则该因公支付账单票据状态为“已回票”；若某个因公支付账单的票据的查询结果为关联的票据不存在，则该因公支付账单票据状态为“未回票”。
105.需要注意的是，在步骤s316执行之后，返回执行步骤s310时，在用户的票据夹对应的票据集合中查询各因公支付账单关联的票据的查询结果发生变更。可以理解为，在将商家发送的票据关联至账单标识对应的因公支付账单后，在用户的票据夹对应的票据集合中查询该因公支付账单关联的票据的查询结果从关联的票据不存在变更为关联的票据存在。则根据变更后的查询结果配置该因公支付账单的票据状态。
106.在步骤s316执行之后，返回执行步骤s310时，可以直接读取已获取的账单列表以及已配置好的各因公支付账单的票据状态，在此基础上将步骤s316中账单标识对应的因公支付账单的票据状态进行配置更新处理即可。
107.步骤s312，向商家发送票据请求信息。
108.当账单列表中某个因公支付账单的票据状态为“未回票”时，用户可以向商家请求该因公支付账单关联的电子票据。服务器可以根据获取的用户的票据请求操作，向商家发送票据请求信息。
109.具体实施时，服务器根据获取的用户的票据请求操作，生成并向商家发送票据请求信息。该票据请求信息包括用户的用户标识和至少一个因公支付账单的账单标识。
110.步骤s314，将商家发送的票据添加到用户的票据夹中。
111.商家发送的票据可以是电子票据。商家可以根据步骤s312中服务器发送的票据请求信息，开具电子票据。服务器获取商家基于用户标识发送的与账单标识关联的电子票据。
112.步骤s316，将票据关联至因公支付账单。
113.将商家发送的电子票据关联至账单标识对应的因公支付账单，即在账单标识对应的因公支付账单与电子票据之间建立关联关系。
114.在步骤s316被服务器执行之后，服务器返回执行步骤s310。
115.步骤s318，根据因公支付账单及关联的票据发起报销。
116.在步骤s310执行之后，服务器响应于获取的票据报销发起请求，根据因公支付账单及关联的票据发起报销。该票据报销发起请求中可以携带有待报销的因公支付账单的账单标识。
117.具体实施时，服务器根据票据报销发起请求中携带的待报销的因公支付账单的账单标识，获取待报销账单以及关联的票据；服务器根据待报销账单以及关联的票据生成报表；服务器将报表发送至报销系统。
118.如图3所示的方法实施例，可以实现前述方法实施例中的各个过程，此处不再赘述。
119.综上，本实施例提供的账单处理方法，首先，确定用户提交的账单访问请求的请求
类别；其次，根据请求类别对用户的因公支付账单进行归集，获得账单列表；接着，在用户的票据集合中查询与账单列表中各因公支付账单关联的票据；最后，根据查询结果在账单列表中配置各因公支付账单的票据状态。通过该技术方案，能够灵活地根据用户需求归集因公支付账单，通过配置各因公支付账单的票据状态，使得用户能够从账单视角直观地感知各因公支付账单关联的票据是否被遗漏。
120.对应上述图1描述的账单处理方法，基于相同的技术构思，本说明书一个或多个实施例还提供一种账单处理装置。图4为本说明书一个或多个实施例提供的第一种账单处理装置的结构示意图，如图4所示，账单处理装置，包括：
121.类别确定模块402，被配置为确定用户提交的账单访问请求的请求类别；
122.列表获取模块404，被配置为根据请求类别对用户的因公支付账单进行归集，获得账单列表；
123.票据查询模块406，被配置为在用户的票据集合中查询与账单列表中各因公支付账单关联的票据；
124.状态配置模块408，被配置为根据查询结果在账单列表中配置各因公支付账单的票据状态。
125.需要说明的是，本说明书中关于账单处理装置的实施例与本说明书中关于账单处理方法的实施例基于同一发明构思，因此该实施例的具体实施可以参见前述对应的账单处理方法的实施，重复之处不再赘述。
126.对应上述描述的应用于电子设备的账单处理方法，基于相同的技术构思，本说明书一个或多个实施例还提供一种电子设备，该电子设备用于执行上述提供的账单处理方法，图5为本说明书一个或多个实施例提供的一种电子设备的结构示意图。
127.本实施例提供的一种电子设备，包括：
128.如图5所示，电子设备可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上的处理器501和存储器502，存储器502中可以存储有一个或一个以上存储应用程序或数据。其中，存储器502可以是短暂存储或持久存储。存储在存储器502的应用程序可以包括一个或一个以上模块(图示未示出)，每个模块可以包括电子设备中的一系列计算机可执行指令。更进一步地，处理器501可以设置为与存储器502通信，在电子设备上执行存储器502中的一系列计算机可执行指令。电子设备还可以包括一个或一个以上电源503，一个或一个以上有线或无线网络接口504，一个或一个以上输入/输出接口505，一个或一个以上键盘506等。
129.在一个具体的实施例中，电子设备包括有存储器，以及一个或一个以上的程序，其中一个或者一个以上程序存储于存储器中，且一个或者一个以上程序可以包括一个或一个以上模块，且每个模块可以包括对电子设备中的一系列计算机可执行指令，且经配置以由一个或者一个以上处理器执行该一个或者一个以上程序包含用于进行以下计算机可执行指令：
130.确定用户提交的账单访问请求的请求类别；
131.根据请求类别对用户的因公支付账单进行归集，获得账单列表；
132.在用户的票据集合中查询与账单列表中各因公支付账单关联的票据；
133.根据查询结果在账单列表中配置各因公支付账单的票据状态。
134.本说明书提供的一种存储介质实施例如下：
135.对应上述描述的一种的账单处理方法，基于相同的技术构思，本说明书一个或多个实施例还提供一种存储介质。一个具体的实施例中，该存储介质可以为u盘、光盘、硬盘等。
136.本实施例提供的存储介质，用于存储计算机可执行指令，计算机可执行指令在被执行时实现以下流程：
137.确定用户提交的账单访问请求的请求类别；
138.根据请求类别对用户的因公支付账单进行归集，获得账单列表；
139.在用户的票据集合中查询与账单列表中各因公支付账单关联的票据；
140.根据查询结果在账单列表中配置各因公支付账单的票据状态。
141.需要说明的是，本说明书中关于存储介质的实施例与本说明书中关于账单处理方法的实施例基于同一发明构思，因此该实施例的具体实施可以参见前述对应方法的实施，重复之处不再赘述。
142.上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
143.在20世纪30年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(programmable logic device，pld)(例如现场可编程门阵列(field programmable gate array，fpga))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片pld上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(hardware description language，hdl)，而hdl也并非仅有一种，而是有许多种，如abel(advanced boolean expression language)、ahdl(altera hardware description language)、confluence、cupl(cornell university programming language)、hdcal、jhdl(java hardware description language)、lava、lola、myhdl、palasm、rhdl(ruby hardware description language)等，目前最普遍使用的是vhdl(very-high-speed integrated circuit hardware description language)与verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
144.控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可
读介质、逻辑门、开关、专用集成电路(application specific integrated circuit，asic)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：arc625d、atmel at91sam、microchip pic18f26k20以及silicone labs c8051f320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
145.上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
146.为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本说明书实施例时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
147.本领域内的技术人员应明白，本说明书一个或多个实施例可提供为方法、系统或计算机程序产品。因此，本说明书一个或多个实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本说明书可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
148.本说明书是参照根据本说明书实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
149.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
150.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
151.在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
152.内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或
非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的示例。
153.计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
154.还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
155.本说明书一个或多个实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书的一个或多个实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
156.本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
157.以上所述仅为本文件的实施例而已，并不用于限制本文件。对于本领域技术人员来说，本文件可以有各种更改和变化。凡在本文件的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本文件的权利要求范围之内。