一种付款管理方法及装置与流程

本申请涉及软件系统领域，尤其涉及一种付款管理方法及装置。

背景技术：

在公司和客户完成业务项目时，一般由于产品或服务的特性，货款由付款方分步支付；根据公司和客户之间签订的合同，当达到付款条件时，请款方一般会向付款方发出请款申请单和发票，付款方根据合同付款条约、请款申请单以及请款方提供的请款材料(包括发票及业务办理证明文件等)进行付款审核。当付款方审核通过之后，将该阶段对应的业务费用支付给请款方。目前，在付款管理流程需要付款方安排专业人员负责业务审核和业务付款，并进行发票验证及开票抄税。付款流程不仅繁琐、耗时耗力，且可能由于人员的操作不当或者粗心导致账目管理混乱、单据遗漏、审核失误以及付款出现纰漏等问题，处理周期不稳定。

因此，如何有效管理付款审核的流程，减少工作失误的发生，是亟待解决的问题。

技术实现要素：

本申请实施例提供一种付款管理方法及装置，有效地管理付款审核的流程，减少工作失误的发生。

第一方面，本申请实施例提供了一种付款管理方法，应用于区块链节点设备，可包括：

获取请款申请单和请款请求；

根据所述请款申请单审核所述请款请求，所述请款请求包括业务发票和目标业务完成情况；

在所述请款请求通过审核之后，向所述请款单位付款。

通过实施本申请实施例，在收到请款申请单和请款请求后对请款请求进行审核，并基于区块链技术存储业务发票和收款记录，有利于准确审请款信息和支付款项，并且能够提高审核效率，区别于现有技术中的人工审核业务内容和相应的业务发票，再支付业务金额的情况，本申请实施例实现了基于业务合同自动完成付款的相关操作，比如实现自动验证收到的业务发票、开票抄税、存储所有付款记录等。实施本申请实施例，通过付款流程管理的自动化以及对付款相关信息的管理和存储，简化了付款审核的流程，节约了时间和人力成本，避免账目管理混乱、单据遗漏、审核失误等问题，处理周期稳定，有效地管理付款审核流程，减少出现工作失误。

在一种可能的实现方式中，所述请款申请单包括业务合同的名称、所述业务合同的编号、请款总金额、请款分期金额、请款单位、目标业务完成条件和付款形式，所述根据所述请款申请单审核所述请款请求，包括：根据所述请款申请单和所述业务发票，确认所述请款单位；判断所述目标业务完成情况是否达到所述目标业务完成条件；在确认达到所述目标业务完成条件之后，根据付款形式判断所述请款请求中的请款金额为请款总金额或者请款分期金额。

在一种可能的实现方式中，所述向请款单位付款之前，还包括：调用票据审核接口检验所述业务发票的真实性；当确认所述业务发票真实，调用报税接口完成对应税务的报税操作。

在一种可能的实现方式中，所述向所述请款单位付款之后，还包括：存储付款记录、所述请款申请单和所述请款请求中的一个或者多个。

在一种可能的实现方式中，所述根据所述请款申请单和所述业务发票，确认所述请款单位，包括：识别所述业务发票中的请款单位，将识别出的请款单位与所述请款申请单的请款单位进行比对，确认所述请款单位。

在一种可能的实现方式中，所述向所述请款单位付款之后，还包括：确认向所述请款单位付款成功，向所述请款单位发送付款完成信息。

在一种可能的实现方式中，所述获取请款申请单和请款请求之后，还包括：根据所述请款申请单的编号识别所述请款单位是否重复请款；在识别出所述请款单位重复请款的情况下，拒绝所述请款单位的请款申请。

第二方面，本申请实施例提供了一种付款管理装置，可包括：

获取单元，用于获取请款申请单和请款请求，所述请款申请单包括业务合同的名称、所述业务合同的编号、请款总金额、请款分期金额、请款单位、目标业务完成条件、目标业务完成情况和付款形式中的一种或者多种；

审核单元，用于根据所述请款申请单审核所述请款请求，所述请款请求包括业务发票；

付款单元，用于在所述请款请求通过审核之后，向所述请款单位付款。

在一种可能的实现方式中，所述请款申请单包括业务合同的名称、所述业务合同的编号、请款总金额、请款分期金额、请款单位、目标业务完成条件和付款形式，所述审核单元，还包括：

确认单元，用于根据所述请款申请单和所述业务发票，确认所述请款单位；

判断单元，用于判断所述目标业务完成情况是否达到所述目标业务完成条件；在确认达到所述目标业务完成条件之后，根据付款形式判断所述请款请求中的请款金额为请款总金额或者请款分期金额。

在一种可能的实现方式中，所述装置还包括调用单元，用于在向请款单位付款之前，调用票据审核接口检验所述业务发票的真实性；当确认所述业务发票真实，调用报税接口完成对应税务的报税操作。

在一种可能的实现方式中，所述装置还包括存储单元，用于在向所述请款单位付款之后，存储付款记录、所述请款申请单和所述请款请求中的一个或者多个。

在一种可能的实现方式中，所述确认单元，具体用于：识别所述业务发票中的请款单位，将识别出的请款单位与所述请款申请单的请款单位进行比对，确认所述请款单位。

在一种可能的实现方式中，所述装置还包括发送单元，用于：确认向所述请款单位付款成功，向所述请款单位发送付款完成信息。

在一种可能的实现方式中，所述装置还包括识别单元，用于：根据所述请款申请单的编号识别所述请款单位是否重复请款；在识别出所述请款单位重复请款的情况下，拒绝所述请款单位的请款申请。

第三方面，本申请实施例提供了一种付款管理设备，包括存储部件、通信部件和处理部件，存储部件、通信部件和处理部件相互连接，其中，存储部件用于存储数据处理代码，通信部件用于与外部设备进行信息交互；处理部件被配置用于调用程序代码，执行上述第一方面所述的方法，此处不再赘述。

第四方面，本申请实施例提供了一种计算机可读存储介质，其特征在于，计算机存储介质存储有程序指令，程序指令当被处理器执行时使处理器执行第一方面所述方法，此处不再赘述。

第五方面，本申请实施例还提供了一种计算机程序，该计算机程序可以包括程序指令，当该计算机程序被计算机执行时，使得计算机可以执行包括上述第一方面所述的方法，此处不再赘述。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对本申请实施例或现有技术描述中所需要使用的附图作简单地介绍。

图1是本申请实施例提供的一种付款管理系统架构示意图；

图2是本申请实施例提供的一种付款管理方法的流程示意图；

图3是本申请实施例提供的一种付款管理装置的结构示意图；

图4是本申请实施例提供的一种付款管理设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

本申请的说明书和权利要求书及所述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其他实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其他实施例相结合。本申请实施例的技术方案可以应用于数据处理，聚类分析等领域。当方法、装置应用的领域和场景不同时，本申请实施例中具体设备、场地的名称也会不同。

首先，对本申请中的部分用语进行解释说明，以便于本领域技术人员理解。

(1)请款单，或称请款申请单，是请予付款的申请单据，是财务支付款项的原始凭证。请款单可根据具体情况自行设计，一般有标题，请款事由，日期等。请款单作为单位内部因业务发生向有关领导进行申请的传递凭证，一般应经过单位内部审批流程，部门和分管领导审核，最后由主管领导签字批准，财务以此作为付款的依据。

(2)发票，是指一切单位和个人在购销商品、提供或接受服务以及从事其他经营活动中，所开具和收取的业务凭证，是会计核算的原始依据，也是审计机关、税务机关执法检查的重要依据。收据才是收付款凭证，发票只能证明业务发生了，不能证明款项是否收付。也是经济活动中，由出售方向购买方签发的文本，内容包括向购买者提供产品或服务的名称、质量、协议价格。除了预付款以外，发票必须具备的要素是根据议定条件由购买方向出售方付款，必须包含日期和数量。为内部审计及核数，每一张发票都必须有独一无二的流水账号码，防止发票重复或跳号。

(3)报税，向税务部门申报并办理有关纳税手续。纳税人进行申报的主要方式为网上申报。为了更好的服务广大纳税人，也可以通过手机进行报税，需要手机的ca数字证书。

下面先对本申请实施例所基于的其中一种系统框架进行描述，本申请提出的一种付款管理方法可以应用于该系统架构。请参见图1，图1是本申请实施例提供的一种付款管理方法的系统架构示意图，如图1所示，该系统架构包含了多个区块链网络中的节点设备，其中，节点设备在付款管理过程中，可以分为请款设备和付款设备。本申请实施例对节点设备、请款设备和付款设备的数量不作限定，图中的付款设备以终端(图中所示终端为电脑)为例进行说明。基于区块链技术构建的区块链网络不具有中心服务器，区块链设备由有多个区块链节点设备组成并集中提供算力，构成区块链网络。其中，

终端，是指通信终端等计算机网络中处于网络最外围的设备，例如：终端可以为手机或笔记本电脑等，主要可以用于数据的输入以及处理结果的输出等。在本申请实施例中，当终端设备为付款设备时，获取请款申请单和请款请求；根据所述请款申请单审核所述请款请求，所述请款请求包括业务发票；在所述请款请求通过审核之后，向所述请款单位付款。可选地，当终端用作请款设备时，可以接收业务完成指令；调用开票接口生成所述目标业务的业务发票；识别所述业务发票中的付款单位，根据所述付款单位发送请款请求，再接收业务合同；根据所述业务合同生成请款申请单，向所述付款单位发送所述请款申请单。在本申请实施例中的终端，指的是区块链节点设备，可以包括区块链请款设备和区块链付款设备，其中，区块链请款设备和区块链付款设备可以是同一个设备，不同的设备名称是用于区分该设备在收付款过程中所起的作用；区块链请款设备和区块链付款设备也可以是不同的设备，比如，一部分节点设备的专门负责请款或者付款。在本申请实施例中，以终端(即区块链中节点设备)用作付款设备为例进行描述，付款设备获取请款申请单和请款请求；根据所述请款申请单审核所述请款请求，所述请款请求包括业务发票和目标业务完成情况；在所述请款请求通过审核之后，向所述请款单位付款。

可以理解的是，图1所示的内容只是本申请实施例中的一种示例性的实施方式。本申请实施例中的系统架构可以包括但不仅限于以上系统架构。

下面结合上述系统架构和本申请中提供的付款管理方法的实施例，对本申请中提出的技术问题进行具体分析和解决。

请参见图2，图2是本申请实施例提供的一种付款管理方法的流程示意图，该基于付款管理方法可以应用于付款管理系统(包括上述架构)。其中，所述付款管理系统包括一对交互的终端，下面将结合图2，以终端(作为付款设备)为执行主体为例，从付款设备(即区块链中节点设备)的单侧进行描述，该方法可以包括以下步骤s201-步骤s206，可选的步骤可以包括步骤s202、步骤s204和步骤s206。

步骤s201：获取请款申请单和请款请求。

具体地，付款设备从请款设备同时获取请款申请单和请款请求，请款申请单可以包括业务完成的证明材料、业务发票信息以及请款单位和付款单位双方签订的业务合同的内容；请款请求用于请求付款设备进行付款审核并向请款设备对应的请款单位支付费用。可选地，付款设备在接收到请款设备(另一个节点设备)发送的请款请求，再根据存储的业务合同信息生成请款申请单。

步骤s202：根据所述请款申请单的编号识别所述请款单位是否重复请款；在识别出所述请款单位重复请款的情况下，拒绝所述请款单位的请款申请。

具体地，付款设备获得请款申请单的编号(每一个请款申请单的编号唯一)，将请款申请单的编号与付款记录中的请款申请单的编号进行对比，如果获得请款申请单的编号符合之前付款记录中的编号，判断该请款申请单为重复请款的申请单，拒绝通过该申请单和支付费用。

步骤s203：根据所述请款申请单审核所述请款请求。

具体地，付款设备根据所述请款申请单的详细内容，如约定的业务完成条件、请款方信息、付款形式和相关金额等，判断业务发票的请款单位以及发票金额是否符合付款要求，以及请款单位的目标业务完成情况是否达标；所述请款请求包括业务发票和目标业务完成情况。

在一种可能的实现方式中，所述请款申请单包括业务合同的名称、所述业务合同的编号、请款总金额、请款分期金额、请款单位、目标业务完成条件和付款形式，所述根据所述请款申请单审核所述请款请求，包括：根据所述请款申请单和所述业务发票，确认所述请款单位；判断所述目标业务完成情况是否达到所述目标业务完成条件；在确认达到所述目标业务完成条件之后，根据付款形式判断所述请款请求中的请款金额为请款总金额或者请款分期金额。例如，付款设备先根据请款请求中的业务发票确认请款单位a，根据请款单位a提供的业务完成证明和合同中关于业务的约定，确认请款单位a的确完成请款金额对应的业务要求。如果该请款金额是一次性的支付，就检验该金额是否与总金额数目一致；如果该请款金额是分期支付中的一笔分期金额，就检验该金额是否与对应的期数的金额一致。

在一种可能的实现方式中，所述根据所述请款申请单和所述业务发票，确认所述请款单位，包括：识别所述业务发票中的请款单位，将识别出的请款单位与所述请款申请单的请款单位进行比对，确认所述请款单位。例如，付款设备基于业务发票获得请款单位的名称以及纳税人识别号，与请款申请单中请款单位名称和纳税人识别号进行对比，当业务发票和请款申请单中的请款单位名称和纳税人识别号都符合时，确认该请款单位为正确的请款单位。

步骤s204：调用票据审核接口检验所述业务发票的真实性；当确认所述业务发票真实，调用报税接口完成对应税务的报税操作。

具体地，付款设备调用票据审核接口检验业务发票类型、格式是否正确，发票的印章是否正确，校验发票的校验码，通过检索发票代码和号码查询发票信息以及解析发票密码区的信息。在确认所述业务发票真实无误之后，调用报税接口完成报税。

步骤s205：在所述请款请求通过审核之后，向所述请款单位付款。

具体地，付款设备在所述请款请求通过审核之后，接收审核通过的指令，将预设银行账户或者其他金融账户的余额转入请款单位制定的账户。

步骤s206：存储付款记录、所述请款申请单和所述请款请求中的一个或者多个。

具体地，付款设备存储每一次成功付款的付款记录、所述请款申请单和所述请款请求中的一个或者多个，并将存储的一个或者多个信息发送给区块链网络中其他的节点设备，同时存储前述信息。

在一种可能的实现方式中，所述向所述请款单位付款，还包括：确认向所述请款单位付款成功后，向所述请款单位发送付款完成信息。例如，付款设备将金额从某个银行账户转出后，收到银行的转出业务完成的回执信息；付款设备向请款设备发送付款完成信息，用于通知请款单位已经成功支付了相关业务的费用。

通过实施本申请实施例，在收到请款申请单和请款请求后对请款请求进行审核，并基于区块链技术存储业务发票和收款记录，有利于准确审请款信息和支付款项，并且能够提高审核效率，区别于现有技术中的人工审核业务内容和相应的业务发票，再支付业务金额的情况，本申请实施例实现了基于业务合同自动完成付款的相关操作，比如实现自动验证收到的业务发票、开票抄税、存储所有付款记录等。实施本申请实施例，通过付款流程管理的自动化以及对付款相关信息的管理和存储，简化了付款审核的流程，节约了时间和人力成本，避免账目管理混乱、单据遗漏、审核失误等问题，处理周期稳定，有效地管理付款审核流程，减少出现工作失误。

上述详细阐述了本申请实施例的方法，下面提供了本申请实施例的相关装置。

请参见图3，图3是本申请实施例提供的一种付款管理装置的结构示意图。所述付款管理装置30，可以包括获取单元301、审核单元302、付款单元303、确认单元304、判断单元305、调用单元306、存储单元307、发送单元308和识别单元309，可选的单元可以包括确认单元304、判断单元305、调用单元306、存储单元307、发送单元308和识别单元309。

获取单元301，用于获取请款申请单和请款请求，所述请款申请单包括业务合同的名称、所述业务合同的编号、请款总金额、请款分期金额、请款单位、目标业务完成条件、目标业务完成情况和付款形式中的一种或者多种；

审核单元302，用于根据所述请款申请单审核所述请款请求，所述请款请求包括业务发票；

付款单元303，用于在所述请款请求通过审核之后，向所述请款单位付款。

在一种可能的实现方式中，所述请款申请单包括业务合同的名称、所述业务合同的编号、请款总金额、请款分期金额、请款单位、目标业务完成条件和付款形式，所述审核单元302，还包括：

确认单元304，用于根据所述请款申请单和所述业务发票，确认所述请款单位；

判断单元305，用于判断所述目标业务完成情况是否达到所述目标业务完成条件；在确认达到所述目标业务完成条件之后，根据付款形式判断所述请款请求中的请款金额为请款总金额或者请款分期金额。

在一种可能的实现方式中，所述装置还包括调用单元306，用于在向请款单位付款之前，调用票据审核接口检验所述业务发票的真实性；当确认所述业务发票真实，调用报税接口完成对应税务的报税操作。

在一种可能的实现方式中，所述装置还包括存储单元307，用于在向所述请款单位付款之后，存储付款记录、所述请款申请单和所述请款请求中的一个或者多个。

在一种可能的实现方式中，所述确认单元304，具体用于：识别所述业务发票中的请款单位，将识别出的请款单位与所述请款申请单的请款单位进行比对，确认所述请款单位。

在一种可能的实现方式中，所述装置还包括发送单元308，用于：确认向所述请款单位付款成功，向所述请款单位发送付款完成信息。

在一种可能的实现方式中，所述装置还包括识别单元309，用于：根据所述请款申请单的编号识别所述请款单位是否重复请款；在识别出所述请款单位重复请款的情况下，拒绝所述请款单位的请款申请。

通过实施本申请实施例，在收到请款申请单和请款请求后对请款请求进行审核，并基于区块链技术存储业务发票和收款记录，有利于准确审请款信息和支付款项，并且能够提高审核效率，区别于现有技术中的人工审核业务内容和相应的业务发票，再支付业务金额的情况，本申请实施例实现了基于业务合同自动完成付款的相关操作，比如实现自动验证收到的业务发票、开票抄税、存储所有付款记录等。实施本申请实施例，通过付款流程管理的自动化以及对付款相关信息的管理和存储，简化了付款审核的流程，节约了时间和人力成本，避免账目管理混乱、单据遗漏、审核失误等问题，处理周期稳定，有效地管理付款审核流程，减少出现工作失误。

本申请实施例提供了一种付款管理设备40，请参见图4，图4是本申请实施例提供的一种付款管理设备的结构示意图，如图4所示，一种付款管理装置能以图4的结构实现，付款管理设备40可以包括至少一个存储部件401、至少一个通信部件402、至少一个处理部件403。此外，该设备还可以包括天线、电源等故障分析部件，在此不再详述。

存储部件401可以包括一个或多个存储单元，每个单元可以包括一个或多个存储器，存储部件可用于存储程序和各种数据，并能在设备运行过程中高速、自动地完成程序或数据的存取。可以采用具有两种稳定状态的物理器件来存储信息，所述两种稳定状态分别表示为“0”和“1”。前述存储部件401，可以是只读存储器(read-onlymemory，rom)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(randomaccessmemory，ram)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electricallyerasableprogrammableread-onlymemory，eeprom)、只读光盘(compactdiscread-onlymemory，cd-rom)或其他光盘存储、光碟存储(可以包括压缩光碟、激光碟、光碟、数字故障分析光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过总线与处理器相连接。存储器也可以和处理器集成在一起。

通信部件402，也可以称为收发机，或收发器等，可以是用于与其他设备或通信网络通信，其中可以包括用来进行无线、有线或其他通信方式的单元。

处理部件403，处理部件也可以称为处理器，处理单元，处理单板，处理模块、处理装置等。处理部件可以是中央处理器(centralprocessingunit，cpu)，网络处理器(networkprocessor，np)或者cpu和np的组合，也可以是微处理器，特定应用集成电路(application-specificintegratedcircuit，asic)，或一个或多个用于控制以上方案程序执行的集成电路。

当付款管理设备40为图1所述付款设备时，所述处理部件403用于调用所述存储部件401的数据执行上述图2所述方法的相关描述如下：获取请款申请单和请款请求；根据所述请款申请单审核所述请款请求，所述请款请求包括业务发票和目标业务完成情况；在所述请款请求通过审核之后，向所述请款单位付款。

在本申请中，所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本申请实施例方案的目的。

另外，在本申请各个实施例中的各功能组件可以集成在一个组件也可以是各个组件单独物理存在，也可以是两个或两个以上组件集成在一个组件中。上述集成的组件既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的组件如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

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

应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。尽管在此结合各实施例对本申请进行了描述，然而，在实施例所要求保护的本申请过程中，本领域技术人员可理解并实现公开实施例的其他变化。