多账本、多账户、多业务规则下的收款单据自动生成方法

技术领域

本发明涉及数据处理技术领域，尤其是涉及一种多账本、多账户、多业务规则下的收款单据自动生成方法。

背景技术

对于大型企业来说，企业内部有多家属地公司，并且每个属地公司又有自己定制的业务规则；在生成收款单据处理方面，因每家属地公司的收款来源渠道比较多(银联支付、中金支付、快钱支付、付通、支付宝、微信、融资、国际跨境交易等等)，支付方式比较多(网银转账、第三方支付、融资支付、银票支付、商票支付、通宝支付等等)，账户类型(收入户、支出户、基本户、资金平台等等)比较多，账户种类(建行户、工行户、农行户、交行、中行、浙商银行、宁波银行等等)比较多；要想将每一笔收款项根据其不同收款来源渠道以及不同的业务规则，生成既能与上游业务类型相对应、又能与下游集团挂账科目相匹配的收款单据是一个非常繁琐的过程；因为在生成收款单据时，单据上的一些影响记账的科目因素以及一些辅助核算项是最终入账生成凭证的基础，只要某个科目因素错了或者辅助核算项漏了就会生成错误的记账凭证，导致会计口的出入账不平，从而需要耗时大量会计人员、财务人员、业务人员对收款单据重新审核对账直到借贷相等；因此在生成收款单据的整个过程中需要靠业务人员、财务人员根据账户上每笔流水上的一些特殊标志信息去仔细判断、归类、审核后，才能生成相应业务类型的收款单据；然而每个属地公司的业务场景又有所差异，从而会导致在整个收款单据生成过程中异常繁锁复杂，不但耗时了大量的人力资源而且还容易出错。因此亟需一种能够针对不同账本、不同账户、不同业务规则下实现上可与银企直联、下可与业务系统做对接，只需业务人员、财务人员略加少许人工干预，就能快速完成公司内部多账本、多账户、多业务规则下的自动生成收款单据的整个流程。

发明内容

本发明的目的就是为了提供一种快速准确生成收款单据的多账本、多账户、多业务规则下的收款单据自动生成方法。

本发明的目的可以通过以下技术方案来实现：

一种多账本、多账户、多业务规则下的收款单据自动生成方法，包括以下步骤：

根据定时任务处理机制，获取多个不同的账本信息；

基于所述多个不同的账本信息，获取对应的多个账户收款信息；

根据统一接口入参要求对所述多个账户收款信息分别进行封装处理，向统一接口发出加密请求；

所述统一接口接收封装后的多个账户收款信息，进行加密处理；

对加密后的多个账户收款信息进行验证，若验证不通过，则返回相应的提示信息，若验证通过，则向银企直联系统发出交互请求；

获取经银企直联系统处理过的多个账户收款信息生成收款流水信息，并匹配对应的多个业务规则，生成对应的收款单据，其中，所述银企直联系统的处理步骤包括对接收加密后的多个账户收款信息进行解密、解析和清洗处理。

进一步地，所述账户收款信息通过业务人员进行配置，所述账户收款信息包括账户性质、账户的分类、账户的系统别、账户直联属性、是否自动记账、是否下发属地系统和是否获取余额信息。

进一步地，所述加密处理采用数字签名的方式进行。

进一步地，在生成所述收款单据前，根据收款流水信息中的唯一关键字判断是否已生成过收款单据，若是，则不再生成对应的收款单据，若否，则生成收款单据。

进一步地，所述收款单据包括流水类型、支付类型、用途、下发状态、业务类型和凭证分类。

进一步地，所述收款单据划分为两大类，分别为主营类和非主营类，其中，划分原则为：若流水类型是预收的且支付类型为通过设定的接口支付的，则将所述收款单据划分为主营类，否则将所述收款单据划分为非主营类。

进一步地，所述下发状态包括未处理、取消、下发成功和下发失败。

进一步地，还包括根据所述收款单据的下发状态判断是否需要将所述收款单据下发到属地系统，具体步骤为：

判断所述收款单据的下发状态是否为未处理，若是，则将收款单据下发到属地系统，并更新下发状态，若否，则不进行下发。

进一步地，所述业务类型包括商品交易、代收业务、服务业务、资金业务、税收业务、退款、保证金和待处理。

进一步地，所述业务规则包括收款方式、收款渠道、凭证类型、凭证分类、会员规则和收款用途。

与现有技术相比，本发明具有以下有益效果：

(1)本发明根据不同账本信息和不同账户收款信息，直接与银企直联系统进行交互，获得所需要的收款流水信息，再经过与多种规则进行匹配，这种自动化生成方式，实现了收款单据快速准确的生成。

(2)本发明通过自动匹配等方式实现，收款单据的生成过程人工参与度小，生成过程简单，减少了人力资源，减低了出错概率。

附图说明

图1为本发明的方法流程示意图。

具体实施方式

下面结合附图和具体实施例对本发明进行详细说明。本实施例以本发明技术方案为前提进行实施，给出了详细的实施方式和具体的操作过程，但本发明的保护范围不限于下述的实施例。

本实施例提供一种多账本、多账户、多业务规则下的收款单据自动生成方法，该方法基于开发的一款基于银企直联能按不同账本、不同账户、不同业务规则自动生成既能满足上游业务规则又能精确匹配下游科目凭证的收款单据的中间件实现。通过使用该中间件，可将企业内部不同账本，不同账户下的不同渠道的收款信息按既定的业务规则自动生成符合入账科目的多种类型收款单据的整个流程。

如图1所示，该收款单据自动生成方法的具体步骤如下：

S1、根据定时任务处理机制，获取多个不同的账本信息。

本实施例中使用开发工具Intellij Idea 2019，jdk1.8，tomcat 8.5创建自动收款抛账中间件，命名为ar_auto_document，并配置相关的启动、构建、剖署等所需的环境变量以及配置文件。

构建项目架构分层结构，根据该中件间功能的整体设计以及微服务相关技术标准等，将整个设计结构分别拆分为ar_auto_document-jk、ar_auto_document-service、ar_auto_document-api等三个相互独立的模块；其中将ar_auto_document-jk、ar_auto_document-service构建为两个独立的微服务模块，将ar_auto_document-api构建为微服务模块间的Api。模块ar_auto_document-jk主要用于与外部系统进行通讯的出入口，主要定义一些对外部发送请求、接收外部请求的相关接口以及数据加签、签名验证等一些核心工具类；模块ar_auto_document-service主要对外部系统流入或流出的数据的进行业务逻辑处理的核心层；模块ar_auto_document-api主要定义用于衔接两个微服务模块间相互通讯时Api的相关信息，主要包含接口Api的定义、用于数据传输的载体bean定义以及一些常用的核心工具类UtilClass。

引入微服务框架Dubble，zk等以及一些相关配置文件，通过使用微服务框架Dubble，zk与Springboot容器等相关框架的紧密结合，保证了各微服务模块间既独立又能够相互调度、相互协调、相互通讯，高效地完成每一项作业。这样在系统架构的整个设计上，对于每个微服模块而言，既能够独立解偶，又能够高效协调地配合完成整个业务功能的逻辑处理，从而极大提高了的系统的高负荷、高效率、高稳定性、高扩展性。

创建微服务模块ar_auto_document-service，并添加相关的配置文件以及一些必要的工具包依赖POM配置文件等；该模块主要用于建设业务逻辑处理的实现部分，按部署环境分别创建三个应用配置文件application-dev、application-test、application-run；按微服务框架Dubble要求标准，分别创建接口服务的提供者配置文件provider.xml以及接口服务的消费者配置文件consumer.xml；按项目容器框架Springboot、微服务框架Dubble等的搭建标准要求，分别创建微服务的注册中心zk以及微服务暴露的端口等相关的配置文件applicationContext.xml以及微服务引入底程基础框架xplat的相关配置文件applicationContext-xeye.xml。

创建微服务模块ar_auto_document-jk，并添加相关的配置文件以及一些必要的工具包依赖POM配置文件等，引入并创建与财务公司以及与银行对接所必要的一些核心Jar包以及Core工具类，主要包括使用Webservice交互的客户端核心类SettleDCService、SettleDC、SettleDCProxy、SettleDCServiceLocator、SettleDCSoapBindingStub等；用于数字签名的工具类Keystore、SignDea、SignValidateFilte等；使用HTTP协议模式对外请求服务的工具类HttpClientPoolUtil、HttpClientPoolHolder、HttpConfigure、HttpAttributes等。

创建微服务模块ar_auto_document-api，该模块主要用于建设各个微服务间交互通信的接口Api的定义，主要包括接口服务的定义、接口服务中数据传输载体实体bean的定义、接口服务中的各种异常信息的自定义以及一些通用的常用工具类等。当某个微服务模块要调用其它微服务的某个接口时，只需引入并配置该模块依的赖包即可调用其已定义的接口Api。

通过上述设置的中间件主要模块，可实现各个模块以及与外界系统的通信交互等功能。为根据定时任务处理机制，获取多个不同的账本信息，在中间件的开发过程中，编写自动获取收款信息的定时工具类IJobHandler，通过使用IJobHandler的定时调度来获取不同账本的收款信息；并且可根据业务需求场景对不同账本收款信息的实时性要求，可以对不同账本的定时配置不同的调度频率，为数据的自动获取提供了便利。

定时任务处理机制是一种自动化执行任务的方式，通过设定定时规则和任务执行逻辑，可以定期或按照一定的时间间隔执行特定的任务。本实施例中采用定时任务处理机制用于定期获取多个不同账本的信息。

S2、基于所述多个不同的账本信息，获取对应的多个账户收款信息。

为支持多线程作业，编写可支持多线程请求服务的Http工具类HttpClientPoolHolder，该工具类可支持请求服务按多线程进行作业；当开启多线程作业模式时，Http请求服务被线程池管理；通过灵活设置线程池的最大连接数以及连接的生命周期，可减少Http请求服务时创建连接的耗时性，从而可以大大提高在高并发情况下服务请求效率。

账户收款信息是可以通过财务人员对不同账本下的不同账户进行灵活配置的，主要通过编写账户配置类GlBankAccountExecuteService实现对账户的相关信息进行配置，如账户性质、账户的分类、账户的系统别、账户直联属性、是否自动记账、是否下发属去公司、是否获取余额信息等等。通过对账户各个属性的灵活配置，为后续生成收款单以及抛账单逻辑提供了便利。

进一步编写接收步定时任务调度的实现类ARDCPaySchedule，使用策略设计模式根据入参中的账本信息，分别进入各自账本的处理逻辑中，保证各账本的处理逻辑互不影响；然后根据账本信息获取已配置好的并且满足相关收款条件的账户信息。

S3、根据统一接口入参要求对所述多个账户收款信息分别进行封装处理，向统一接口发出加密请求。

针对该步骤，中间件编写了获取某个账户收款信息的逻辑处理类DCPayQueryService，根据获取到满足条件的账户收款信息后，遍历每个账户并按统一接口的入参要求进行参数封装处理，然后通过统一接口向前置机发起请求，待前置机收到请求后对相关参数进行验证，验证通过后向对方系统发起交互通讯；否则返回相应提示信息。其中，统一接口的入参要求指的是该接口对请求的参数有一定的规范和要求。这些要求包括参数的格式、数据类型、长度限制、加密要求等。根据这些要求，对多个账户的收款信息进行封装处理，确保生成的请求参数符合统一接口的要求。

上述前置机的环境部署为将对接银企方所提供的前置机应用程序部署在相应的前置机服务器上；并对前置机的相关配置进行调优处理，确保前置机运行环境能够高效、稳定的完成作业的调度任务；其次配置相关日志文件，用于记录应用系统与前置机交互的出入信息，为日后问题跟踪提供便利条件；通过使用前置机可以确保双方系统在进行相互通讯时，数据的安全性、可靠性、防止被篡改的风险。

编写ar_auto_document-jk模块中与前置机进行交互的统一出入口工具类DCPayService、CZBANKOpenApiUtils，通过这些工具类将ar_auto_document-jk中的相关核心类库SettleDCServiceLocator、SettleDCService等进行封装处理，组装成统一对外交互的工具类。使用统一接口对外处理便于系统日后的可扩展性、可维护性。

S4、所述统一接口接收封装后的多个账户收款信息，进行加密处理。

本实例中通过数字签名的方式进行加密处理，中间件需要编写ar_auto_document-jk模块中数字签名的工具类Keystore、SignDeal、SignValidateFilte等，为了保障数据在传输过程中不被截留，篡改等风险，在双方进行交互时使用数字签名的方式进行通讯，通过数字签名工具类将传输的数据截取部分并按双方事先约定的加密方式进行数字签名，并将已签名的数据一并发送给对方；对方拿到数据后首先使用签名中的公钥对加密数据解密，解密后摘取其中的部分数据按相同的方式加签处理并与传过来的签名数据进行对比，从而可以确保交互双方的真实身份，同时确保了数据的完整性，避免被篡改的风险。

S5、对加密后的多个账户收款信息进行验证，若验证不通过，则返回相应的提示信息，若验证通过，则向银企直联系统发出交互请求。

本实例中通过前置机对加密后的多个账户收款信息进行验证，验证过程主要通过步骤3中的DCPayQueryService实现。

S6、获取经银企直联系统处理过的多个账户收款信息生成收款流水信息，并匹配对应的多个业务规则，生成对应的收款单据，其中，所述银企直联系统的处理步骤包括对接收加密后的多个账户收款信息进行解密、解析和清洗处理。

本步骤实现主要依赖中间件编写类DCPayQueryService中数据的解析逻辑，拿到接口返回的结果集后，因双方系统字段命名不一致，所以需对返回的结果集进行解析转换，并将转换后结果集进行重新组装到一个集合中。紧接着对新集合中的数据进行过滤处理，如果是已经被获取过并生成流水记录的则剔除掉，否则会导致多收款或少收款从而会影响后面客户资金账处理流程。

编写获取会员信息处理类QueryObspCompany，由于企业内部一个会员会存在多个T代码，所以针对会员信息的获取需按如下规则：获取上述中已清洗后的收款信息后，首先根据付款方名称调用会员中心接口获取该付款方的会员信息。根据接口返回的会员信息进行如下处理：如果返回的结果集是一条则直接取用其中的T代码，如果有多条则按如下规则选取：判断多条会员信息中拥有G代码的有几条，如果只有一条则取有G代码的那条记录中对应的T代码；如果拥有G代码的仍有多条，则需判断审核状态，如果审核通过的只有一条则取审核通过那条的T代码，否则按该付款方在平台的会员信息有误处理返回空值。

经过银企直联系统的处理，需要生成收款流水信息，中间件中编写生成收款流水类DCPayStream中生成流水的逻辑，拿到已清理后的收款流水信息后，根据流水中的唯一关键字判断该流水是否已落地并生成过收款单，如果是则直接返回；否则根据付方信息、附言信息、摘要信息等获取已配置好的流水类型以及支付方式并落地生成收款流水。

接着生成收款单据，中间件通过编写以下类实现：

编写收款单据类DCPayExecuteService中判断收款信息的流水类型逻辑，拿到填充付款方T代码的收款信息后，根据各公司的业务场景将收款流水类型归为两大类：主营业务和非主营业务，其中主营业务主要包括预收类型，非主营业务主要包括资金业务(同户名划转、资金结息、付通提现充值等等)、资金上收、资金下拨等类型。

编写收款单据类DCPayExecuteService中判断收款信息的支付类型逻辑，拿到预处理好的收款流水信息后，根据收款流水的付款方名称、用途、附言等信息，将支付类型分为：财务公司接口支付、付通支付、微信支付，支付宝支付、融资支付，浙商接口支付、宁波银行支付等类型。

编写收款单据类DCPayExecuteService中收款单据的生成逻辑，为了在记账处理过程中更加灵活可控，根据流水类型和支付类型等，将收款单据划分为两大类：一类为主营类的收款单，另一类为非主营的收款单。如果流水类型是预收并且支付类型为财务公司接口支付的，则将收款流水按主营收款单处理，否则按非主营收款单处理；根据收款单类型分别对收款用途、状态、业务类型、下发状态等进行不同的逻辑处理。

编写收款单据类DCPayExecuteService中收款单用途的逻辑，拿到预处理过的收款单信息，根据流水类型、付款方信息、附言、摘要等信息将收款单用途划分为：异议退款、电子证书费用、资金上收、资金下拨、商品交易等等，是后续抛账单据中业务类型以及摘要信息的主要来源。

编写收款单据类DCPayExecuteService中收款单状态的逻辑，拿到预处理过的收款单信息，根据流水类型、收款用途、附言、摘要等信息将收款单状态划分为：新增、确认、冻结等三个状态。其中新增状态后面需财务相关人员进行手动确认，否则该类收款单不会自动生成抛账单据，并且也不会下发给属地公司系统；冻结状态的收款单据需财务人员手工做账后直接反写会计凭证号，因为此类收款单据为特殊业务的收款；只有确认状态下的收款单才会自动生成抛账单据并且自动下发给对应的属地系统。

编写收款单据类DCPayExecuteService中收款单业务类型的逻辑，拿到预处理过的收款单信息，根据收款用途、账本、付方相关信息、收方账户类型、流水类型、支付类型等等，将收款单的业务类型划分为：商品交易、代收业务、服务业务、资金业务、税收业务、退款、保证金、待处理等等。其中待处理业务需财务相关人员进行确认后处理，否则该业务类型的收款单据不会自动生成抛账单据。

编写收款单据的凭证分类以及制单人员的配置类RuleOrMarkerService，通过凭证类型以及制单人员的配置规则，首先给每个账本下配置一个默认的凭证分类，其次根据单据类型、业务类型、凭证类型配置其对应的凭证分类，在生成收款单据时根据匹配规则获取相对应的凭证类型及制单人信息，如果匹配不到则取本账本下对应的默认的凭证分类。

编写生成收款单据凭证类型的配置类VoucherExecuteService，根据收款单据中收方账户上配置的账户类型以及业务类型，根据凭证类型匹配规则自动获取收款单据上的凭证类型，如果匹配不到则取本账本下、本账户下配置的默认凭证类型。

此外，本实施例获得的收款单据可下发到属地公司系统。中间件编写收款单据类DCPayExecuteService中收款单下发属地公司状态的逻辑，根据收款单类型、流水类型、支付类型、用途等信息判断该收款单信息是否需要下发属地公司。将收款单下发状态划分为：未处理、取消、下发成功、下发失败等状态，只有未处理状态的收款单才能下发属地公司，下发后状态更新为下发成功。还编写编写收款单据下发属地公司的类ArToCollectionsService，根据收款单据中收方账户上配置的是否下发标记以及收款单据的是否下发标记判断该收款单是否具备下发属地公司的条件；如果满足下发条件则根据系统对属地公司相关接口的配置信息，获取到对应的接口后将收款单相关信息封装并下发业务系统；同时更新收款单下发状态为发送中，如果下发成功则回写收款单下发状态为下发成功；否则为下发失败，然后由运维人员对失败原因进行分析后确认是否重新下发。

以上步骤通过中间件实现了多账本、多账户、多业务规则下的收款单据自动生成方法。

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

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。本发明实施例中的方案可以采用各种计算机语言实现，例如，面向对象的程序设计语言Java和直译式脚本语言JavaScript等。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。