CN114266609A

CN114266609A - 一种销项发票开具方法及装置

Info

Publication number: CN114266609A
Application number: CN202111528520.6A
Authority: CN
Inventors: 魏连新
Original assignee: Beijing Ziroom Information Technology Co Ltd
Current assignee: Beijing Ziroom Information Technology Co Ltd
Priority date: 2021-12-14
Filing date: 2021-12-14
Publication date: 2022-04-01

Abstract

本发明实施例提供了一种销项发票开具方法及装置，该方法包括：获取目标交易合同的合同数据及当前应开销项发票数据；对所述合同数据进行分析，确定合同周期及收付款方式；基于所述合同周期及所述收付款方式，确定开票周期；基于所述当前应开销项发票数据和所述开票周期，确定应开发票周期及每个应开发票周期对应的应开发票额；接收所述目标交易合同对应的开票请求；基于所述开票请求、应开发票周期及每个应开发票周期对应的应开发票额，开具销项发票。实现了复杂合同场景的发票自动开具，无需人工进行审核，提高了发票开具效率的同时实现了发票精准开具，提高了用户的使用体验。

Description

一种销项发票开具方法及装置

技术领域

本发明涉及计算机应用技术领域，具体涉及一种销项发票开具方法及装置。

背景技术

对于租住行业等具有周期性付款特点的销售项目。企业需支持多种业务场景的销项发票开具，以租住行业为例，销项发票可能包含：出房房租、出房服务费、收房服务费、收出房违约金、业主装修款、保洁服务费、维修服务费等。由于各个销售合同约定的付款周期及付款方式存在差异，现有的销项发票自动开具方案难以适用复杂合同场景，使得这类行业的销项发票开具的方案只能对用户的发票申请通过人工审核的方式进行发票的开具。通过人工审核开具销项发票不仅效率低下还容易出现发票开具错误的问题。

发明内容

有鉴于此，本发明实施例提供了一种销项发票开具方法及装置，以克服现有技术中通过人工审核开具销项发票不仅效率低下还容易出现发票开具错误的问题。

本发明实施例提供了一种销项发票开具方法，包括：

获取目标交易合同的合同数据及当前应开销项发票数据，所述当前应开销项发票数据包括：当前应开销项发票总额及当前应开时间段；

对所述合同数据进行分析，确定合同周期及收付款方式；

基于所述合同周期及所述收付款方式，确定开票周期；

基于所述当前应开销项发票数据和所述开票周期，确定应开发票周期及每个应开发票周期对应的应开发票额；

接收所述目标交易合同对应的开票请求；

基于所述开票请求、应开发票周期及每个应开发票周期对应的应开发票额，开具销项发票。

可选地，所述当前应开销项发票数据包括：当前应开销项发票总额及当前应开时间段，所述获取当前应开销项发票数据，包括：

获取与所述目标交易合同对应的未开票的当前收付款数据；

基于所述当前收付款数据对应的付款项目类别，确定所述当前应开时间段；

基于所述当前收付款数据对应的收款数据和付款数据，计算当前应开销项发票总额。

可选地，所述基于所述当前应开销项发票数据和所述开票周期，确定应开发票周期及每个应开发票周期对应的应开发票额，包括：

基于所述当前应开时间段和所述开票周期，确定应开发票周期；

基于所述当前应开销项发票总额和所述应开发票周期，计算每个应开发票周期对应的应开发票额。

可选地，所述基于所述开票请求、应开发票周期及每个应开发票周期对应的应开发票额，开具销项发票，包括：

基于所述开票请求确定目标发票开具周期；

判断所述目标发票开具周期是否在所述应开发票周期内；

当所述目标发票开具周期在所述应开发票周期内时，获取目标发票开具周期对应的目标应开发票额；

基于所述目标应开发票额，按照所述开票请求中的发票开具要求开具销项发票。

可选地，所述方法还包括：

基于已开具的销项发票及对应的发票开具周期，对所述当前应开销项发票数据进行更新，并返回所述获取目标交易合同的合同数据及当前应开销项发票数据的步骤。

可选地，所述方法还包括：

获取所述目标交易合同的合同解约数据；

基于所述合同解约数据确定解约时间；

基于已开具的销项发票对应的发票开具周期与所述解约时间的关系，确定超开销项发票；

对所述超开销项发票进行红冲处理。

可选地，所述基于已开具的销项发票对应的发票开具周期与所述解约时间的关系，确定超开销项发票，包括：

判断所述解约时间是否在已开具的销项发票对应的发票开具周期内；

当所述解约时间是否在已开具的销项发票对应的发票开具周期内时，从已开具的销项发票中提取所述解约时间之后的发票开具周期对应的超开销项发票。

本发明实施例还提供了一种销项发票开具装置，包括：

获取模块，用于获取目标交易合同的合同数据及当前应开销项发票数据，所述当前应开销项发票数据包括：当前应开销项发票总额及当前应开时间段；

第一处理模块，用于对所述合同数据进行分析，确定合同周期及收付款方式；

第二处理模块，用于基于所述合同周期及所述收付款方式，确定开票周期；

第三处理模块，用于基于所述当前应开销项发票数据和所述开票周期，确定应开发票周期及每个应开发票周期对应的应开发票额；

第四处理模块，用于接收所述目标交易合同对应的开票请求；

第五处理模块，用于基于所述开票请求、应开发票周期及每个应开发票周期对应的应开发票额，开具销项发票。

本发明实施例还提供了一种电子设备，包括：存储器和处理器，所述存储器和所述处理器之间互相通信连接，所述存储器中存储有计算机指令，所述处理器通过执行所述计算机指令，从而执行本发明实施例提供方法。

本发明实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储计算机指令，所述计算机指令用于使计算机执行本发明实施例提供的方法。

本发明技术方案，具有如下优点：

本发明实施例提供了一种销项发票开具方法及装置，通过获取目标交易合同的合同数据及当前应开销项发票数据；对所述合同数据进行分析，确定合同周期及收付款方式；基于所述合同周期及所述收付款方式，确定开票周期；基于所述当前应开销项发票数据和所述开票周期，确定应开发票周期及每个应开发票周期对应的应开发票额；接收所述目标交易合同对应的开票请求；基于所述开票请求、应开发票周期及每个应开发票周期对应的应开发票额，开具销项发票。从而通过对具有周期性付款特点的销售项目的交易合同及当前应开销项发票数据进行分析，确定发票的开票周期，进而确定实时所有应开发票周期及对应应开发票额，在接收到用户的开票请求后，可基于开票请求实现自动化开票。实现了复杂合同场景的发票自动开具，无需人工进行审核，提高了发票开具效率的同时实现了发票精准开具，提高了用户的使用体验。

附图说明

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

图1为本发明实施例中的销项发票开具方法的流程图；

图2为本发明实施例中的销项发票开具系统的结构示意图；

图3为本发明实施例中的销项发票开具装置的结构示意图；

图4为本发明实施例中的电子设备的结构示意图。

具体实施方式

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

下面所描述的本发明不同实施方式中所涉及的技术特征只要彼此之间未构成冲突就可以相互结合。

基于上述问题，本发明实施例提供了一种销项发票开具方法，如图1所示，该方法具体包括如下步骤：

步骤S101：获取目标交易合同的合同数据及当前应开销项发票数据。

其中，当前应开销项发票数据包括：当前应开销项发票总额及当前应开时间段。具体地可根据收付款信息及对应的付款项目以及已经开具发票的数据得到当前还需要开具销项发票的总额及对应的可开具发票的时间段。示例性地，在本发明实施例中，目标交易合同是以租住行业的长租合同为例进行的说明，由于长租合同可能存在月付、季付、半年付、年付等多种支付方式，当前应开时间段即为当前可以开具销项发票的时间段，如：某年3月到8月的发票可以开具，并且当前应开销项发票总额为5万元等，便于后续根据用户提供的开票请求进行开票。

步骤S102：对所述合同数据进行分析，确定合同周期及收付款方式。

其中，合同周期为合同约定的交易执行时间，如：xx年3月1日，到xx年10月1日，则合同周期为合同约定的这7个月，收付款方式包括：月付、季付、半年付、年付等，本发明并不以此为限。

步骤S103：基于所述合同周期及所述收付款方式，确定开票周期。

其中，开票周期为用户可选择的最小开票时间单位，示例性地，合同周期为1年，收付款方式为月付，则开票周期可以是按月开票，合同周期为3年，收付款方式为年付，则最小开票周期可以是按年开票也可以是按月开票等，具体可根据实际需求进行灵活的设置，本发明并不以此为限。

步骤S104：基于所述当前应开销项发票数据和所述开票周期，确定应开发票周期及每个应开发票周期对应的应开发票额。

其中，该应开发票周期为将上述当前应开时间段按照开票周期进行划分，得到多个应开发票周期，并计算每个应开发票周期对应的应开发票额。具体地，上述步骤S104通过基于所述当前应开时间段和所述开票周期，确定应开发票周期；基于所述当前应开销项发票总额和所述应开发票周期，计算每个应开发票周期对应的应开发票额。

示例性地，假设当前应开销项发票总额为7000，当前应开时间段为7个月，开票周期为按月开票，则应开发票周期为7个，且每个应开发票周期对应的应开发票额为1000。此外，如果有不属于完整开票周期的情况时，如季付收款：2021.04.02－2021.07.09，账单金额9800，拆出3个月+8天，完整月份有前3个月，月数量1＊3＝3；不完整月数量＝8/30；总月数量＝3+8/30完整期间的发票应开的金额＝完整月金额＝9800/(3+8/30)＝3000，取整数，最后一个不完整月的发票应开金额＝9800－3＊3000＝800。上述示例仅为举例说明，本发明并不以此为限。

步骤S105：接收所述目标交易合同对应的开票请求。

其中，该开票请求为用户提交的针对目标交易合同的销项发票开具请求，具体可按所需开具的时间段进行申请，如：用户可以选择开具某个月的发票，或者一次选择开具某几个月的发票等，本发明并不以此为限。

步骤S106：基于所述开票请求、应开发票周期及每个应开发票周期对应的应开发票额，开具销项发票。

具体地，用户的开票请求还可以设置合并开票或单独开票，如果选择合并开票则将用户开票请求对应的所有应开发票周期的应开发票额开到一张发票上，如果选择单独开票，则按照每个应开发票周期对应的应开发票额分别开具发票。在实际应用中，上述开票请求还包括：开票的类型，如增值税电子发票、增值税专用发票等，按照用户的开票请求为用户提供相应的发票。

通过执行上述步骤，本发明实施例提供的销项发票开具方法，通过对具有周期性付款特点的销售项目的交易合同及当前应开销项发票数据进行分析，确定发票的开票周期，进而确定实时所有应开发票周期及对应应开发票额，在接收到用户的开票请求后，可基于开票请求实现自动化开票。实现了复杂合同场景的发票自动开具，无需人工进行审核，提高了发票开具效率的同时实现了发票精准开具，提高了用户的使用体验。

具体地，在一实施例中，上述步骤S101中获取当前应开销项发票数据，具体包括如下步骤：

步骤S201：获取与所述目标交易合同对应的未开票的当前收付款数据。

具体地，当前收付款数据可从收付款系统中获取所有与目标交易合同相关的收付款数据得到。

步骤S202：基于所述当前收付款数据对应的付款项目类别，确定所述当前应开时间段。

其中，付款项目类别可从收付款数据中的交易备注中获取，示例性地，当目标交易合同为租房合同时，付款项目类别可以是某一季度房租、某一年的房租等，则对应的当前应开时间段即为对应的某个季度或某一年。

步骤S203：基于所述当前收付款数据对应的收款数据和付款数据，计算当前应开销项发票总额。

具体地，在实际应用中，在目标交易合同中可能会同时存在收款项和付款项，如：租户一次性付清一年房费，在第二年的第一个月返还租户一部分费用等，此时实际前应开销项发票总额为租户支付的房费减去返还租户的费用。从而避免了销项发票超开，进一步提高了销项发票开具的准确性，保障目标交易合同各参与方的权益。

此外，在本发明另一实施例中，当目标交易合同对应有已经开具过的发票时，可以通过上述收付款数据确定总共可以开具发票的总金额及对应的可开发票时间段，然后根据目标交易合同已经开具销项发票的历史记录，确定已开发票的已开发票时间段及已开发票金额，从可开发票时间段中剔除已开发票时间段即为当前收付款数据的当前应开时间段，从可以开具发票的总金额中剔除已开发票金额，即为当前应开销项发票总额。从而进一步提高了销项发票开具的准确性，实现了不同情况下的发票开具，灵活性高，以保障最终开票结果更加符合实际情况。

具体地，，在一实施例中，上述步骤S106，具体包括如下步骤：

步骤S601：基于所述开票请求确定目标发票开具周期。

其中，目标发票开具周期为用户期望开具发票的时间段，如：某个月、某个季度、某年等。

步骤S602：判断所述目标发票开具周期是否在所述应开发票周期内。

具体地，当用户提出开票请求时，需要对开票请求进行验证，通过判断目标发票开具周期是否在所述应开发票周期内，从而验证用户提出的开票请求是否正确，如：用户已经开具过某月的销项发票，则应开发票周期中不再包括该月，如果用户再次提出该月的开票请求时，则认为目标发票开具周期不在应开发票周期内，从而结束此次开票过程，在实际应用中，为了提高用户的使用体验，可以向用户进行相应的提示，如：目标发票开具周期已开具，或不属于应开发票周期内等。

步骤S603：当所述目标发票开具周期在所述应开发票周期内时，获取目标发票开具周期对应的目标应开发票额。

具体地，目标发票开具周期可以包括一个或多个应开发票周期，不同应开发票周期可能对应有不同的应开发票额，如上述非整月的应该发票额要小于整月的应开发票额，或者房租上涨后，不同应开发票周期对应的应开发票额也不相同。从而通过获取目标发票开具周期对应的目标应开发票额，可以精确确定用户所需开具销项发票的情况，便于为用户提供销项发票开具服务。

步骤S604：基于所述目标应开发票额，按照所述开票请求中的发票开具要求开具销项发票。

其中，发票开具要求包括：发票的开具类型如：增值税电子发票或者增值税专用发票等，以及发票开具方式如：合并为一张发票开具或按照应开发票周期开具等。从而为用户提供了灵活的发票开具服务，进一步提升了用户的使用体验。

具体地，在一实施例中，上述销项发票开具方法具体还包括如下步骤：

步骤S107：基于已开具的销项发票及对应的发票开具周期，对所述当前应开销项发票数据进行更新，并返回步骤S101。

具体地，通过已开具的销项发票及对应的发票开具周期对当前应开销项发票数据中的当前应开销项发票总额及当前应开时间段进行更新，即从原来的当前应开时间段中将已开具的销项发票及对应的发票开具周期剔除，并适应对当前应开销项发票总额进行调整。从而通过实时更新前应开销项发票数据的方式，避免出现发票超开的情况，保证用户在申请开票时，可以开具的销项发票与实际需要开具的销项发票一致，进一步提高了销项发票开具的准确性。

步骤S108：获取所述目标交易合同的合同解约数据。

其中，该合同解约数据为目标交易合同约定的交易周期尚未结束，用户提出解约的数据。示例性地，假设租户签订的租房合同租房时间为3年，并已付款3年的房租，但是该租户在租房一年后提出退租，需要返还该租户预支付房租中的后两年的房租。

步骤S109：基于所述合同解约数据确定解约时间。

其中，该解约时间为根据合同解约数据中的实际的解约时间，如租户在租房满一年的某时刻提出合同解约，按照合同交易规定，仅退还用户后两年的房租，则该解约时间为租户提出解约生效时刻。

步骤S110：基于已开具的销项发票对应的发票开具周期与所述解约时间的关系，确定超开销项发票。

具体地，上述步骤S110通过判断所述解约时间是否在已开具的销项发票对应的发票开具周期内；当所述解约时间是否在已开具的销项发票对应的发票开具周期内时，从已开具的销项发票中提取所述解约时间之后的发票开具周期对应的超开销项发票。

示例性地，假设上述租户在已付款3年的房租后，提出了开票请求，并且已经开具了3年的发票，则用户在合同解约后，后两年对应的已开具发票则为超开销项发票。

步骤S111：对所述超开销项发票进行红冲处理。

具体地，通过对超开发票进行红冲处理，避免出现发票超开的情况，保证开票数据准确性，减少人工干预，降低人力人本。

下面将结合具体应用示例，对本发明实施例提供的销项发票开具方法进行详细的说明。

具体地，如图2所示，采用本发明实施例提供的销项发票开具方法构建销项发票中台1，并将销项发票中台与已有的用户终端2(如销项发票开具APP等)、合同系统3、收付款系统4(包括收款系统和付款系统)、税控服务商系统5及税局系统6等联合组成销项发票开具系统。其中，以长租业务为目标交易合同为例，对该销项发票开具系统的整体工作过程进行详细的说明。

1、客户注册登录销项发票开具APP→选择房源签订合同→支付合同账单，同步合同系统签订出房合同信息，同步收款系统收款单信息；

2、客户登录销项发票开具APP→选择出房合同→解约退款，交易系统同步合同系统出房合同解约信息，同步付款系统付款单信息；

3、收款系统收款单“已收款”，同步销项发票中台收款单开票消息，销项发票中台接收消息并存储；

4、销项发票中台定时任务处理收款单开票消息，从合同系统获取出房合同信息，从收款系统获取收款单信息，从付款系统获取付款单信息，系统自动生成发票应开数据并落库存储。发票应开金额＝收款单金额－付款单金额(收款单和付款单的相同费用项金额相减)；

5、客户登录销项发票开具APP→进入“我的工具箱”点击“开发票”图标→选择开票业务→可开发票列表，APP页面可开发票列表，系统获取销项发票中台的发票应开数据；

6、客户勾选需开发票数据→选择发票类型(增值税电子发票或者增值税专用发票)→确认发票类型→提交发票申请。如果选择发票类型为增值税专用发票，需要是企业客户且完成专票资质申请审核通过，才可以提交发票申请；

7、客户销项发票开具APP提交发票申请，系统自动对接销项发票中台生成发票订单，发票订单审核通过后，销项发票中台自动对接税控服务商系统生成发票订单，税控服务商系统对接税局系统开具蓝票；

8、税局系统发票开票成功后，已开发票数据对接税控服务商，税控服务商系统接收发票数据后，自动对接销项发票中台已开发票数据，销项发票中台接收发票数据后，发票类型是增值税电子发票时，已开发票数据给客户发送邮件通知。发票类型是增值税专用发票时，税务人员打印发票后，纸质发票给客户发送快递邮寄；

9、客户登录销项发票开具APP→进入“我的工具箱”点击“开发票”图标→开票历史→查看已开发票，APP页面已开发票列表，系统获取销项发票中台的已开发票数据。

以上9个流程，支撑长租业务客户开具发票的完整线上化流程，涉及销项发票开具APP、合同系统、收付款系统、销项发票中台、税务服务商系统、税局系统等多个系统交互对接。

支持长租业务客户开具发票，销项发票中台最重要的功能是生成发票应开，保证客户开具发票数据的准确性、及时性，系统实现功能逻辑如下：系统接收到出房合同收款单“已收款”消息通知，系统自动获取合同系统出房合同信息、收款系统收款单信息、付款系统付款单信息，生成发票应开数据：购买方名称、纳税人识别号、地址、电话、开户行及账号字段获取合同系统出房合同信息；销售方名称、纳税人识别号、地址、电话、开户行及账号、收款人、复核、开票人字段获取销项发票中台中维护的公司主体信息；货物或应税劳务、服务名称、规格型号、单位、税率，根据收款系统收款单的费用项，匹配销项发票中台中维护的商品税率信息配置规则获取；单价、数量、不含税金额、税额、含税金额，根据收款单的费用项，匹配销项发票中台中维护的商品税率信息配置规则，判断该费用项是否需要按月维度拆分发票应开，如果需要按月维度拆分，需要根据收款单的账单期间、金额字段，通过系统算法拆分计算得出最小颗粒度月度的发票应开；说明：长租业务客户支付房租费用项，有多种支付方式：月付、季付、半年付、年付，销项发票中台系统需要根据房租费用项类型，自动拆分计算得出每月房租的发票应开金额。

客户在APP，可以勾选1条或多条房租发票应开数据，提交开票申请，系统自动合并多条发票应开生成发票订单，多条发票应开金额加和、开票期间合并；

客户合同未到期解约退费，解约日期之后开具的发票需要自动红冲处理，发票应开按照实际支付金额重新计算(收款单金额－付款单金额)，以免超开发票，规避税务合规风险。

示例性地，租住行业不同于其他行业，一笔交易订单对应开具一张发票。与租客签订合同，包含房租、服务费费用项，一个合同会分多次收款，一个收款单对应拆分多笔发票应开，多笔发票应开可申请开具多张发票。与租客签订合同，合同周期有三个月、半年、一年、两年、三年，尾房可能是5个月20天，合同支付方式有月付、季付、半年付、年付、尾房一次付清。租客会按月申请发票，用于提取公积金、公司报销，可能1次申请1月、多月。

根据租住业务需求，销项发票中台根据合同、收款单、付款单数据，获取金额、账单周期字段数值，按照账单周期拆分收款金额，每月生成1笔发票应开，租客可以申请一笔发票应开开具一张发票，或者申请多笔发票应开合并开具一张发票。租住业务开票规则是，收款单已收款即可申请开票，即提前开具未住期间的发票。当租客已经申请发票，租住中途合同解约退款时，解约日期之后开过的发票，根据合同已解约状态和解约日期，系统自动检索解约日期之后的超开发票，将超开发票自动红冲处理，且重新计算生成发票应开，支持重新提交开票申请。

根据收款单的金额、账单周期拆分发票应开的具体过程为：

每个月度日期拆分：如果最后一个月不是完整周期月度，则单独做为一个周期；生成发票应开的数量，按照月度进行拆分：完整月份月数量＝1；不完整月份月数量＝实际天数/30，实际天数＝账单周期截止日－账单周期开始日+1。生成发票应开的总数量＝完整月份数量+不完整月份数量合计；

生成发票应开的金额：完整月的金额＝账单金额/(完整月份数量+不完整月份数量合计)，取整数；前面每个完整期间的发票应开金额＝完整月的金额；最后一个发票应开金额＝账单金额－前面的发票应开金额合计

如何判断一个月不是完整月：使用这个区间的期间，按照算法推算出完整月的终止日期，发现实际日期＜终止日期，则不是完整月。举例说明：

例子1：没有不完整月份

季付收款：2021.04.02－2021.07.01，账单金额9000

拆出3个月，月数量1＊3

每个月账单金额＝完整月金额＝9000/3＝3000

例子2：有不完整月份

季付收款：2021.04.02－2021.07.09，账单金额9800

拆出3个月+8天，完整月份有前3个月，月数量1＊3＝3；不完整月数量＝8/30；总月数量＝3+8/30

完整期间的发票应开的金额＝完整月金额＝9800/(3+8/30)＝3000，取整数

末期的发票应开金额＝9800－3＊3000＝800

如何判断末期的发票应开不是完整月：最后一个区间正常拆分结果是2021.07.02－2021.08.01，实际日期2021.07.09＜2021.08.01，故此区间不是完整月。

再举例说明，按照实际业务场景的时间顺序，租客签订合同→支付收款单→系统生成发票应开→支付收款单→系统生成发票应开→客户申请开发票→客户解约合同→系统自动超开发票红冲→系统自动重新生成发票应开：

2021.01.08，张三在APP签订出房合同，房租月租金1000，租住1年，合同周期为2021.01.10～2022.01.09，支付方式为季付。

2021.01.09，张三支付第1个季度房租费用，收款单信息如表1所示：

表1

收款单号	房租金额	账单周期	支付日期	收款单状态
					Sk001	3000	2021.01.10～2021.04.09	2021.01.09	已收款
Sk002	3000	2021.04.10～2021.07.09	2021.04.09	未收款
					Sk003	3000	2021.07.10～2021.10.09	2021.07.09	未收款
Sk004	3000	2021.10.10～2022.01.09	2021.10.09	未收款

销项发票中台接收到收款系统收款信息(sk001已收款)，生成发票应开数据如表2：

表2

收款单号	发票应开编号	房租金额	账单周期	发票应开状态
					Sk001	Yk001	1000	2021.01.10～2021.02.09	待申请
Sk001	Yk002	1000	2021.02.10～2021.03.09	待申请
					Sk001	Yk003	1000	2021.03.10～2021.04.09	待申请

2021.04.20，张三在APP，勾选发票应开，提交3次开票申请：第1次勾选发票应开Yk001、Yk002，第2次勾选发票应开Yk003、Yk004、Yk005，第3次勾选发票应开Yk006，生成3张发票订单，勾选发票应开对应的发票订单如表3所示，其中，发票应开Yk001、Yk002，金额相加是2000，开票期间合并是2021.01.10～2021.03.09，发票应开Yk003、Yk004、Yk005，金额相加是3000，开票期间合并是2021.03.10～2021.06.09，发票应开Yk006，金额是1000，开票期间是2021.06.10～2021.07.09。然后销项发票中台将该开票信息通过税务服务商系统发送给税局系统为张三开具蓝票。

表3

2021.05.02，张三在APP，申请合同解约，解约日期是2021.05.03，房租退款2200；2021.05.03，销项发票中台接收合同信息，合同状态已解约，解约日期2021.05.03，系统规则判断已开发票Fp002、Fp003的开票期间，包含2021.05.03之后的，这两张发票为超开发票，自动调取第三方税控服务商系统进行发票红冲处理，且发票Fp002、Fp003红冲后，对应的发票应开自动释放后，根据合同解约日期和退款金额重新计算生成发票应开，重新生成的发票应开如表4所示：

表4

通过系统中台化设计思维，销售公司主体、售卖商品和服务的税率信息，在销项发票中台统一维护，基础数据集中管理；发票数据源统一，来源签约出房合同、收款单、付款单，发票数据可追溯，系统留存完整数据链路查询；根据业务规则，系统自动生成可开发票数据，保证开票数据准确性，合规性；开票全流程线上化对接，客户提交开票申请，税务完成开票处理，优化业务作业流程，节省业务人员(包含客服、销售、商务人员等)、财务人员人力成本；系统具有高可拓展性，系统功能设计，可拓展支持业主房租、服务费、违约金、装修费、保洁费、维修费等更多业务开票场景。

采用本发明实施例提供的销项发票开具方法建立的销项发票开具系统，通过利用中台化设计思维，各业务开发票由销项发票中台统一支持，无需各业务线分别开发功能对接；基于长租业务等周期性付款业务特点，既有周期型房租、服务费销售项目，又有违约金、装修费、保洁费、维修费一次性销售项目。销项发票中台统一生成可开发票数据，即支持周期型拆分月维度，也支持一次性不拆分维度；为公司税务合规重要查验系统，保证发票数据可溯源，与业务收款付款实时交互，保证数据真实性、准确性、及时性；具有多种数据看板，包含可开票数据、已开票数据、未开票数据，为税务纳税申报提供数据支持。

本发明实施例还提供了一种销项发票开具装置，如图3所示，该销项发票开具装置包括：

获取模块101，用于获取目标交易合同的合同数据及当前应开销项发票数据。详细内容参见上述方法实施例中步骤S101的相关描述，在此不再进行赘述。

第一处理模块102，用于对所述合同数据进行分析，确定合同周期及收付款方式。详细内容参见上述方法实施例中步骤S102的相关描述，在此不再进行赘述。

第二处理模块103，用于基于所述合同周期及所述收付款方式，确定开票周期。详细内容参见上述方法实施例中步骤S103的相关描述，在此不再进行赘述。

第三处理模块104，用于基于所述当前应开销项发票数据和所述开票周期，确定应开发票周期及每个应开发票周期对应的应开发票额。详细内容参见上述方法实施例中步骤S104的相关描述，在此不再进行赘述。

第四处理模块105，用于接收所述目标交易合同对应的开票请求。详细内容参见上述方法实施例中步骤S105的相关描述，在此不再进行赘述。

第五处理模块106，用于基于所述开票请求、应开发票周期及每个应开发票周期对应的应开发票额，开具销项发票。详细内容参见上述方法实施例中步骤S106的相关描述，在此不再进行赘述。

通过上述各个组成部分的协同合作，本发明实施例提供的销项发票开具装置，通过对具有周期性付款特点的销售项目的交易合同及当前应开销项发票数据进行分析，确定发票的开票周期，进而确定实时所有应开发票周期及对应应开发票额，在接收到用户的开票请求后，可基于开票请求实现自动化开票。实现了复杂合同场景的发票自动开具，无需人工进行审核，提高了发票开具效率的同时实现了发票精准开具，提高了用户的使用体验。

上述各个模块的更进一步的功能描述与上述对应方法实施例相同，在此不再赘述。

根据本发明实施例还提供了一种电子设备，如图4所示，该电子设备可以包括处理器901和存储器902，其中处理器901和存储器902可以通过总线或者其他方式连接，图4中以通过总线连接为例。

处理器901可以为中央处理器(Central Processing Unit，CPU)。处理器901还可以为其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等芯片，或者上述各类芯片的组合。

存储器902作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序、非暂态计算机可执行程序以及模块，如本发明方法实施例中的方法所对应的程序指令/模块。处理器901通过运行存储在存储器902中的非暂态软件程序、指令以及模块，从而执行处理器的各种功能应用以及数据处理，即实现上述方法实施例中的方法。

存储器902可以包括存储程序区和存储数据区，其中，存储程序区可存储操作装置、至少一个功能所需要的应用程序；存储数据区可存储处理器901所创建的数据等。此外，存储器902可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施例中，存储器902可选包括相对于处理器901远程设置的存储器，这些远程存储器可以通过网络连接至处理器901。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

一个或者多个模块存储在存储器902中，当被处理器901执行时，执行上述方法实施例中的方法。

上述电子设备具体细节可以对应参阅上述方法实施例中对应的相关描述和效果进行理解，此处不再赘述。

本领域技术人员可以理解，实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，实现的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，存储介质可为磁碟、光盘、只读存储记忆体(Read－Only Memory，ROM)、随机存储记忆体(Random Access Memory，RAM)、快闪存储器(Flash Memory)、硬盘(Hard Disk Drive，缩写：HDD)或固态硬盘(Solid－State Drive，SSD)等；存储介质还可以包括上述种类的存储器的组合。

虽然结合附图描述了本发明的实施例，但是本领域技术人员可以在不脱离本发明的精神和范围的情况下作出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。

Claims

1.一种销项发票开具方法，其特征在于，包括：

对所述合同数据进行分析，确定合同周期及收付款方式；

基于所述合同周期及所述收付款方式，确定开票周期；

接收所述目标交易合同对应的开票请求；

2.根据权利要求1所述的方法，其特征在于，所述获取当前应开销项发票数据，包括：

获取与所述目标交易合同对应的未开票的当前收付款数据；

3.根据权利要求2所述的方法，其特征在于，所述基于所述当前应开销项发票数据和所述开票周期，确定应开发票周期及每个应开发票周期对应的应开发票额，包括：

4.根据权利要求1所述的方法，其特征在于，所述基于所述开票请求、应开发票周期及每个应开发票周期对应的应开发票额，开具销项发票，包括：

基于所述开票请求确定目标发票开具周期；

判断所述目标发票开具周期是否在所述应开发票周期内；

5.根据权利要求2所述的方法，其特征在于，还包括：

6.根据权利要求2所述的方法，其特征在于，还包括：

获取所述目标交易合同的合同解约数据；

基于所述合同解约数据确定解约时间；

对所述超开销项发票进行红冲处理。

7.根据权利要求6所述的方法，其特征在于，所述基于已开具的销项发票对应的发票开具周期与所述解约时间的关系，确定超开销项发票，包括：

8.一种销项发票开具装置，其特征在于，包括：

9.一种电子设备，其特征在于，包括：

存储器和处理器，所述存储器和所述处理器之间互相通信连接，所述存储器中存储有计算机指令，所述处理器通过执行所述计算机指令执行权利要求1－7任一项所述方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机指令，所述计算机指令用于使计算机执行权利要求1－7任一项所述的方法。