CN114077604A - 业务凭证的生成方法、装置、服务器及存储介质 - Google Patents

业务凭证的生成方法、装置、服务器及存储介质 Download PDF

Info

Publication number
CN114077604A
CN114077604A CN202010811442.XA CN202010811442A CN114077604A CN 114077604 A CN114077604 A CN 114077604A CN 202010811442 A CN202010811442 A CN 202010811442A CN 114077604 A CN114077604 A CN 114077604A
Authority
CN
China
Prior art keywords
data
transaction data
service
transaction
target
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202010811442.XA
Other languages
English (en)
Inventor
何东明
唐勇
洪亮
唐文波
郭荣发
李永德
李活甫
赵培源
付金鑫
张燕群
张爱花
卢秋霞
张仲全
陈真
刘大梁
邓淑瑛
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SF Technology Co Ltd
Original Assignee
SF Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by SF Technology Co Ltd filed Critical SF Technology Co Ltd
Priority to CN202010811442.XA priority Critical patent/CN114077604A/zh
Publication of CN114077604A publication Critical patent/CN114077604A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23Updating
    • G06F16/2358Change logging, detection, and notification
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28Databases characterised by their database models, e.g. relational or object models
    • G06F16/284Relational databases
    • G06F16/285Clustering or classification
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Software Systems (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • General Business, Economics & Management (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本申请提供一种业务凭证的生成方法、装置、计算机设备及存储介质。该方法包括:获取目标业务的业务凭证生成请求;响应请求,获取目标业务的前置交易数据和目标业务的数据分类策略信息;基于数据分类策略信息对前置交易数据进行分类,得到多种类型交易数据;根据预设的凭证保存策略信息,分别对多种类型交易数据进行保存处理,得到目标业务的一个或多个业务凭证。本申请根据预设的数据分类策略对大批量业务凭证的前置交易数据进行分类,然后对分类后的多种类型交易数据同时进行保存得到业务凭证,能够支持对大数据量下的高并发处理。

Description

业务凭证的生成方法、装置、服务器及存储介质
技术领域
本申请涉及网络技术领域,具体涉及一种业务凭证的生成方法、装置、服务器及存储介质。
背景技术
快递、电商等新经济蓬勃发展,新经济下企业管理对财务核算的精细化程度要求越来越高,新经济下企业的客户数量大、种类多,业务订单和运单也是巨量,每月每日甚至每秒都有巨大量的凭证需要记账到系统;但目前业界企业资源计划系统和财务软件因各种原因不支持对大数据量下的高并发处理,在使用过程中,给公司管理带来很大困扰:
现有的业务凭证的生成方法不支持对大数据量下的高并发处理。
发明内容
基于此,有必要针对现有的技术问题,提供一种业务凭证的生成方法、装置、服务器及存储介质,解决现有业务凭证的生成方法不支持对大数据量下的高并发处理的问题。
一方面,本申请提供一种业务凭证的生成方法,所述业务凭证的生成方法包括:
获取目标业务的业务凭证生成请求;
响应所述请求,获取目标业务的前置交易数据和所述目标业务的数据分类策略信息;
基于所述数据分类策略信息对所述前置交易数据进行分类,得到所述多种类型交易数据;
根据预设的凭证保存策略信息,分别对所述多种类型交易数据进行保存处理,得到所述目标业务的一个或多个业务凭证。
其中,所述凭证保存策略信息中包括多种类型交易数据的凭证保存策略信息,所述根据预设的凭证保存策略信息,分别对所述多种类型交易数据进行保存处理,得到所述目标业务的一个或多个业务凭证,包括:
基于预设的数据补充策略分别对每种类型交易数据进行补充,得到多种类型补充数据;
基于所述凭证保存策略信息,确定每种类型交易数据的凭证保存策略信息;
基于所述每种类型交易数据的凭证保存策略信息,对对应的每种类型补充数据进行保存处理,生成所述一个或多个业务凭证。
其中,所述基于预设的数据补充策略分别对每种类型交易数据进行补充,得到多种类型补充数据,包括:
分别以所述多种类型交易数据中每种类型交易数据为目标类型交易数据,判断所述目标类型交易数据是否被锁定;
若所述目标类型交易数据未被锁定,基于预设的数据补充策略对所述目标类型交易数据进行补充,得到所述目标类型补充数据。
其中,所述基于所述每种类型交易数据的凭证保存策略信息,对对应的每种类型补充数据进行保存处理,生成所述一个或多个业务凭证,包括:
对所述目标类型补充数据进行数据切分,得到所述目标类型补充数据对应的一个或多个分块交易数据;
当所述目标类型补充数据对应的分块交易数据的数量为多个时,基于所述目标类型补充数据对应的凭证保存策略对所述目标类型补充数据对应的多个分块交易数据进行保存处理,生成一个或多个目标类型凭证。
其中,所述基于所述目标类型补充数据对应的凭证保存策略对所述目标类型补充数据对应的多个分块交易数据进行保存处理,生成一个或多个目标类型凭证,包括:
获取所述目标类型补充数据中所述多个分块交易数据的保存状态信息;
基于所述保存状态信息判断所述目标类型补充数据中所述多个分块交易数据是否全部保存成功;
若所述目标类型补充数据中所述多个分块交易数据全部保存成功,则生成所述一个或多个目标类型凭证,并更新所述目标类型补充数据的交易状态。
其中,在所述获取所述目标类型补充数据中所述多个分块交易数据的保存状态信息之前,所述生成方法还包括:
获取所述目标类型补充数据的交易识别标识;
将所述目标类型补充数据的交易识别标识抛入分布式发布订阅消息系统;
对分布式发布订阅消息系统消费的交易识别标识对应的多个分块交易数据进行保存处理。
其中,所述生成方法还包括:
若所述目标类型补充数据中所述多个分块交易数据未全部保存成功,则判断所述目标类型补充数据的保存出错次数是否超过预设值;
若所述保存出错次数未超过预设值,则将所述目标类型补充数据的交易识别标识抛入分布式发布订阅消息系统。
另一方面,本申请提供一种业务凭证的生成装置,所述生成装置包括:
第一获取单元,用于获取目标业务的业务凭证生成请求;
第二获取单元,用于响应所述请求,获取目标业务的前置交易数据和所述目标业务的数据分类策略信息;
分类单元,用于基于所述数据分类策略信息对所述前置交易数据进行分类,得到所述多种类型交易数据;
保存单元,用于根据预设的凭证保存策略信息,分别对所述多种类型交易数据进行保存处理,得到所述目标业务的一个或多个业务凭证。
其中,所述凭证保存策略信息中包括多种类型交易数据的凭证保存策略信息,所述保存单元,还用于基于预设的数据补充策略分别对每种类型交易数据进行补充,得到多种类型补充数据;
基于所述凭证保存策略信息,确定每种类型交易数据的凭证保存策略信息;
基于所述每种类型交易数据的凭证保存策略信息,对对应的每种类型补充数据进行保存处理,生成所述一个或多个业务凭证。
其中,所述保存单元,还用于分别以所述多种类型交易数据中每种类型交易数据为目标类型交易数据,判断所述目标类型交易数据是否被锁定;
若所述目标类型交易数据未被锁定,基于预设的数据补充策略对所述目标类型交易数据进行补充,得到所述目标类型补充数据。
其中,所述保存单元,还用于对所述目标类型补充数据进行数据切分,得到所述目标类型补充数据对应的多个分块交易数据;
当所述目标类型补充数据对应的分块交易数据的数量为多个时,基于所述目标类型补充数据对应的凭证保存策略对所述目标类型补充数据对应的多个分块交易数据进行保存处理,生成一个或多个目标类型凭证。
其中,所述保存单元,还用于获取所述目标类型补充数据中所述多个分块交易数据的保存状态信息;
基于所述保存状态信息判断所述目标类型补充数据中所述多个分块交易数据是否全部保存成功;
若所述目标类型补充数据中所述多个分块交易数据全部保存成功,则生成所述一个或多个目标类型凭证,并更新所述目标类型补充数据的交易状态。
其中,所述保存单元,还用于获取所述目标类型补充数据的交易识别标识;
将所述目标类型补充数据的交易识别标识抛入分布式发布订阅消息系统;
对分布式发布订阅消息系统消费的交易识别标识对应的多个分块交易数据进行保存处理。
其中,所述保存单元,还用于若所述目标类型补充数据中所述多个分块交易数据未全部保存成功,则判断所述目标类型补充数据的保存出错次数是否超过预设值;
若所述保存出错次数未超过预设值,则将所述目标类型补充数据的交易识别标识抛入分布式发布订阅消息系统。
又一方面,本申请还提供一种服务器,所述服务器包括:
一个或多个处理器;
存储器;以及
一个或多个应用程序,其中所述一个或多个应用程序被存储于所述存储器中,并配置为由所述处理器执行以实现所述的业务凭证的生成方法。
再一方面,本申请还提供一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器进行加载,以执行所述的业务凭证的生成方法中的步骤。
本申请根据预设的数据分类策略对大批量业务凭证的前置交易数据进行分类,然后对分类后的多种类型交易数据同时进行保存得到业务凭证,能够支持对大数据量下的高并发处理。
附图说明
为了更清楚地说明本申请实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的业务凭证的生成方法的场景示意图;
图2是本申请实施例中提供的业务凭证的生成方法的一个实施例流程示意图;
图3是本申请实施例中提供的业务凭证的生成方法中S204一个实施例流程示意图;
图4是本申请实施例中提供的业务凭证的生成方法中S303一个实施例流程示意图;
图5是本申请实施例中提供的业务凭证的生成方法中S402一个实施例流程示意图;
图6是本申请实施例中提供的业务凭证的生成装置一个实施例结构示意图;
图7是本申请实施例中提供的服务器的一个实施例结构示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
在本申请的描述中,需要理解的是,术语“中心”、“纵向”、“横向”、“长度”、“宽度”、“厚度”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系,仅是为了便于描述本申请和简化描述,而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作,因此不能理解为对本申请的限制。此外,术语“第一”、“第二”仅用于描述目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个特征。在本申请的描述中,“多个”的含义是两个或两个以上,除非另有明确具体的限定。
在本申请中,“示例性”一词用来表示“用作例子、例证或说明”。本申请中被描述为“示例性”的任何实施例不一定被解释为比其它实施例更优选或更具优势。为了使本领域任何技术人员能够实现和使用本申请,给出了以下描述。在以下描述中,为了解释的目的而列出了细节。应当明白的是,本领域普通技术人员可以认识到,在不使用这些特定细节的情况下也可以实现本申请。在其它实例中,不会对公知的结构和过程进行详细阐述,以避免不必要的细节使本申请的描述变得晦涩。因此,本申请并非旨在限于所示的实施例,而是与符合本申请所公开的原理和特征的最广范围相一致。
本申请实施例提供一种业务凭证的生成方法、装置、服务器及存储介质,以下分别进行详细说明。
参阅图1,图1是本申请实施例提供的业务凭证的生成方法的场景示意图,该业务凭证的生成方法可应用于业务凭证的生成系统中。其中,业务凭证的生成系统包括用户终端102和服务器104,用户终端102具体可以是台式终端或移动终端,移动终端具体可以手机、平板电脑、笔记本电脑等中的至少一种;服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现;用户终端102与服务器104之间可通过广域网、城域网或局域网等网络建立通信连接。
如图2所示,在一个实施例中,本申请提供了一种业务凭证的生成方法。本实施例主要以该方法应用于上述图1中的服务器104来举例说明。参照图2,该业务凭证的生成方法具体包括如下步骤:
S201、获取目标业务的业务凭证生成请求。
本申请实施例中,用户可以通过用户终端102发送业务凭证生成请求,服务器104获取目标业务的业务凭证生成请求。可以是一个用户通过用户终端102发送业务凭证生成请求,也可以是多个用户通过各自的用户终端102同时向服务发送业务凭证生成请求。服务器104获取一个或多个用户发送的业务凭证生成请求。
S202、响应请求,获取目标业务的前置交易数据和目标业务的数据分类策略信息。
每笔记账都一直以凭证形式存储,每一凭证都作为前后一致的单位保留在系统中,直至将它归档。每张凭证都有一个凭证抬头和两个以上的行项目组成。凭证抬头指对整个凭证有效的信息,例如四个日期、文本摘要、凭证类型等等。行项目仅仅包含特定项目的信息,如记账码、科目编码、金额、税码、成本对象等有科目、记账码等配置综合决定的信息。
本申请实施例中,前置交易数据是凭证正式过账前的数据,也可称为前置凭证。前置交易数据包括前置凭证头信息、前置凭证往来明细行信息以及前置凭证总账行信息。例如,前置凭证头信息为《前置凭证头》表,前置凭证往来明细行信息为《前置凭证客户明细》表、前置凭证总账行信息为《前置凭证总账明细》表。业务凭证包括凭证头信息、凭证往来明细行信息以及凭证总账行信息。例如,凭证头信息为《凭证头》表,凭证往来明细行信息为《凭证客户明细》表、凭证总账行信息为《凭证总账明细》表。
例如,前置凭证头信息可以包括唯一ID、客户端、联合凭证编号、凭证日期、过账日期、冲销凭证编号、公司代码、系统来源、往来数据类型、被冲销凭证编号等。前置凭证往来明细行信息包括交易金额、本位币金额、集团货币金额等。前置凭证总账行信息包括交易金额、本位币金额、集团货币金额、成本中心以及起息日等。
服务器104响应请求,获取目标业务的前置交易数据和目标业务的数据分类策略信息。数据分类策略信息与目标业务对应,可根据目标业务的不同,选用不同的数据分类策略。
S203、基于数据分类策略信息对前置交易数据进行分类,得到多种类型交易数据。
本申请实施例中,根据数据分类策略信息将前置交易数据的凭证往来明细行信息分为以下七类交易数据:
(1)第一类型交易数据:新生成的往来项。第一类型交易数据指的是,在执行完确定清账项后,未与可清项建立核销关联的未清项或与可清项建立核销关系后金额过剩的部分,在提交下游时被重新归类,便于区别标识。
(2)第二类型交易数据:清账保留的往来项。第二类型交易数据指的是,在执行完确定清账项后,与未清项建立核销关系金额过剩的部分,在提交下游时被重新归类,便于区别标识。
(3)第三类型交易数据:将被完全清账的往来项。第三类型交易数据指的是,在执行完确定清账项后,与未清项建立了核销关系且金额一致的可清项,在提交下游时被重新归类,便于区别标识。
(4)第四类型交易数据:新生成将被清账的往来项。第四类型交易数据指的是,在执行完确定清账项后,与可清项建立了核销关系且金额一致的未清项,在提交下游时被重新归类,便于区别标识。
(5)第五类型交易数据:将被释放的已清项。第五类型交易数据指的是,在清账重置和清账冲销场景下,需将原清账凭证中的已清项恢复到未清状态,这类往来账目在提交下游过账时需单独归类,便于区别标识。
(6)第六类型交易数据:拆分出将被清账的往来项。第六类型交易数据指的是,在执行完确定清账项后,因金额比与之比较的未清项金额大,按可比较金额拆分出来的部分,在提交下游时被重新归类,便于区别标识。
(7)第七类型交易数据:拆分后被完全清账的往来项。第七类型交易数据指的是,在执行完确定清账项后,因金额比与之比较的未清项金额大,拆分后剩余的且与其他未清项完全清账的部分,在提交下游时被重新归类,便于区别标识。
S204、根据预设的凭证保存策略信息,分别对多种类型交易数据进行保存处理,得到目标业务的一个或多个业务凭证。
如图3所示,在一个实施例中,凭证保存策略信息中包括多种类型交易数据的凭证保存策略信息,根据预设的凭证保存策略信息,分别对多种类型交易数据进行保存处理,得到目标业务的一个或多个业务凭证,具体包括如下步骤:
S301、基于预设的数据补充策略分别对每种类型交易数据进行补充,得到多种类型补充数据。
本申请实施例中,分别以多种类型交易数据中每种类型交易数据为目标类型交易数据,判断目标类型交易数据是否被锁定,若目标类型交易数据未被锁定,基于预设的数据补充策略对目标类型交易数据进行补充,得到目标类型补充数据。
进一步的,在基于预设的数据补充策略对目标类型交易数据进行补充,得到目标类型补充数据后,将目标类型补充数据进行锁定。
可以同时以多种类型交易数据中每种类型交易数据为目标类型交易数据,判断目标类型交易数据是否被锁定。
具体的,基于预设的数据补充策略分别对每种类型交易数据进行补充,得到多种类型补充数据,包括:对前置交易数据分类后的多种类型交易数据进行一次财务特性的查漏补缺:
(1)增加纯财务属性核算要素的查漏补充,对成本要素类科目和银行存款类科目分别对【成本中心】和【起息日】的查漏补充;
(2)凭证结构完整性检查;
(3)《前置凭证头》表、《前置凭证客户明细》表、《前置凭证总账明细》表中,必填字段的检查和金额不能同时为0的检查,包括新生成凭证和被更新的历史凭证;
(4)《前置凭证头》表、《前置凭证客户明细》表、《前置凭证总账明细》表中,核算要素的一致性检查,包括新生成凭证和被更新的历史凭证;
(5)凭证项核算对象的规范性检查,即有值的才检查,为空的不做检查,包括新生成凭证和被更新的历史凭证;
(6)凭证金额借贷平衡检查,包括新生成凭证和被更新的历史凭证;
每次对同一批数据在同一层次做全量检查,即检查有异常的,将同一层次所有的问题以清单的形式全量反馈出来;
汇总《前置凭证客户明细》表中第一类型交易数据的条目、《前置凭证客户明细》表中第四类型交易数据的条目以及《前置凭证总账明细》表中所有条目数据的【交易金额】、【本位币金额】、【集团货币金额】汇总是否为0,并进行如下判断处理:
如果【交易金额】、【本位币金额】、【集团货币金额】三个汇总金额都等于0,则说明业务凭证平衡,返回对;
如果【交易金额】、【本位币金额】、【集团货币金额】三个汇总金额中有不等于0的,则说明业务凭证不平衡:返回错,同时提示错误消息:
如果交易货币下金额不平衡,提示错误消息E:H0012交易货币,XX1下借贷不平衡,差额为:XX2;
如果本位币下金额不平衡,提示错误消息E:H0013本位币,XX1下借贷不平衡,差额为:XX2;
如果集团货币下金额不平衡,提示错误消息E:H0014集团货币:XX1下借贷不平衡,差额为:XX2。
进一步的,基于预设的数据补充策略分别对每种类型交易数据进行补充,得到多种类型补充数据,还包括:
(1)生成对账代码。
具体的,调用预设的{Reconciliation Key对账代码}类中的方法<genReconciliationKey生成对账代码>,输入《前置凭证头》中的【公司代码】+【系统来源】+【数据类型】值组合,获取返回的对账代码。
(2)生成凭证编号
调用预设的{DocNumber凭证编号}类中的方法<genDocNumber生成凭证编号>,按【唯一ID】输出《前置凭证头》表中的【凭证类型】值,获取返回的凭证编号。
S302、基于凭证保存策略信息,确定每种类型交易数据的凭证保存策略信息。
S303、基于每种类型交易数据的凭证保存策略信息,对对应的每种类型补充数据进行保存处理,生成一个或多个业务凭证。
在一个具体的实施例中,基于每种类型交易数据的凭证保存策略信息,对对应的每种类型补充数据进行保存处理,生成一个或多个业务凭证,可以如下:
(2)提交和更新《凭证头》表
将《前置凭证头》表中的数据赋值到《凭证头》表,将新生成的凭证编号补充更新到《凭证头》中的【凭证编号】字段,将新生成的对账代码补充更新到《凭证头》中的【对账代码】字段;
同时,以下场景需特别处理:
当《凭证头》表中的【事务类型】=冲销时,将新生成的凭证编号补充更新到“被冲销凭证”的《凭证头》中的【冲销凭证编号】字段;
此处“被冲销凭证”即《前置凭证头》表中的【被冲销凭证编号】。
(3)提交和更新《凭证客户明细》表
3.1、根据第一类型交易数据的凭证保存策略信息提交第一类型交易数据。
将《前置凭证客户明细》表中的【往来数据类型】=(新生成的往来项)的数据赋值到《凭证客户明细》表,同时将上面提交和更新《凭证头》表中新生成的凭证编号补充更新到《凭证客户明细》表中的【凭证编号】字段;将新生成的对账代码补充更新到《凭证客户明细》中的【对账代码】字段。
3.2、根据第二类型交易数据的凭证保存策略信息更新第二类型交易数据。
在《凭证客户明细》表中找出与《前置凭证客户明细》表中【往来数据类型】=(清账保留的往来项)数据中的【凭证编号】+【项编号】+【子项编号】三个字段值一致的条目,并用《前置凭证客户明细》表中对应数据的本位币金额、交易金额和集团货币金额更新替换《凭证客户明细》表中对应数据的【本位币金额】、【交易金额】和【集团货币金额】字段值;
3.3、根据第三类型交易数据的凭证保存策略信息更新第三类型交易数据。
在《凭证客户明细》表中找出与《前置凭证客户明细》表中【往来数据类型】=(将被清账的往来项)数据中的【凭证编号】+【项编号】+【子项编号】三个字段值一致的条目,将上面提交和更新《凭证头》表中新生成凭证编号值写入《凭证客户明细》表中对应数据的【清账凭证编号】字段;
同时,用《前置凭证客户明细》表中该条目数据中的【清账凭证项编号】、【清账凭证子项编号】、【清账日期】、【清账记账日期】、【清账货币】、【清账金额】、【清账原因】字段替换《凭证客户明细》表中的对应字段;同时当被更新条目中【清账状态】为0或为空时,更新赋值已清。
3.4、根据第四类型交易数据的凭证保存策略信息提交第四类型交易数据。
将《前置凭证客户明细》表中的【往来数据类型】=(新生成将被清账的往来项)的数据赋值到《凭证客户明细》表:
并将上面新生成的凭证编号补充更新到《凭证客户明细》表中的【凭证编号】和【清账凭证编号】字段;将新生成的对账代码补充更新到《凭证客户明细》中的【对账代码】字段。
3.5、根据第五类型交易数据的凭证保存策略信息更新第五类型交易数据。
在《凭证客户明细》表中找出与《前置凭证客户明细》表中【往来数据类型】=(将被释放的已清项)数据中的【凭证编号】+【项编号】+【子项编号】三个字段值一致的条目,然后清空条目数据中的【清账日期】、【清账凭证编号】、【清账凭证项编号】、【清账凭证子项编号】、【清账记账日期】、【清账原因】、【清账货币】、【清账金额】;将【重置清账标识】字段更新赋值1;同时将【清账状态】更新赋值为0。
3.6、对于执行过以上步骤3.5的数据,需将原始未清项凭证、清账凭证和冲销清账凭证三者间登记历史清账关系:
先从步骤3.5的《前置凭证客户明细》表中【往来数据类型】=(将被释放的已清项)的数据中取出对应的【凭证编号】、【项编号】、【子项编号】、【清账凭证编号】、【清账凭证项编号】、【清账凭证子项编号】、【清账日期】、【清账原因】、【清账货币】、【清账金额】、【本币金额】、【交易金额】、【公司代码】、【交易货币】等信息,并在《清账历史关系表》中按对应字段登记一行数据;
再将步骤3.3中获取的新生成的【凭证编号】和【过账日期】补充更新到【清账历史关系表】中的【冲销凭证编号】和【冲销过账日期】字段。
3.7、根据第六类型交易数据的凭证保存策略信息提交第六类型交易数据。
将《前置凭证客户明细》表中的【往来数据类型】=(拆分出将被清账的往来项)的数据赋值到《凭证客户明细》表:
并则将上面第2步中新生成的凭证编号补充更新到《凭证客户明细》表中的【清账凭证编号】字段。
3.8、根据第七类型交易数据的凭证保存策略信息更新第七类型交易数据。
在《凭证客户明细》表中找出与《前置凭证客户明细》表中【往来数据类型】=(拆分后被完全清账的往来项)数据中的【凭证编号】+【项编号】+【子项编号】三个字段值一致的条目,将上面第2步中新生成的凭证编号值写入《凭证客户明细》表中对应数据的【清账凭证编号】字段;
同时,用《前置凭证客户明细》表中该条目数据中的【交易金额】、【本币金额】、【集团货币金额】、【清账凭证项编号】、【清账凭证子项编号】、【清账日期】、【清账记账日期】、【清账货币】、【清账金额】、【清账原因】字段替换《凭证客户明细》表中的对应字段;同时当被更新条目中【清账状态】为0或为空时,更新赋值已清。
说明:第三类型交易数据和第七类型交易数据的区别:
第三类型交易数据是在一次清账事务中整条未清项参与完整清账,没被拆分过的条目;第七类型交易数据是在一次清账事务中未清项被拆分过,但最后仍被完全清账时被拆分后的最后一个条目);
在更新时,第七类型交易数据在第三类型交易数据需要更新的数据上,还需更新【交易金额】、【本币金额】、【集团货币金额】。
(4)提交和更新《凭证总账明细》表。
将《前置凭证总账明细》表中的数据复制到《凭证总账明细》表,同时将上面提交和更新《凭证头》表中新生成的凭证编号补充更新到《凭证总账明细》中的【凭证编号】字段。
(5)补充新生成凭证的《凭证客户明细》和《凭证总账明细》表中的【对账代码】。
将新生成的对账代码补充到《凭证客户明细》中第一、第四类型交易数据的条目和《凭证总账明细》表中所有条目的【对账代码】字段。
(6)《凭证客户明细》和《凭证总账明细》表新增字段。
《凭证客户明细》和《凭证总账明细》表增加【参考凭证编号】字段,两个表的该字段赋值同《凭证头》表中的【参考凭证编号】字段的值。目的是为出具内部往来对账报表,避免跨表查询。
(7)《凭证头》、《凭证客户明细》和《凭证总账明细》三张表均增加【首次实际落地时间】字段,该字段为技术字段,记录条目首次实际写表的时间。
如图4所示,在一个实施例中,基于每种类型交易数据的凭证保存策略信息,对对应的每种类型补充数据进行保存处理,生成一个或多个业务凭证,具体包括如下步骤:
S401、对目标类型补充数据进行数据切分,得到目标类型补充数据对应的一个或多个分块交易数据。
数据切分是指通过某种特定的条件,将我们存放在同一个数据库中的数据分散存放到多个数据库上面。以达到分散单台设备负载的效果。
对目标类型补充数据进行数据切分后,可能得到一个分块交易数据,也可能得到多个分块交易数据。
本申请实施例中,基于客户属性信息对目标类型补充数据进行数据切分,得到目标类型补充数据对应的一个或多个分块交易数据。客户属性信息包括客户编码信息。
S402、当目标类型补充数据对应的分块交易数据的数量为多个时,基于目标类型补充数据对应的凭证保存策略对目标类型补充数据对应的多个分块交易数据进行保存处理,生成一个或多个目标类型凭证。
当目标类型补充数据对应的分块交易数据的数量为1个时,无需走分布式发布订阅消息系统,直接对这一分块交易数据进行保存处理。
当目标类型补充数据对应的分块交易数据的数量为多个时,需要走分布式发布订阅消息系统。基于目标类型补充数据对应的凭证保存策略对目标类型补充数据对应的多个分块交易数据进行保存处理,生成一个或多个目标类型凭证。
需要说明的是,一个目标类型凭证的数据可能存在于多个分块交易数据,并不是数据切分后有多个分块交易数据,就会生成多个目标类型凭证,有可能多个分块交易数据只属于一个目标类型凭证。因此,对多个分块交易数据进行保存处理时,生成的目标类型凭证的数量可能为1个也可能为多个。
例如业务生成请求的数据包中的前置凭证为两张,第一张前置凭证的客户明细行中有两行,客户属性信息(结算BP)分别为A和B,第二张前置凭证的客户明细行中也有两行,客户属性信息(结算BP)为B和C,以客户属性信息(结算BP)进行数据切分分块,此请求数据将会被切分为三个分块,这三个分块中的客户属性信息(结算BP)是A、B、C,但实际生成的目标类型凭证还是两张,第一张目标类型凭证的数据存在于A、B两个分块中,第二张目标类型凭证的数据存在于B、C两个分块中。
如图5所示,在一个实施例中,当目标类型补充数据对应的分块交易数据的数量为多个时,基于目标类型补充数据对应的凭证保存策略对目标类型补充数据对应的多个分块交易数据进行保存处理,生成一个或多个目标类型凭证,具体包括如下步骤:
S501、获取目标类型补充数据的交易识别标识。
具体的,交易识别标识为目标类型补充数据的交易ID。
S502、将目标类型补充数据的交易识别标识抛入分布式发布订阅消息系统。
具体的,分布式发布订阅消息系统为Kafka,Kafka是由Apache软件基金会开发的一个开源流处理平台,由Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统,它可以处理消费者在网站中的所有动作流数据。这种动作是在现代网络上的许多社会功能的一个关键因素。这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。对于像Hadoop一样的日志数据和离线分析系统,但又要求实时处理的限制,这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理,也是为了通过集群来提供实时的消息。
其中,将交易识别标识存储至关系型数据库管理系统,例如,关系型数据库管理系统为MySQL。MySQL是一种开放源代码的关系型数据库管理系统,使用最常用的数据库管理语言--结构化查询语言(SQL)进行数据库管理。MySQL是开放源代码的,因此任何人都可以在General Public License的许可下下载并根据个性化的需要对其进行修改。MySQL因为其速度、可靠性和适应性而备受关注。大多数人都认为在不需要事务化处理的情况下,MySQL是管理内容最好的选择。
将交易识别标识对应的多个分块交易数据存储至分布式的、面向列的开源数据库。例如,分布式的、面向列的开源数据库为Hbase。HBase是一个分布式的、面向列的开源数据库,该技术来源于Fay Chang所撰写的Google论文“Bigtable:一个结构化数据的分布式存储系统”。就像Bigtable利用了Google文件系统(File System)所提供的分布式数据存储一样,HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache的Hadoop项目的子项目。HBase不同于一般的关系数据库,它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。
具体的,判断将交易识别标识存储至关系型数据库管理系统的步骤和将交易识别标识对应的多个分块交易数据存储至分布式的、面向列的开源数据库的步骤是否全部成功,若是,则将目标类型补充数据的交易识别标识抛入分布式发布订阅消息系统Kafka;若否,则解除对目标类型补充数据的锁定。
S503、对分布式发布订阅消息系统消费的交易识别标识对应的多个分块交易数据进行保存处理。
具体的,将交易识别标识抛入分布式发布订阅消息系统Kafka后,利用分布式发布订阅消息系统Kafka根据交易识别标识从HBase中查找对应的多个分块交易数据。然后对交易识别标识对应的多个分块交易数据进行保存处理。利用分布式发布订阅消息系统Kafka进行数据抛入和消费,可实现异步消费目标类型补充数据,提高保存效率。
S504、获取目标类型补充数据中多个分块交易数据的保存状态信息。
具体的,保存状态信息为各个分块交易数据是否保存成功。例如,交易识别标识为A1,交易识别标识对应的多个分块交易数据分别为A11、A12、A13,多个分块交易数据的保存状态信息分别为A11保存成功、A12保存成功、A13未保存成功。
S505、基于保存状态信息判断目标类型补充数据中多个分块交易数据是否全部保存成功。
具体的,若判断目标类型补充数据中多个分块交易数据全部保存成功,则执行S506;若判断目标类型补充数据中多个分块交易数据未全部保存成功,则执行S507。
S506、生成一个或多个目标类型凭证,并更新目标类型补充数据的交易状态。
具体的,更新Hbase中目标类型补充数据的交易状态,更新Hbase中目标类型补充数据的通知状态,删除目标类型补充数据的交易识别标识。
S507、判断目标类型补充数据的保存出错次数是否超过预设值。
在一个具体的实施例中,目标类型补充数据中多个分块交易数据未全部保存成功,则记录保存出错次数1次。预设值可以根据具体情况设定,例如,预设值为5次、6次等。判断目标类型补充数据的保存出错次数未超过预设值时,执行S502,同时更新保存出错次数;判断目标类型补充数据的保存出错次数超过预设值时,执行补偿任务。具体的,补偿任务为:按预设周期查找保存出错的交易数据,将保存出错的交易数据抛入分布式发布订阅消息系统Kafka。其中,预设周期可以为半小时,1小时等,本申请对此不作限定。
为了更好实施本申请实施例中业务凭证的生成方法,在业务凭证的生成方法基础之上,本申请实施例中还提供一种业务凭证的生成装置,如图6所示,业务凭证的生成装置包括:
第一获取单元601,用于获取目标业务的业务凭证生成请求;
第二获取单元602,用于响应请求,获取目标业务的前置交易数据和目标业务的数据分类策略信息;
分类单元603,用于基于数据分类策略信息对前置交易数据进行分类,得到多种类型交易数据;
保存单元604,用于根据预设的凭证保存策略信息,分别对多种类型交易数据进行保存处理,得到目标业务的一个或多个业务凭证。
其中,凭证保存策略信息中包括多种类型交易数据的凭证保存策略信息,保存单元604,还用于基于预设的数据补充策略分别对每种类型交易数据进行补充,得到多种类型补充数据;
基于凭证保存策略信息,确定每种类型交易数据的凭证保存策略信息;
基于每种类型交易数据的凭证保存策略信息,对对应的每种类型补充数据进行保存处理,生成一个或多个业务凭证。
其中,保存单元604,还用于分别以多种类型交易数据中每种类型交易数据为目标类型交易数据,判断目标类型交易数据是否被锁定;
若目标类型交易数据未被锁定,基于预设的数据补充策略对目标类型交易数据进行补充,得到目标类型补充数据。
其中,保存单元604,还用于对目标类型补充数据进行数据切分,得到目标类型补充数据对应的一个或多个分块交易数据;
当目标类型补充数据对应的分块交易数据的数量为多个时,基于目标类型补充数据对应的凭证保存策略对目标类型补充数据对应的多个分块交易数据进行保存处理,生成一个或多个目标类型凭证。
其中,保存单元604,还用于获取目标类型补充数据中多个分块交易数据的保存状态信息;
基于保存状态信息判断目标类型补充数据中多个分块交易数据是否全部保存成功;
若目标类型补充数据中多个分块交易数据全部保存成功,则生成一个或多个目标类型凭证,并更新目标类型补充数据的交易状态。
其中,保存单元604,还用于获取目标类型补充数据的交易识别标识;
将目标类型补充数据的交易识别标识抛入分布式发布订阅消息系统;
对分布式发布订阅消息系统消费的交易识别标识对应的多个分块交易数据进行保存处理。
其中,保存单元604,还用于若目标类型补充数据中多个分块交易数据未全部保存成功,则判断目标类型补充数据的保存出错次数是否超过预设值;
若保存出错次数未超过预设值,则将目标类型补充数据的交易识别标识抛入分布式发布订阅消息系统。
本申请提供一种业务凭证的生成方法,该方法包括:获取目标业务的业务凭证生成请求;响应请求,获取目标业务的前置交易数据和目标业务的数据分类策略信息;基于数据分类策略信息对前置交易数据进行分类,得到多种类型交易数据;根据预设的凭证保存策略信息,分别对多种类型交易数据进行保存处理,得到目标业务的一个或多个业务凭证。本申请根据预设的数据分类策略对大批量业务凭证的前置交易数据进行分类,然后对分类后的多种类型交易数据同时进行保存得到业务凭证,能够支持对大数据量下的高并发处理。
本申请实施例还提供一种服务器。如图7所示,图7是本申请实施例中提供的服务器的一个实施例结构示意图,具体来讲:
该服务器可以包括一个或者一个以上处理核心的处理器701、一个或一个以上计算机可读存储介质的存储器702、电源703和输入单元704等部件。本领域技术人员可以理解,图中示出的服务器结构并不构成对服务器的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。其中:
处理器701是该服务器的控制中心,利用各种接口和线路连接整个服务器的各个部分,通过运行或执行存储在存储器702内的软件程序和/或模块,以及调用存储在存储器702内的数据,执行服务器的各种功能和处理数据,从而对服务器进行整体监控。可选的,处理器701可包括一个或多个处理核心;优选的,处理器701可集成应用处理器和调制解调处理器,其中,应用处理器主要处理操作系统、用户界面和应用程序等,调制解调处理器主要处理无线通信。可以理解的是,上述调制解调处理器也可以不集成到处理器701中。
存储器702可用于存储软件程序以及模块,处理器701通过运行存储在存储器702的软件程序以及模块,从而执行各种功能应用以及数据处理。存储器702主要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等;存储数据区可存储根据服务器的使用所创建的数据等。此外,存储器702可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地,存储器702还可以包括存储器控制器,以提供处理器701对存储器702的访问。
服务器还包括给各个部件供电的电源703,优选的,电源703可以通过电源管理系统与处理器701逻辑相连,从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源703还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。
该服务器还可包括输入单元704,该输入单元704可用于接收输入的数字或字符信息,以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。
尽管未示出,服务器还可以包括显示单元等,在此不再赘述。具体在本实施例中,服务器中的处理器701会按照如下的指令,将一个或一个以上的应用程序的进程对应的可执行文件加载到存储器702中,并由处理器701来运行存储在存储器702中的应用程序,从而实现各种功能,如下:
获取目标业务的业务凭证生成请求;
响应请求,获取目标业务的前置交易数据和目标业务的数据分类策略信息;
基于数据分类策略信息对前置交易数据进行分类,得到多种类型交易数据;
根据预设的凭证保存策略信息,分别对多种类型交易数据进行保存处理,得到目标业务的一个或多个业务凭证。
本领域普通技术人员可以理解,上述实施例的各种方法中的全部或部分步骤可以通过指令来完成,或通过指令控制相关的硬件来完成,该指令可以存储于计算机可读存储介质中,并由处理器进行加载和执行。
为此,本申请实施例提供一种计算机可读存储介质,该计算机可读存储介质可以包括:只读存储器(ROM,Read Only Memory)、随机存取记忆体(RAM,Random AccessMemory)、磁盘或光盘等。其上存储有计算机程序,计算机程序被处理器进行加载,以执行本申请实施例所提供的任一种业务凭证的生成方法中的步骤。例如,计算机程序被处理器进行加载可以执行如下步骤:
获取目标业务的业务凭证生成请求;
响应请求,获取目标业务的前置交易数据和目标业务的数据分类策略信息;
基于数据分类策略信息对前置交易数据进行分类,得到多种类型交易数据;
根据预设的凭证保存策略信息,分别对多种类型交易数据进行保存处理,得到目标业务的一个或多个业务凭证。
在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见上文针对其他实施例的详细描述,此处不再赘述。
具体实施时,以上各个单元或结构可以作为独立的实体来实现,也可以进行任意组合,作为同一或若干个实体来实现,以上各个单元或结构的具体实施可参见前面的方法实施例,在此不再赘述。
以上各个操作的具体实施可参见前面的实施例,在此不再赘述。
以上对本申请实施例所提供的一种业务凭证的生成方法、装置、服务器及存储介质进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处,综上,本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种业务凭证的生成方法,其特征在于,所述业务凭证的生成方法包括:
获取目标业务的业务凭证生成请求;
响应所述请求,获取目标业务的前置交易数据和所述目标业务的数据分类策略信息;
基于所述数据分类策略信息对所述前置交易数据进行分类,得到所述多种类型交易数据;
根据预设的凭证保存策略信息,分别对所述多种类型交易数据进行保存处理,得到所述目标业务的多个业务凭证。
2.如权利要求1所述的业务凭证的生成方法,其特征在于,所述凭证保存策略信息中包括多种类型交易数据的凭证保存策略信息,所述根据预设的凭证保存策略信息,分别对所述多种类型交易数据进行保存处理,得到所述目标业务的多个业务凭证,包括:
基于预设的数据补充策略分别对每种类型交易数据进行补充,得到多种类型补充数据;
基于所述凭证保存策略信息,确定每种类型交易数据的凭证保存策略信息;
基于所述每种类型交易数据的凭证保存策略信息,对对应的每种类型补充数据进行保存处理,生成所述一个或多个业务凭证。
3.如权利要求2所述的业务凭证的生成方法,其特征在于,所述基于预设的数据补充策略分别对每种类型交易数据进行补充,得到多种类型补充数据,包括:
分别以所述多种类型交易数据中每种类型交易数据为目标类型交易数据,判断所述目标类型交易数据是否被锁定;
若所述目标类型交易数据未被锁定,基于预设的数据补充策略对所述目标类型交易数据进行补充,得到所述目标类型补充数据。
4.如权利要求3所述的业务凭证的生成方法,其特征在于,所述基于所述每种类型交易数据的凭证保存策略信息,对对应的每种类型补充数据进行保存处理,生成所述一个或多个业务凭证,包括:
对所述目标类型补充数据进行数据切分,得到所述目标类型补充数据对应的一个或多个分块交易数据;
当所述目标类型补充数据对应的分块交易数据的数量为多个时,基于所述目标类型补充数据对应的凭证保存策略对所述目标类型补充数据对应的多个分块交易数据进行保存处理,生成一个或多个目标类型凭证。
5.如权利要求4所述的业务凭证的生成方法,其特征在于,所述基于所述目标类型补充数据对应的凭证保存策略对所述目标类型补充数据对应的多个分块交易数据进行保存处理,生成一个或多个目标类型凭证,包括:
获取所述目标类型补充数据中所述多个分块交易数据的保存状态信息;
基于所述保存状态信息判断所述目标类型补充数据中所述多个分块交易数据是否全部保存成功;
若所述目标类型补充数据中所述多个分块交易数据全部保存成功,则生成所述一个或多个目标类型凭证,并更新所述目标类型补充数据的交易状态。
6.如权利要求5所述的业务凭证的生成方法,其特征在于,在所述获取所述目标类型补充数据中所述多个分块交易数据的保存状态信息之前,所述生成方法还包括:
获取所述目标类型补充数据的交易识别标识;
将所述目标类型补充数据的交易识别标识抛入分布式发布订阅消息系统;
对分布式发布订阅消息系统消费的交易识别标识对应的多个分块交易数据进行保存处理。
7.如权利要求6所述的业务凭证的生成方法,其特征在于,所述生成方法还包括:
若所述目标类型补充数据中所述多个分块交易数据未全部保存成功,则判断所述目标类型补充数据的保存出错次数是否超过预设值;
若所述保存出错次数未超过预设值,则将所述目标类型补充数据的交易识别标识抛入分布式发布订阅消息系统。
8.一种业务凭证的生成装置,其特征在于,所述生成装置包括:
第一获取单元,用于获取目标业务的业务凭证生成请求;
第二获取单元,用于响应所述请求,获取目标业务的前置交易数据和所述目标业务的数据分类策略信息;
分类单元,用于基于所述数据分类策略信息对所述前置交易数据进行分类,得到所述多种类型交易数据;
保存单元,用于根据预设的凭证保存策略信息,分别对所述多种类型交易数据进行保存处理,得到所述目标业务的一个或多个业务凭证。
9.一种服务器,其特征在于,所述服务器包括:
一个或多个处理器;
存储器;以及
一个或多个应用程序,其中所述一个或多个应用程序被存储于所述存储器中,并配置为由所述处理器执行以实现权利要求1至7中任一项所述的业务凭证的生成方法。
10.一种计算机可读存储介质,其特征在于,其上存储有计算机程序,所述计算机程序被处理器进行加载,以执行权利要求1至7任一项所述的业务凭证的生成方法中的步骤。
CN202010811442.XA 2020-08-13 2020-08-13 业务凭证的生成方法、装置、服务器及存储介质 Pending CN114077604A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010811442.XA CN114077604A (zh) 2020-08-13 2020-08-13 业务凭证的生成方法、装置、服务器及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010811442.XA CN114077604A (zh) 2020-08-13 2020-08-13 业务凭证的生成方法、装置、服务器及存储介质

Publications (1)

Publication Number Publication Date
CN114077604A true CN114077604A (zh) 2022-02-22

Family

ID=80280578

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010811442.XA Pending CN114077604A (zh) 2020-08-13 2020-08-13 业务凭证的生成方法、装置、服务器及存储介质

Country Status (1)

Country Link
CN (1) CN114077604A (zh)

Similar Documents

Publication Publication Date Title
US10430875B2 (en) Integration and enhancement of business systems with external services
US10579973B2 (en) System for efficient processing of transaction requests related to an account in a database
CN110458562B (zh) 票据报销方法、装置和设备及计算机存储介质
US20160328791A1 (en) System and method for electronic consumer debt validation and dispute process
US11863659B2 (en) Shipping platform
CN108830697A (zh) 一种业财一体化系统和方法
JP6310092B2 (ja) 業務連携システムおよび業務連携方法
CN108897729B (zh) 一种交易模板共享方法、装置、电子设备及存储介质
CN111311277B (zh) 一种基于区块链网络的票据处理方法、装置和相关设备
CN102208061A (zh) 数据核销处理装置和数据核销处理方法
CN108765106A (zh) 一种业财一体化的财务凭证生成方法
CN112200595A (zh) 优惠券校验方法、支付方法、装置、设备及介质
CN117742843A (zh) 一种交割服务业务表单生成方法和系统
US20150066800A1 (en) Turbo batch loading and monitoring of documents for enterprise workflow applications
CN114077604A (zh) 业务凭证的生成方法、装置、服务器及存储介质
US20140236781A1 (en) Systems and Methods for an In-Memory Budget Finder
CN113055401B (zh) 一种企业业务的授权处理方法及装置
CN113835780A (zh) 一种事件响应方法及装置
CN113706107A (zh) 公积金缴存方法、装置、电子设备及计算机可读介质
CN112085461A (zh) 一种面向交叉销售的佣金结算方法、装置及存储介质
CN104205133A (zh) 便携终端管理服务器及便携终端管理程序
CN110766540A (zh) 一种账单核销方法、装置及电子设备
JP2020194387A (ja) マッチング支援装置、マッチング支援方法、コンピュータプログラム及び記録媒体
CN113988773A (zh) 凭证的核销方法、装置、服务器及存储介质
JP2019204326A (ja) 電文処理装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination