一种发票开具方法、装置、系统、电子设备、介质及产品与流程

1.本公开涉及数据处理技术领域，尤其涉及金融数据处理技术领域，具体涉及一种发票开具方法、装置、系统、电子设备、介质及产品。


背景技术：

2.先票后款，指的是销售方在购买方对所购买商品付款之前，先为购买产品开具发票。在先票后款场景下，目前的电子发票系统中，需要由销售人员代替购买方在电子发票系统中针对所购买商品申请开票。


技术实现要素：

3.本公开提供了一种发票开具方法、装置、系统、电子设备、介质及产品。
4.根据本公开实施例的第一方面，提供了一种发票开具方法，包括：
5.获取开票信息，所述开票信息包括销售方的纳税信息和购买方的纳税信息，以及所述购买方的多个账号各自对应的申请行信息，每条申请行信息包括商品信息；
6.针对每条申请行信息，根据该申请行信息包括的商品信息，确定该申请行信息的类型；
7.基于单张发票的属性限制信息，对相同类型的申请行信息进行分组；其中，分组得到的每组申请行信息满足所述属性限制信息；
8.对于每组申请行信息，基于该组申请行信息包括的商品信息、所述销售方的纳税信息和所述购买方的纳税信息，构建待开具发票；
9.对所述待开具发票进行发票开具。
10.根据本公开实施例的第二方面，提供了一种发票开具装置，包括：
11.获取模块，用于获取开票信息，所述开票信息包括销售方的纳税信息和购买方的纳税信息，以及所述购买方的多个账号各自对应的申请行信息，每条申请行信息包括商品信息；
12.确定模块，用于针对所述获取模块获取的每条申请行信息，根据该申请行信息包括的商品信息，确定该申请行信息的类型；
13.分组模块，用于基于单张发票的属性限制信息，对所述确定模块确定的相同类型的申请行信息进行分组；其中，分组得到的每组申请行信息满足所述属性限制信息；
14.构建模块，用于对于所述分组模块得到的每组申请行信息，基于该组申请行信息包括的商品信息、所述销售方的纳税信息和所述购买方的纳税信息，构建待开具发票；
15.开具模块，用于对所述构建模块构建的所述待开具发票进行发票开具。
16.根据本公开实施例的第三方面，提供了一种发票开具系统，包括：客户关系管理系统和发票系统；
17.所述客户关系管理系统，用于当接收到用户触发的提交指令时，向所述发票系统发送开票信息，所述开票信息包括销售方的纳税信息、购买方的纳税信息以及所述购买方
的多个账号各自对应申请行信息，每条申请行信息包括商品信息；
18.所述发票系统，用于执行第一方面所述的方法以进行发票开具。
19.根据本公开实施例的第四方面，提供了一种电子设备，包括：
20.至少一个处理器；以及
21.与所述至少一个处理器通信连接的存储器；其中，
22.所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行第一方面所述的方法。
23.根据本公开实施例的第五方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行第一方面所述的方法。
24.根据本公开实施例的第六方面，提供了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现第一方面所述的方法。
25.本公开实施例提供的发票开具方法、装置、系统、电子设备、介质及产品中，通过确定申请行信息的类型，并基于单张发票的属性限制信息，对相同类型的申请行信息进行分组，使得分组后每组申请行信息既属于同一种类型，又满足单张发票的属性限制信息，因此通过每组申请行信息构建的发票项可以属于同一张发票中。使得后续可以对每组申请行信息构建待开具发票并进行发票开具。由于本公开实施例中的开票信息包括购买方的多个账号各自对应的申请行信息，因此能够支持销售方人员通过发起一次开票申请提交多个账号各自对应的申请行信息，并进行合并开票，减少开票过程耗费的时间和人力。
26.应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。
附图说明
27.附图用于更好地理解本方案，不构成对本公开的限定。其中：
28.图1是本公开实施例提供的一种发票开具方法的流程图；
29.图2是本公开实施例提供的一种发票的示例性示意图；
30.图3是本公开实施例提供的一种申请界面的示例性示意图；
31.图4是本公开实施例提供的一种确定申请行信息类型的方法的流程图；
32.图5是本公开实施例提供的一种分组方法的流程图；
33.图6是本公开实施例提供的一种待开具发票的状态的示例性示意图；
34.图7是本公开实施例提供的一种发票开具方法的流程示意图；
35.图8a是本公开实施例提供的一种发票开具系统的结构示意图；
36.图8b是本公开实施例提供的另一种发票开具系统的结构示意图；
37.图9是本公开实施例提供的另一种发票开具系统的结构示意图；
38.图10是本公开实施例提供的一种发票开具装置的结构示意图；
39.图11是用来实现本公开实施例的发票开具方法的电子设备的框图。
具体实施方式
40.以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识
到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。
41.线上发票系统开具发票与线下开具发票的方式相比，能够减少人员之间的直接交互，简化开票过程，使得电子发票系统的应用广泛。尤其对于提供各类云产品的云服务平台，构建高效易用的电子发票系统，能够使得发票开具流程更快捷、且对发票的查询更方便。
42.先票后款，指的是销售方在购买方对所购买商品付款之前，先为购买方购买的商品开具发票。
43.在先票后款场景下，目前的电子发票系统中，需要由销售方人员代替购买方在电子发票系统中根据线下合同约定内容，针对所购买商品申请开票。目前的电子发票系统仅支持账号级别的开票，即一次只能针对一个账号申请开具一张发票。购买方名下可能存在多个账号，例如购买方存在多个部门，每个部门具有一个账号。如果购买方名下的多个账号具有批量开票需求，销售方人员则需要分别针对每个账号分别发起开票申请，导致整个开票过程耗时耗力。
44.为了解决先票后款场景下开票过程耗时耗力的问题，本公开实施例提供了一种发票开具方法，该方法可以应用于发票系统。发票系统可以部署在计算机或者服务器等具备数据处理能力的电子设备中。
45.如图1所示，发票开具方法包括如下步骤：
46.s101、获取开票信息。
47.其中，开票信息包括销售方的纳税信息、购买方的纳税信息，以及购买方的多个账号各自对应的申请行信息，申请行信息包括商品信息。
48.可选的，开票信息可以是客户关系管理系统在接收到用户触发的提交指令时，向发票系统发送的。其中，销售方的纳税信息包括销售方的名称、纳税人识别号、地址、电话、开户行及银行账号。购买方的纳税信息包括购买方的名称、纳税人识别号、地址、电话、开户行及银行账号。其中，购买方的名称也可以称为发票抬头。
49.示例性的，商品信息包括：商品的标识、数量、金额和单价等。
50.s102、针对每条申请行信息，根据该申请行信息包括的商品信息，确定该申请行信息的类型。
51.可以理解的，申请行信息也可称为征税信息(taxapplyinfo)，开票信息包括的每条申请行信息可构建为发票中的一条或多条发票项，因此申请行信息与发票中的发票项对应。同一张发票中的各发票项的类型需要相同，即不同类型的发票项不能同时处于一张发票中。因此本公开实施例需要确定每条申请行信息的类型，以便区分不同类型的申请行信息。
52.可选的，在s102之前，发票系统还可以对开票信息进行校验，校验方式包括：检查购买方的纳税信息和销售方的纳税信息是否存在且正确、购买方的名称和销售方的名称是否已实名认证、购买方的地址是否存在、是否存在发票抬头且发票抬头是否正确、购买方的账号是否为非内部测试账号、商品的税收分类编码是否存在且正确、以及商品金额是否为正数。可选的，商品的税收分类编码可以携带在商品信息中，或者发票系统可以根据商品信息包括的商品名称，查找税收分类编码。商品金额可以携带在商品信息中。可以理解的，由
于后续可能需要将发票寄送至购买方，所以可以校验是否存在购买方的地址。
53.s103、基于单张发票的属性限制信息，对相同类型的申请行信息进行分组。其中，分组得到的每组申请行信息满足属性限制信息。
54.可以理解的，单张发票具有属性限制信息，例如单张发票包括的各发票项的金额总和不能超过一定金额、以及单张发票包括的发票项数量不能超过一定数量。因此，本公开实施例在构建待开具发票之前，可以对相同类型的申请行信息进行分组，使得分组后每组申请行信息既属于同一种类型，又满足单张发票的属性限制信息，从而通过每组申请行信息构建的发票项可以属于同一张发票。
55.s104、对于每组申请行信息，基于该组申请行信息包括的商品信息、销售方的纳税信息和购买方的纳税信息，构建待开具发票。
56.一种实现方式中，结合图2，发票系统针对每组申请行信息中的每条申请行信息，将该申请行信息中商品信息包括的商品名称填写在图2中的“货物或应税劳务、服务名称”、将商品规格型号填写在图2中的“规格型号”、将单位填写在图2中的“单位”、将商品数量填写在图2中的“数量”、将商品金额填写在图2中的“金额”。并根据商品信息中的税收分类编码确定税率并填写图2中的“税率”，计算商品信息中的金额和税率的乘积得到税额并填写在图2中的“税额”，从而得到一条完整的发票项。之后计算各发票项的金额与税额的总和得到发票的价税合计金额，并填写在图2中的“价税合计”。并将s101获取的开票信息包括的销售方的纳税信息填写在发票的销售方区域，将s101获取的开票信息包括的购买方的纳税信息填写在发票的购买方区域，得到一张待开具发票。
57.s105、对待开具发票进行发票开具。
58.可选的，可以对待开具发票进行电子发票开具或者纸质发票开具。
59.采用本公开实施例提供的发票开具方法，通过确定申请行信息的类型，并基于单张发票的属性限制信息，对相同类型的申请行信息进行分组，使得分组后每组申请行信息既属于同一种类型，又满足单张发票的属性限制信息，因此通过每组申请行信息构建的发票项可以属于同一张发票中。使得后续可以对每组申请行信息构建待开具发票并进行发票开具。由于本公开实施例中的开票信息包括购买方的多个账号各自对应的申请行信息，因此能够支持销售方人员通过发起一次开票申请提交多个账号各自对应的申请行信息，并进行合并开票，减少开票过程耗费的时间和人力。
60.本公开实施例中的销售方人员可以是销售方的销售人员或者销售方的财务人员等，本公开实施例对此不作具体限定。
61.在本公开的一个实施例中，在上述s101之前，客户关系管理系统在向发票系统发送开票信息之前，还可以接收用户输入的合同号，获取合同号对应的销售方的纳税信息、购买方的纳税信息和购买方的各账号，以及接收用户针对选择的每个账号分别输入的申请行信息。
62.其中，每个合同号对应一份已签署的合同，合同中包括销售方的纳税信息、购买方的纳税信息以及购买方的所有账号。
63.客户关系管理系统除了接收用户输入的合同号以外，还可以接收用户输入的其他信息。例如，一份合同可能存在多个不同的购买方，例如，购买方总公司签署的合同中，包括多个购买方子公司的纳税信息，这种情况下可以接收用户输入的发票抬头，即购买方的名
称，从而使得客户关系管理系统根据购买方的名称，确定购买方的纳税信息。又例如，一个购买方可能存在纸质发票和电子发票的开票需求，这种情况下可以接收用户输入的发票介质，并将发票介质携带在开票信息中。
64.一种实现方式中，客户关系管理系统可以接收销售方人员输入的合同号，从合同号对应的销售方的纳税信息和购买方的纳税信息，以及购买方的所有账号，然后展示购买方的各账号。销售方人员可从购买方的各账号中选择多个账号，并针对每个账号输入商品信息。客户关系管理系统在检测到销售方人员点击提交后，将接收的每条商品信息和销售方人员选择的账号的账号标识对应，生成一条申请行信息。之后向发票系统发送包括销售方的纳税信息、购买方的纳税信息和多个账号各自对应的申请行信息的开票信息。
65.例如，图3是客户关系管理系统的申请界面的示例性示意图，销售方人员可以在申请界面中填写合同号和申请人，其中申请人为申请开票的人，也称开票人。发票抬头、发票介质和购买方地址可由销售方人员填写，或者由客户关系管理系统根据合同号从合同中获取。
66.申请行列表包括多条申请行信息，每条申请行信息包括：账号标识、商品身份标识号(identity document，id)、税收分类编码、商品名称、商品规格型号、商品金额和单位。其中，申请行信息包括的账号标识由销售方人员选择；商品id、商品金额和单位由销售方人员选择或填写；税收分类编码、商品名称和商品规格型号可由销售方人员填写，或者由客户关系管理系统基于商品id从商品库系统中查询得到。
67.在本公开的一个实施例中，申请信息的类型包括账单类型和税率类型。在此基础上，如图4所示，上述s102中根据该申请行信息包括的商品信息，确定该申请行信息的类型的方式，包括以下步骤：
68.s401、从商品库系统中查找该申请行信息包括的商品标识对应的商品出账方式。其中，商品信息包括商品标识和税收分类编码，商品标识可以为商品id。
69.商品库系统中记录了各商品标识对应的商品出账方式，商品的出账方式可以是线上业务手工出账、线下业务手工出账或者线上业务开账单(billing)出账。
70.s402、基于商品出账方式与账单类型之间的预设对应关系，确定查找到的商品出账方式对应的账单类型。
71.一种实现方式中，商品出账方式与账单类型之间的预设对应关系如表一所示，根据表1确定查找到的商品出账方式对应的账单类型。
72.表1
73.商品出账方式账单类型线上业务手工出账定制账单类型线下业务手工出账定制账单类型线上业务billing出账通用账单类型
74.例如，结合表一，当商品出账方式为线上业务手工出账时，确定账单类型为定制账单类型。
75.确定账单类型之后，可以构造合同商品账单维度地图，即将商品id和账单类型对应存储，方便查找各申请行信息的账单类型。即得到商品账单源地图(goodsbillsourcemap)[商品id，账单类型]。
[0076]
可选的，账单类型也可以称为资金池类型，定制账单类型对应定制账单资金池，通用账单类型对应通用资金池。
[0077]
确定每条申请行信息对应的账单类型之后，还可以构造账单类型维度申请明细地图，以方便区分不同账单类型的申请行信息。即得到账单源信息地图(billsourceinfomap)[账单类型,申请行信息列表]。
[0078]
s403、基于税收分类编码与税率类型之间的预设对应关系，确定该申请行信息包括的税收分类编码对应的税率类型。
[0079]
一种实现方式中，可以根据商品税率的相关规定，在发票系统本地预先配置各税收分类编码与税率类型之间的预设对应关系，之后根据该对应关系查找该申请行信息包括的税收分类编码对应的税率类型。
[0080]
例如，生活服务业的税收分类编码为3070599，对应的税率类型为6％。
[0081]
在此基础上，执行上述s103时，可以将相同账单类型以及相同税率类型的申请行信息，作为相同类型的申请行信息，再对相同类型的申请行信息进行分组。可以理解的，一张发票中的各商品的账单类型和税率类型需要相同，因此将不同账单类型及不同税率类型的申请行信息需要被分为不同的组。
[0082]
可选的，一张发票中的各商品除了账单类型和税率类型需要相同以外，还可以限定商品名称类型相同，即申请行信息的类型还包括商品名称类型。在此情况下，执行上述s103时，可以将账单类型相同、税率类型相同且商品名称类型相同的申请行信息，作为相同类型的申请行信息。
[0083]
如图2所示，商品名称为发票中的货物或应税劳务、服务名称。其中当商品为技术服务时，商品名称类型包括发票名称和服务名称，且发票名称之前存在符号“*”，发票名称和服务名称之间存在符号“*”。例如，商品名称类型为：*信息技术服务*技术服务费。
[0084]
现有技术中，销售方人员开票过程中，需要人工查找申请行信息的账单类型，再人工地对申请行信息进行分组，耗时耗力。而本公开实施例能够自动确定申请行信息的账单类型和税率类型，方便区分不同类型的申请行信息，以便后续对相同类型的申请行信息进行分组，使得不同类型的申请行信息被分在不同的组中，从而实现同一组申请行信息对应的商品，在理论上可以开具在同一张发票中，方便后续针对每组申请行信息构建发票，减少人力成本。而且本公开实施例根据申请行信息的账单类型和税率类型对申请行信息进行分组，相比于仅根据账单类型对申请行信息进行分组的方式相比，本公开实施例对申请行信息进行分组的粒度更细。
[0085]
在本公开的一个实施例中，商品信息包括商品数量和商品金额，其中，商品金额指的是一条申请行信息中包括的商品的总金额。
[0086]
在s103对相同类型的申请行信息进行分组之前，发票系统还可以对申请行信息进行拆分，发票的拆分可在事务中进行，以减少并发的拆分操作之间的影响，其中事务指的是访问并可能更新申请行信息的一个程序执行单元。拆分方式包括：针对每条申请行信息，判断该申请行信息包括的商品信息是否满足预设要求。若否，则按照该申请行信息包括的商品金额，将该申请行信息拆分为满足预设要求的多条申请行信息。反之，若申请行信息满足预设要求，则不拆分该申请行信息。
[0087]
其中，预设要求包括：商品金额除以商品数量得到的商品单价包括的小数不超过
两位、以及商品金额不超过金额上限。
[0088]
可以理解的，单张发票具有可开具的金额上限，每条申请行信息包括的商品金额不能超过该金额上限。
[0089]
在本公开实施例中，可以限制销售方人员输入的商品金额的小数不超过两位，且商品数量的小数不超过一位。
[0090]
一种实现方式中，若申请行信息包括的商品金额超过金额上限，则计算其中表示向上取整。然后计算商品数量/拆分份数，将计算结果作为拆分后的申请行信息中的商品数量。之后计算拆分后的申请行信息中的商品数量
×
商品单价，得到拆分后的申请行信息中的商品金额。申请行信息拆分前后除商品金额和商品数量以外，其他信息不变。
[0091]
例如，一条申请行信息包括：商品id为001，商品单价为10000，商品数量为10，商品金额为100000。计算拆分份数拆分后申请行信息的商品数量为10/2＝5，拆分后申请行信息的金额为10000
×
5＝50000。即拆分后的两条申请行信息均包括：商品id为001，商品单价为10000，商品数量为5，商品金额为50000。
[0092]
另一种实现方式中，若申请行信息的商品单价包括的小数超过两位，则对商品单价保留整数，并计算保留整数的商品单价与商品数量的乘积，得到该申请行信息的商品金额。计算该申请行信息的原商品金额与现商品金额的差，得到金额差值。新增一条申请行信息，则将金额差值作为新的申请行信息的商品金额，且设置该新的申请行信息的商品数量为1，且商品单价为金额差值/1，其他信息与拆分前的申请行信息相同。
[0093]
例如，一条申请行信息包括：商品id为001，商品金额为12.55，商品数量为10，商品单价为1.255。对该申请行信息，保留商品id为001，更新商品单价为1，保留商品数量为10，更新商品金额为1
×
10＝10。新增一条申请行信息，并设置商品id为001，商品金额为12.55-10＝2.55，商品数量为1，商品单价为2.55/1＝2.55。
[0094]
本公开实施例中，预设要求还可以包括其他条件，且对申请行信息的拆分方式不限于上述两种方式。
[0095]
采用上述方法，本公开实施例可以对不满足预设要求的申请行信息进行自动拆分，使得拆分后的申请行信息可以用于构建发票。避免了人工拆分申请行信息所耗费的时间和精力。
[0096]
在本公开的一个实施例中，参见图5，上述s103中对相同类型的申请行信息进行分组的方式，可以实现为分别针对每一类型的申请行信息执行以下操作：
[0097]
s501、从该类型的申请行信息中，按照顺序选择一条申请行信息。
[0098]
其中，同一种类型的申请行信息指的是通过图4所示的方式确定的类型相同且满足预设要求的各申请行信息，以及，类型相同且经拆分后满足预设要求的各申请行信息。
[0099]
可选的，可以按照申请行信息在发票信息中的排列顺序，选择申请行信息。或者也可以按照其他顺序选择申请行信息，本公开实施例对此不作具体限定。按照顺序选择申请行信息的目的是避免重复确定申请行信息所属的分组。
[0100]
s502、判断若将当前选择的申请行信息加入当前分组，当前分组对应的发票是否满足属性限制信息。若是，则执行s503；若否，则执行s504。
[0101]
其中，单张发票的属性限制信息包括：发票的金额不超过单张发票的金额上限和发票包括的发票项数量不超过单张发票的发票项数量上限。
[0102]
当前分组对应的发票，指的是利用当前分组的每条申请行信息构建的发票项，以及上述开票信息包括的购买方的纳税信息和销售方的纳税信息，构建得到的发票。
[0103]
当前分组中的一条申请行信息可以构建为发票中的一个发票项，每个发票项为发票中的一项商品数据。例如，结合图2，图2中共示出了8个发票项，为便于理解，将这8个发票项分别用虚线方框标出。每个虚线方框内包括一项由货物或应税劳务、服务名称、规格型号、单位、数量、单价、金额、税率和税额组成的商品数据，这一项商品数据称为一个发票项。
[0104]
申请行信息包括的商品信息与商品数据存在交集。例如，结合图2，假设一条申请行信息包括：商品id、税收分类编码、单位、数量和金额。发票系统可以从合同商品系统中查找商品id对应的货物或应税劳务、服务名称，以及规格型号；并确定税收分类编码对应的税率；计算金额除以数量，得到单价；计算金额乘以税率，得到税额。之后将查找到的货物或应税劳务、服务名称和规格型号，以及确定的税率，以及商品信息包括的单位、数量和金额，以及计算得到的单价和税额，组成一项商品数据。
[0105]
当前分组对应的发票的金额为当前分组中各申请行信息包括的商品金额总和。当前分组对应的发票包括的发票项数量为当前分组包括的申请行信息的条数。在判断当前分组对应的发票是否满足属性限制信息时，可以判断当前分组中各申请行信息包括的商品金额总和是否超过单张发票的金额上限，以及当前分组包括的申请行信息的条数是否超过单张发票的发票项数量上限。
[0106]
可选的，单张发票的属性限制信息还可以包括其他条件，具体可根据发票的相关规定设置，本公开实施例对此不作具体限定。例如，单张发票的属性限制信息如表2所示：
[0107]
表2
[0108]
属性限制信息要求单张电子发票金额上限99999.99元单张纸质发票金额上限1000000.00元单张电子发票的发票项数量上限8项单张纸质发票的发票项数量上限无单张发票包括的各商品的税收分类编码相同商品数量小数不超过2位商品单价/商品金额/价税合计金额小数不超过2位
[0109]
s503、将当前选择的申请行信息加入当前分组，并返回s501，直至得到该类型的所有申请行信息所属分组。
[0110]
具体的，在将当前选择的申请行信息加入当前分组后，可判断该类型的申请行信息是否均已被分组，若是，则该流程结束，若否，则返回s501，继续对下一条申请行信息进行分组。
[0111]
s504、生成下一个分组，将当前选择的申请行信息加入生成的分组，并将生成的分组作为当前分组，返回s501，直至得到该类型的所有申请行信息所属分组。
[0112]
具体的，在将当前选择的申请行信息加入当前生成的下一个分组后，可判断该类型的申请行信息是否均已被分组，若是，则该流程结束，若否，则返回s501，继续对下一条申
请行信息进行分组。
[0113]
针对s501-s504举例，假设一个类型的申请行信息包括：申请行信息1、申请行信息2和申请行信息3。生成分组1，判断申请行信息1加入分组1时，分组1对应的发票是否满足单张发票的属性限制信息。假设判断结果为满足，则将申请行信息1加入分组1。然后判断将申请行信息2加入分组1时，分组1对应的发票是否满足单张发票的属性限制信息。假设判断结果为不满足，则生成分组2，将申请行信息2加入分组2。再判断将申请行信息3加入分组2时，分组2对应的发票是否满足单张发票的属性限制信息。假设判断结果为满足，则将申请行信息3加入分组2。
[0114]
采用上述方法，本公开实施例可以对于相同类型的申请行信息，将满足单张发票的属性限制信息的申请行信息分为一组，使得后续可以根据每组申请行信息生成一张待开具发票。从而无需人工对申请行信息进行分组，减少了人工分组消耗的时间和精力。
[0115]
可选的，在上述s104构建待开具发票之后，还可以向运营管理系统发送构建的待开具发票，以使得运营管理系统存储待开具发票，以便运营人员从运营管理系统中查看和管理待开具发票。
[0116]
而且，在s104构建待开具发票之后，发票系统还可以向客户关系管理系统发送通知消息，以通知客户关系管理系统已生成待开具发票，即发票申请过程结束，后续可进入审核流程。客户关系管理系统接收到通知消息后，存储客户关系管理(customer relationship management，crm)操作记录，其中操作记录包括：本次提交的开票信息、提交开票信息的销售方人员信息、以及提交时间等。
[0117]
在本公开的一个实施例中，可以在上述s104构建待开具发票之后，设置异步线程对待开具发票进行审核，包括以下步骤：
[0118]
步骤一、获取未审核状态的待开具发票，针对每张未审核状态的待开具发票，对该待开具发票进行机审。其中，待开具发票的初始状态为未审核状态。
[0119]
可选的，可以定时获取未审核状态的待开具发票；或者监测并获取未审核状态的待开具发票；或者周期性地获取未审核状态的待开具发票。
[0120]
可选的，机审包括：审核待开具发票对应的合同信息所表示的合同是否生效、待开具发票包括的各商品是否存在、以及购买方和销售方是否存在等。本公开实施例对机审的具体方式不作限定。
[0121]
步骤二、若机审结果为审核通过，则更新该待开具发票的状态为已通过状态。之后可执行s105对待开具发票进行发票开具。
[0122]
可选的，机审结果可以是0或1，当机审结果为0时，表示审核未通过；当机审结果为1时，表示审核通过。
[0123]
步骤三、若机审结果为审核未通过，则向运营审批系统发送该待开具发票，并从运营审批系统获取对该待开具发票的人工审核结果。
[0124]
一种实现方式中，运营审批系统可以向审核人员展示接收到的待开具发票，并接收审核人员提交的人工审核结果，之后运营审批系统向发票系统发送针对该待开具发票的人工审核结果。
[0125]
步骤四、若人工审核结果为审核通过，则更新该待开具发票的状态为已通过状态。之后可执行s105对待开具发票进行发票开具。
[0126]
可选的，人工审核结果可以是0或1，当人工审核结果为0时，表示审核未通过；当人工审核结果为1时，表示审核通过。
[0127]
在本公开实施例中，若人工审核结果为审核未通过，则更新该待开具发票的状态为已拒绝状态。
[0128]
具体的，人工审核的过程包括业务人员审核和财务人员审核。当业务人员的审核结果为审核未通过时，更新待开具发票的状态为已拒绝状态。当业务人员的审核结果为审核通过时，更新待开具发票的状态为业务已审核状态。当财务人员的审核结果为审核通过时，更新待开具发票的审核状态为已通过状态。当财务人员的审核结果为审核未通过时，更新待开具发票的审核状态为财务已拒绝状态。
[0129]
采用上述方法，本公开实施例可以对待开具发票进行自动机审，提高审核效率。并在机审未通过时，进一步进行人工审核，减少机审带来的误差，提高审核准确性。
[0130]
在本公开的一个实施例中，开票信息还包括发票介质，发票介质可以是电子发票或者纸质发票。基于相同的开票信息构建的待开具发票的发票介质相同，即销售方人员提交一次开票信息，得到的开具出的发票均为纸质发票或者电子发票。
[0131]
上述s105对待开具发票进行发票开具的方式，包括以下两种情况：
[0132]
情况一、对于机审结果为审核通过的待开具发票，判断该待开具发票的发票介质是否为电子发票。若是，则调用线上开具系统对该待开具发票进行发票开具，获得电子发票。若否，则针对该待开具发票获取线下开具的纸质发票信息。
[0133]
一种实现方式中，每张待开具发票与所属的开票信息存在对应关系，发票系统在检测到待开具发票的机审结果为审核通过时，判断该待开具发票对应的开票信息包括的发票介质是否为电子发票。
[0134]
若是，则发票系统向线上开具系统发送待开具发票，并接收线上开具系统返回的电子发票。
[0135]
若否，则发票系统向用户展示待开具发票，以使得人工线下开具纸质发票；之后发票系统接收人工填写的纸质发票信息。其中，参见图2，纸质发票信息可以包括：发票代码、发票号码、开票日期和校验码。
[0136]
情况二、对于人工审核结果为审核通过的待开具发票，获取人工开具的电子发票或者纸质发票信息。
[0137]
一种实现方式中，人工审核待开具发票后，若人工审核结果为审核通过，则自动进入人工开票流程，之后发票系统接收人工输入的电子发票或者纸质发票信息。
[0138]
采用上述方法，本公开实施例可以对审核通过的待开具发票自动进行发票开具，从而得到电子发票或者纸质发票，提高开票效率。
[0139]
在本公开的一个实施例中，在上述情况一和情况二对待开具发票进行发票开具之后，发票系统还可以：对于已获得电子发票或者纸质发票信息的每张待开具发票，更新该待开具发票的状态为已开具状态。
[0140]
即，发票系统在接收到电子发票或者纸质发票信息时，将电子发票或者纸质发票信息对应的待开具发票的状态，更新为已开具状态。
[0141]
采用上述方法，本公开实施例可以对待开具发票的状态进行及时更新，提高待开具发票的状态的准确性，方便用户对待开具发票的状态进行实时监测。
[0142]
在本公开的一个实施例中，每条申请行信息还可以包括购买方的一个账号的账号标识，其中账号标识可以是账号名称或者账号id。在上述s104构建待开具发票之后，发票系统还可以通过以下步骤向用户展示虚拟发票：
[0143]
步骤1、针对构建的每张待开具发票，将该待开具发票中属于相同账号的发票项分为一组，并为每组发票项构建虚拟发票。其中，属于相同账号的发票项为通过包括相同账号标识的申请行信息构建的发票项，每个发票项为发票中的一项商品数据。
[0144]
一种实现方式中，发票系统记录了待开具发票的每个发票项对应的申请行信息。针对每张待开具发票，确定该待开具发票的每个发票项对应申请行信息包括的账号标识，将确定出的相同账号标识的发票项作为一组，得到账号地图(accountmap)[账号id，发票项列表]。后续针对每组发票项，在该待开具发票中，保留该组发票项和其他信息，并删除除该组发票项以外的其他发票项，将删除后得到的发票，作为该组发票项对应账号的虚拟发票。
[0145]
例如，图2中前3个发票项对应账号1，第4-8个发票项对应账号2，则为账号1构建的虚拟发票为在原发票的基础上删除了第4-8个发票项，其他信息保持不变。为账号2构建的虚拟发票为在原发票的基础上删除前3个发票项，其他信息保持不变。
[0146]
步骤2、向用户控制台系统发送构建的虚拟发票，以使得用户控制台系统向用户展示虚拟发票。
[0147]
一种实现方式中，发票系统向用户控制台系统发送虚拟发票，用户控制台系统存储接收到的虚拟发票，并在购买方用户登录用户控制台系统时，向购买方用户展示该用户所使用账号对应的虚拟发票。
[0148]
由于待开具发票中可能包括多个账号对应的发票项，而且由于发票金额的统计逻辑的复杂性以及单张发票的属性限制信息，发票项可能基于经过拆分后的申请行信息构建。为了让使用单个账号的购买方用户在一张发票中更清楚地对自己的发票项进行核对，本公开实施例基于真实需要开具的待开具发票，构建一张或多张虚拟发票，由于虚拟发票包括的发票项属于同一账号，使得使用该账号的购买方用户可更清楚地核对该虚拟发票中的发票项是否正确。
[0149]
可选的，构建虚拟发票之后，发票系统还可以存储虚拟发票的内容明细。其中，发票内容明细包括：价税合计金额、开票时间和申请开票的销售人员信息等。
[0150]
在本公开的一个实施例中，发票系统还可以在发票开具的过程中对各账号下的资金进行资金转移，其中资金转移可以是对统计的不同类型的金额的累加和减少，而非真实地对电子货币或纸质货币的转移。本公开实施例涉及的资金转移，包括以下三种情况：
[0151]
情况1、在构建任一虚拟发票时，确定该虚拟发票对应的第一账号，将该虚拟发票的价税合计金额从第一账号的来源池转移至第一账号的冻结池。
[0152]
其中，每个账号的来源池包括该账号的剩余可开票金额，每个账号的冻结池包括该账号正在开具的各发票的价税合计金额总和。
[0153]
一种实施方式中，结合图6，图6中每个节点均为待开具发票的一种状态。任一虚拟发票构建完成时，此时虚拟发票所属待开具发票的状态为未审核状态，发票系统确定该虚拟发票对应的账号，为方便理解，将该账号称为第一账号。从第一账号的来源池减去该虚拟发票的价税合计金额，并将第一账号的冻结池加上该虚拟发票的价税合计金额。
[0154]
情况2、在任一虚拟发票所属待开具发票的状态更新为已拒绝状态时，确定该虚拟
发票对应的第二账号，将该虚拟发票的价税合计金额从第二账号的冻结池转入第二账号的来源池。
[0155]
一种实施方式中，结合图6，当发票系统接收到运营审批系统发送的人工审核结果为财务审核未通过或者业务审核未通过时，更新待开具发票的状态为已拒绝状态。或者，当发票系统接收到运营管理系统发送的拒绝消息时，将拒绝消息所指示的待开具发票的状态更新为已拒绝状态。当任一虚拟发票所属待开具发票的状态更新为已拒绝状态时，发票系统确定该虚拟发票对应的账号，为方便理解，将该账号称为第二账号。从第二账号的冻结池减去该虚拟发票的价税合计金额，并将第二账号的来源池加上该虚拟发票的价税合计金额。
[0156]
情况3、在任一虚拟发票所属待开具发票的状态更新为已开具状态时，确定该虚拟发票对应的第三账号，将该虚拟发票的价税合计金额从第三账号的冻结池转入第三账号的消费池。
[0157]
其中，每个账号的消费池包括该账号已开具的各发票的价税合计金额总和。
[0158]
一种实施方式中，结合图6，任一虚拟发票所属待开具发票的状态更新为已开具状态时，发票系统确定该虚拟发票对应的账号，为方便理解，将该账号称为第三账号。从第三账号的冻结池减去该虚拟发票的价税合计金额，并将第三账号的消费池加上该虚拟发票的价税合计金额。
[0159]
采用上述方法，本公开实施例可以在发票开具的过程中，进行账号级别的资金转移，由此维护账号可开票金额的时效性。而且对每个账号建立各种资金池，可以方便统计账号当前的消费情况。
[0160]
除了上述三种资金转移的情况以外，还可以包括其他情况。例如，如图6所示，图6中的虚线箭头表示涉及资金转移的状态转移，实线箭头表示不涉及资金转移的状态转移。当任一虚拟发票所属待开具发票的状态由未审核状态更新为已撤回状态时，发票系统确定该虚拟发票对应的账号，将该虚拟发票的价税合计金额从该账号的冻结池转入该账号的来源池。其中，当发票系统接收到客户关系管理系统发送的撤回消息时，发票系统将撤回消息针对的待开具发票的状态由未审核状态更新为已撤回状态。
[0161]
如图6所示，当任一虚拟发票所属待开具发票的状态更新为已作废状态时，发票系统确定该虚拟发票对应的账号，将该虚拟发票的价税合计金额从该账号的消费池转入该账号的来源池。其中，在待开具发票的状态为已开具状态的情况下，当发票系统接收到客户关系管理系统发送的作废消息时，发票系统将作废消息针对的待开具发票的状态由已开具状态更新为已作废状态。或者，在待开具发票的状态为已寄送状态的情况下，当发票系统接收到用户输入的作废信息时，将作废信息针对的待开具发票的状态由已寄送状态更新为已作废状态。例如，将已开具的发票寄送给购买方后，购买方要求重开发票时，需要对该发票作废处理。
[0162]
在本公开实施例中，如图6所示，在待开具发票的状态为已开具状态的情况下，当发票系统接收到运营管理系统发送的红冲消息时，将红冲消息针对的待开具发票的状态由已开具状态更新为已红冲状态。
[0163]
参见图7，以下对本公开实施例中发票系统所执行的发票开具方法的整体流程进行说明：
[0164]
发票系统接收到开票信息后，对开票信息进行校验。具体校验方式可参考上述相关描述。
[0165]
然后，发票系统对开票信息进行预处理，包括构建goodsbillsourcemap和billsourceinfomap。
[0166]
之后发票系统根据构建的goodsbillsourcemap和billsourceinfomap，对开票信息包括的各申请行信息拆分并分组，并为每组申请行信息构建待开具发票。然后发票系统向运营管理系统发送构建的待开具发票，以使运营管理系统存储待开具发票，方便运营人员通过运营管理系统对待开具发票进行查看和管理。
[0167]
同时，发票系统针对构建的每张待开具发票，将该待开具发票中属于相同账号的发票项分为一组，并为每组发票项构建虚拟发票。然后发票系统向用户控制台系统发送构建的虚拟发票，以使得用户可通过用户控制台系统查看虚拟发票。而且，发票系统将该虚拟发票的价税合计金额从虚拟发票对应账号的来源池转移至冻结池。发票系统还将构建的待开具发票和虚拟发票存储在自身的数据库中。
[0168]
构建待开具发票之后，发票系统向客户关系管理系统发送通知消息，以通知客户关系管理系统已生成待开具发票，即发票申请过程结束，后续将进入审核流程。
[0169]
发票系统通过异步线程定时获取未审核状态的待开具发票，对该待开具发票进行机审，并判断机审结果是否为审核通过。
[0170]
若机审结果为审核通过，则发票系统确定该待开具发票审核通过，并更新该待开具发票的状态为已通过状态。之后，发票系统判断该待开具发票的发票介质是否为电子发票。若是，则发票系统调用线上开具系统对该待开具发票进行发票开具，获得线上开具系统返回的电子发票。若否，则发票系统接收用户输入的该待开具发票的纸质发票信息。之后发票系统更新该待开具发票的状态为已开具状态，同时对于该待开具发票对应的虚拟发票，将该虚拟发票的价税合计金额从该虚拟发票对应账号的冻结池转入该账号的消费池。
[0171]
若机审结果为审核未通过，则发票系统向运营审批系统发送该待开具发票，以进入人工审核流程，之后发票系统接收运营审批系统发送的对该待开具发票的人工审核结果，判断人工审核结果是否为审核通过。
[0172]
若人工审核结果为审核通过，则发票系统确定该待开具发票审核通过，更新该待开具发票的状态为已通过状态，之后接收人工输入的电子发票或者纸质发票信息。之后发票系统更新该待开具发票的状态为已开具状态，同时对于该待开具发票对应的虚拟发票，将该虚拟发票的价税合计金额从该虚拟发票对应账号的冻结池转入该账号的消费池。
[0173]
若人工审核结果为审核未通过，则发票系统确定该待开具发票审核未通过，并更新该待开具发票的状态为已拒绝状态，将待开具发票对应的虚拟发票的价税合计金额从该虚拟发票对应账号的冻结池转入该账号的来源池。
[0174]
基于相同的发明构思，本公开实施例提供了一种发票开具系统，如图8a所示，包括：客户关系管理系统801和发票系统802；
[0175]
客户关系管理系统801，用于当接收到用户触发的提交指令时，向发票系统802发送开票信息，开票信息包括销售方的纳税信息、购买方的纳税信息以及购买方的多个账号各自对应申请行信息，每条申请行信息包括商品信息；
[0176]
发票系统802，用于执行上述方法实施例中由发票系统执行的方法以进行发票开
具。
[0177]
在本公开的一个实施例中，客户关系管理系统801，还用于在接收到用户触发的提交指令之前，接收用户输入的合同号，获取合同号对应的销售方的纳税信息、购买方的纳税信息和购买方的各账号，以及接收用户针对选择的每个账号分别输入的申请行信息。
[0178]
在本公开的一个实施例中，如图8b所示，该发票开具系统还可以包括：合同商品系统803；
[0179]
合同商品系统803，用于存储各商品标识对应的商品出账方式。
[0180]
在本公开的一个实施例中，如图8b所示，该发票开具系统还可以包括：运营审批系统804；
[0181]
运营审批系统804，用于接收发票系统802发送的机审结果为审核未通过的待开具发票，展示接收的待开具发票，获取对接收的待开具发票的人工审核结果，并向发票系统802发送人工审核结果。
[0182]
在本公开的一个实施例中，如图8b所示，该发票开具系统还可以包括：线上开具系统805；
[0183]
线上开具系统805，用于接收发票系统802发送的待开具发票，对接收的待开具发票进行发票开具，得到电子发票，并向发票系统802发送电子发票。
[0184]
在本公开的一个实施例中，如图8b所示，该发票开具系统还可以包括：用户控制台系统806；
[0185]
用户控制台系统806，用于接收发票系统802发送的虚拟发票，并向用户展示虚拟发票。
[0186]
发票开具系统包括的各系统均可部署在计算机或者服务器等具备数据处理能力的电子设备中，且各系统部署的电子设备可以相同或者不同。发票开具系统中各系统的具体实现过程可参考上述方法实施例中的相关描述，此处不再赘述。
[0187]
参见图9，以下对本公开实施例提供的发票开具系统执行的发票开具过程进行具体说明：
[0188]
客户关系管理系统当接收到用户触发的提交指令时，向发票系统发送开票信息。
[0189]
发票系统对开票信息包括的申请行信息进行拆分，并基于申请行信息包括的商品标识，从合同商品系统中获取商品出账方式。并基于商品出账方式对申请行信息进行分组，为每组申请行信息构建待开具发票，向运营管理系统发送待开具发票。并基于待开具发票构建虚拟发票，向用户控制台系统发送虚拟发票。存储待开具发票和虚拟发票。之后对待开具发票进行机审，并在机审结果为审核未通过时，调用运营审批系统，由运营人员在运营审批系统对待开具发票进行人工审核，并接收运营审批系统返回的人工审核结果。在待开具发票机审通过且发票介质为电子发票时，调用线上开具系统开具电子发票。在待开具发票机审通过且发票介质为纸质发票时，获取人工输入的纸质发票信息。在待开具发票的人工审核通过时，获取人工输入的电子发票或者纸质发票信息。
[0190]
运营管理系统支持运营人员查看、管理以及下载待开具发票。
[0191]
用户控制台系统支持云用户查看和下载虚拟发票。
[0192]
基于相同的发明构思，对应于上述方法实施例，本公开实施例提供了一种发票开具装置，如图10所示，该装置包括：获取模块1001、确定模块1002、分组模块1003、构建模块
1004和开具模块1005；
[0193]
获取模块1001，用于获取开票信息，开票信息包括销售方的纳税信息和购买方的纳税信息，以及购买方的多个账号各自对应的申请行信息，每条申请行信息包括商品信息；
[0194]
确定模块1002，用于针对获取模块1001获取的每条申请行信息，根据该申请行信息包括的商品信息，确定该申请行信息的类型；
[0195]
分组模块1003，用于基于单张发票的属性限制信息，对确定模块1002确定的相同类型的申请行信息进行分组；其中，分组得到的每组申请行信息满足属性限制信息；
[0196]
构建模块1004，用于对于分组模块1003得到的每组申请行信息，基于该组申请行信息包括的商品信息、销售方的纳税信息和购买方的纳税信息，构建待开具发票；
[0197]
开具模块1005，用于对构建模块1004构建的待开具发票进行发票开具。
[0198]
在本公开的一个实施例中，其中，商品信息包括商品标识和税收分类编码，申请行信息的类型包括账单类型和税率类型；确定模块1002，具体用于：
[0199]
从商品库系统中查找该申请行信息包括的商品标识对应的商品出账方式；
[0200]
基于商品出账方式与账单类型之间的预设对应关系，确定查找到的商品出账方式对应的账单类型；
[0201]
基于税收分类编码与税率类型之间的预设对应关系，确定该申请行信息包括的税收分类编码对应的税率类型。
[0202]
在本公开的一个实施例中，商品信息包括商品数量和商品金额；该装置还可以包括：判断模块和拆分模块；
[0203]
判断模块，用于在基于单张发票的属性限制信息，对相同类型的申请行信息进行分组之前，针对每条申请行信息，判断该申请行信息包括的商品信息是否满足预设要求；
[0204]
拆分模块，用于若判断模块的判断结果为否，则按照该申请行信息包括的商品金额，将该申请行信息拆分为满足预设要求的多条申请行信息。
[0205]
在本公开的一个实施例中，预设要求包括商品金额除以商品数量得到的商品单价包括的小数不超过两位以及商品金额不超过金额上限。
[0206]
在本公开的一个实施例中，其中，分组模块1003，具体用于：
[0207]
分别针对每一类型的申请行信息执行以下操作：
[0208]
从该类型的申请行信息中，按照顺序选择一条申请行信息；
[0209]
判断若将当前选择的申请行信息加入当前分组，当前分组对应的发票是否满足属性限制信息，其中，属性限制信息包括：发票的金额不超过单张发票的金额上限和发票包括的发票项数量不超过单张发票的发票项数量上限；当前分组对应的发票的金额为当前分组中各申请行信息包括的商品金额总和，每个发票项为发票中的一项商品数据；
[0210]
若是，则将当前选择的申请行信息加入当前分组，并返回从该类型的申请行信息中，按照顺序选择一条申请行信息的步骤，直至得到该类型的所有申请行信息所属分组；
[0211]
若否，则生成下一个分组，将当前选择的申请行信息加入生成的分组，并将生成的分组作为当前分组，返回从该类型的申请行信息中，按照顺序选择一条申请行信息的步骤，直至得到该类型的所有申请行信息所属分组。
[0212]
在本公开的一个实施例中，该装置还可以包括审核模块，审核模块用于：
[0213]
在对待开具发票进行发票开具之前，获取未审核状态的待开具发票，针对每张未
审核状态的待开具发票，对该待开具发票进行机审；
[0214]
若机审结果为审核通过，则更新该待开具发票的状态为已通过状态；
[0215]
若机审结果为审核未通过，则向运营审批系统发送该待开具发票，并从运营审批系统获取对该待开具发票的人工审核结果；
[0216]
若人工审核结果为审核通过，则更新该待开具发票的状态为已通过状态。
[0217]
在本公开的一个实施例中，其中，开票信息还包括发票介质；开具模块1005，具体用于：
[0218]
对于机审结果为审核通过的待开具发票，判断该待开具发票的发票介质是否为电子发票；若是，则调用线上开具系统对该待开具发票进行发票开具，获得电子发票；若否，则针对该待开具发票获取线下开具的纸质发票信息；
[0219]
对于人工审核结果为审核通过的待开具发票，获取人工开具的电子发票或者纸质发票信息。
[0220]
在本公开的一个实施例中，该装置还可以包括：更新模块；
[0221]
更新模块，用于在对待开具发票进行发票开具之后，对于已获得电子发票或者纸质发票信息的每张待开具发票，更新该待开具发票的状态为已开具状态。
[0222]
在本公开的一个实施例中，每条申请行信息还包括购买方的一个账号的账号标识，该装置还可以包括：发送模块；
[0223]
构建模块1004，还用于在基于该组申请行信息包括的商品信息、销售方的纳税信息和购买方的纳税信息，构建待开具发票之后，针对构建的每张待开具发票，将该待开具发票中属于相同账号的发票项分为一组，并为每组发票项构建虚拟发票；其中，属于相同账号的发票项为通过包括相同账号标识的申请行信息构建的发票项，每个发票项为发票中的一项商品数据；
[0224]
发送模块，用于向用户控制台系统发送构建模块1004构建的虚拟发票，以使得用户控制台系统向用户展示虚拟发票。
[0225]
在本公开的一个实施例中，该装置还可以包括：转移模块；转移模块用于：
[0226]
在构建任一虚拟发票时，确定该虚拟发票对应的第一账号，将该虚拟发票的价税合计金额从第一账号的来源池转移至第一账号的冻结池，其中，每个账号的来源池包括该账号的剩余可开票金额，每个账号的冻结池包括该账号正在开具的各发票的价税合计金额总和；或
[0227]
在任一虚拟发票所属待开具发票的状态更新为已拒绝状态时，确定该虚拟发票对应的第二账号，将该虚拟发票的价税合计金额从第二账号的冻结池转入第二账号的来源池；或
[0228]
在任一虚拟发票所属待开具发票的状态更新为已开具状态时，确定该虚拟发票对应的第三账号，将该虚拟发票的价税合计金额从第三账号的冻结池转入第三账号的消费池，每个账号的消费池包括该账号已开具的各发票的价税合计金额总和。
[0229]
本公开的技术方案中，所涉及的开票信息的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。
[0230]
根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。
[0231]
图11示出了可以用来实施本公开的实施例的示例电子设备1100的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。
[0232]
如图11所示，电子设备1100包括计算单元1101，其可以根据存储在只读存储器(rom)1102中的计算机程序或者从存储单元1108加载到随机访问存储器(ram)1103中的计算机程序，来执行各种适当的动作和处理。在ram 1103中，还可存储电子设备1100操作所需的各种程序和数据。计算单元1101、rom 1102以及ram 1103通过总线1104彼此相连。输入/输出(i/o)接口1105也连接至总线1104。
[0233]
电子设备1100中的多个部件连接至i/o接口1105，包括：输入单元1106，例如键盘、鼠标等；输出单元1107，例如各种类型的显示器、扬声器等；存储单元1108，例如磁盘、光盘等；以及通信单元1109，例如网卡、调制解调器、无线通信收发机等。通信单元1109允许电子设备1100通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
[0234]
计算单元1101可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元1101的一些示例包括但不限于中央处理单元(cpu)、图形处理单元(gpu)、各种专用的人工智能(ai)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(dsp)、以及任何适当的处理器、控制器、微控制器等。计算单元1101执行上文所描述的各个方法和处理，例如发票开具方法。例如，在一些实施例中，发票开具方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元1108。在一些实施例中，计算机程序的部分或者全部可以经由rom 1102和/或通信单元1109而被载入和/或安装到电子设备1100上。当计算机程序加载到ram 1103并由计算单元1101执行时，可以执行上文描述的发票开具方法的一个或多个步骤。备选地，在其他实施例中，计算单元1101可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行发票开具方法。
[0235]
本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(fpga)、专用集成电路(asic)、专用标准产品(assp)、芯片上系统的系统(soc)、复杂可编程逻辑设备(cpld)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。
[0236]
用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
[0237]
在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供
指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或快闪存储器)、光纤、便捷式紧凑盘只读存储器(cd-rom)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
[0238]
为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，crt(阴极射线管)或者lcd(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
[0239]
可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(lan)、广域网(wan)和互联网。
[0240]
计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，也可以为分布式系统的服务器，或者是结合了区块链的服务器。
[0241]
应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。
[0242]
上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。