CN110796437A - 业务处理方法、装置、设备及存储介质 - Google Patents

业务处理方法、装置、设备及存储介质 Download PDF

Info

Publication number
CN110796437A
CN110796437A CN201911067394.1A CN201911067394A CN110796437A CN 110796437 A CN110796437 A CN 110796437A CN 201911067394 A CN201911067394 A CN 201911067394A CN 110796437 A CN110796437 A CN 110796437A
Authority
CN
China
Prior art keywords
application
supplementary
payment
account management
management system
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
CN201911067394.1A
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.)
Taikang Insurance Group Co Ltd
Taikang Pension Insurance Co Ltd
Original Assignee
Taikang Insurance Group 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 Taikang Insurance Group Co Ltd filed Critical Taikang Insurance Group Co Ltd
Priority to CN201911067394.1A priority Critical patent/CN110796437A/zh
Publication of CN110796437A publication Critical patent/CN110796437A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/103—Workflow collaboration or project management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/08—Insurance

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Human Resources & Organizations (AREA)
  • General Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Marketing (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Technology Law (AREA)
  • Data Mining & Analysis (AREA)
  • Development Economics (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本申请提供一种业务处理方法、装置、设备及存储介质，该方法包括：接收账管系统发送的申请打回消息；根据所述申请打回消息获取补充申请页面数据；将所述补充申请页面数据发送给终端；接收所述终端发送的补充提交申请数据；将所述补充提交申请数据发送给所述账管系统，以使账管系统可以再次审核补充提交申请数据，若审核通过，则可以计算给付权益，生成待遇支付详细信息发送给受托系统，受托系统可以根据待遇支付详细信息向托管系统发送待遇支付指令，由托管系统进行权益支付。由于业务处理流程增加了补充材料的节点，可以有效方便用户操作，提高业务处理效率，提高用户体验。

Description

业务处理方法、装置、设备及存储介质
技术领域
本申请涉及互联网技术领域，尤其涉及一种业务处理方法、装置、设备及存储介质。
背景技术
企业年金业务运营通常涉及受托系统、账管系统和托管系统三方管理机构。企业成员或受益人可以通过企业终端向受托系统提交待遇支付申请材料，受托系统审核后发送账管系统，由账管系统进行审核，若审核通过则计算给付权益，生成待遇支付详细信息发送刚给受托系统，受托系统可以根据待遇支付详细信息指示托管系统进行权益支付。
但是，现有技术的业务处理流程，当账管系统审核不通过时，业务即作废，需要成员或受益人重新提交全部材料并再次发起申请，业务操作繁琐，效率较低，导致用户体验差。
发明内容
本申请提供一种业务处理方法、装置、设备及存储介质，以解决现有技术业务处理效率低等缺陷。
本申请第一个方面提供一种业务处理方法，包括：
接收账管系统发送的申请打回消息；
根据所述申请打回消息获取补充申请页面数据；
将所述补充申请页面数据发送给终端；
接收所述终端发送的补充提交申请数据；
将所述补充提交申请数据发送给所述账管系统。
可选地，在接收账管系统发送的申请打回消息之前，所述方法还包括：
接收所述终端发送的待遇支付申请信息；
对所述待遇支付申请信息进行审核；
若审核通过，将所述待遇支付申请信息发送给所述账管系统。
可选地，在接收所述终端发送的补充提交申请数据之后，所述方法还包括：
对所述补充提交申请数据进行审核；
所述将所述补充提交申请数据发送给所述账管系统，包括：
若审核通过，将所述补充提交申请数据发送给所述账管系统。
可选地，若所述申请打回消息为全打回消息，所述根据所述申请打回消息获取补充申请页面数据，包括：
根据所述申请打回消息获取第一页面数据，所述第一页面数据用于展示第一页面，以使用户在第一页面补充全部受益人的相关信息。
可选地，若所述申请打回消息为部分打回消息，所述根据所述申请打回消息获取补充申请页面数据，包括：
根据所述申请打回消息获取第二页面数据，所述第二页面数据用于展示第二页面，以使用户在第二页面补充账管系统审核未通过的受益人的相关信息。
可选地，在接收所述终端发送的补充提交申请数据之后，所述方法还包括：
若所述补充提交数据仅包括被打回受益人的放弃支付证明，业务结束，则不执行将所述补充提交申请数据发送给所述账管系统的步骤；
若所述补充提交数据包括至少一个被打回受益人的待遇支付明细信息及其他被打回受益人的放弃支付证明，则将所述补充提交申请数据发送给所述账管系统。
可选地，所述方法还包括：
接收所述账管系统发送的待遇支付详细信息；
根据所述待遇支付详细信息向托管系统发送待遇支付指令，以使所述托管系统根据所述待遇支付指令进行权益支付处理；
接收所述托管系统返回的支付结果。
本申请第二个方面提供一种业务处理装置，包括：
第一接收模块，用于接收账管系统发送的申请打回消息；
处理模块，用于根据所述申请打回消息获取补充申请页面数据；
第一发送模块，用于将所述补充申请页面数据发送给终端；
第二接收模块，用于接收所述终端发送的补充提交申请数据；
第二发送模块，用于将所述补充提交申请数据发送给所述账管系统。
可选地，所述第二接收模块，还用于接收所述终端发送的待遇支付申请信息；
所述处理模块，还用于对所述待遇支付申请信息进行审核；
所述第二发送模块，还用于若审核通过，将所述待遇支付申请信息发送给所述账管系统。
可选地，所述处理模块，还用于对所述补充提交申请数据进行审核；
所述第二发送模块，具体用于若审核通过，将所述补充提交申请数据发送给所述账管系统。
可选地，所述处理模块，具体用于：
若所述申请打回消息为全打回消息，根据所述申请打回消息获取第一页面数据，所述第一页面数据用于展示第一页面，以使用户在第一页面补充全部受益人的相关信息。
可选地，所述处理模块，具体用于：
若所述申请打回消息为部分打回消息，根据所述申请打回消息获取第二页面数据，所述第二页面数据用于展示第二页面，以使用户在第二页面补充账管系统审核未通过的受益人的相关信息。
可选地，所述处理模块，还用于若所述补充提交数据仅包括被打回受益人的放弃支付证明，业务结束，则不执行将所述补充提交申请数据发送给所述账管系统的步骤；
所述第二发送模块，还用于若所述补充提交数据包括至少一个被打回受益人的待遇支付明细信息及其他被打回受益人的放弃支付证明，则将所述补充提交申请数据发送给所述账管系统。
可选地，所述第一接收模块，还用于接收所述账管系统发送的待遇支付详细信息；
所述第二发送模块，还用于根据所述待遇支付详细信息向托管系统发送待遇支付指令，以使所述托管系统根据所述待遇支付指令进行权益支付处理；
所述第一接收模块，还用于接收所述托管系统返回的支付结果。
本申请第三个方面提供一种电子设备，包括：至少一个处理器和存储器；
所述存储器存储计算机执行指令；
所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如上第一个方面以及第一个方面各种可能的设计所述的方法。
本申请第四个方面提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如上第一个方面以及第一个方面各种可能的设计所述的方法。
本申请提供的业务处理方法、装置、设备及存储介质，若账管系统审核不通过，可以向受托系统返回申请打回消息，将申请打回到补充资料节点，受托系统可以根据申请打回消息获取补充申请页面数据发送给终端进行显示补充申请页面，相关人员通过补充申请页面提交被打回的各受益人的相关信息，相关人员在补充申请页面输入各受益人的相关信息后，终端则可以获取到这些信息作为补充提交申请数据发送给受托系统，受托系统接收到终端发送的补充提交申请数据后，可以发送给账管系统，以使账管系统可以再次审核补充提交申请数据，若审核通过，则可以计算给付权益，生成待遇支付详细信息发送给受托系统，受托系统可以根据待遇支付详细信息向托管系统发送待遇支付指令，由托管系统进行权益支付。由于业务处理流程增加了补充材料的节点，可以有效方便用户操作，提高业务处理效率，提高用户体验。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为现有技术待遇支付的业务处理流程示意图；
图2为本申请实施例基于的处理系统的架构示意图；
图3为本申请一实施例提供的业务处理方法的流程示意图；
图4为本申请另一实施例提供的业务处理方法的流程示意图；
图5为本申请一实施例提供的待遇支付的业务流程示意图；
图6为本申请一实施例提供的补充提交待遇支付申请材料节点的处理逻辑示意图；
图7为本申请一实施例提供的业务处理装置的结构示意图；
图8为本申请一实施例提供的电子设备的结构示意图。
通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本公开构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
首先对本申请所涉及的名词进行解释：
成员或受益人：成员本人或身故受益人。
受托系统：或称受托人，是指接受企业委托，管理企业年金基金的法人受托机构；
账管系统：或称账管人，是指接受受托人委托，管理企业年金基金账户，进行记账的专业机构；
托管系统：或称托管人，是指接受受托人委托，保管企业年金基金财产的银行机构；
待遇支付：指参加企业年金计划的成员因退休、身故、出境定居等原因，由成员本人、身故受益人或者授权代理人向受托人提出申请，并通过确认后，由账管人计算给付权益，由受托人向托管银行(即托管人)发送支付指令进行支付的过程。
如图1所示，为现有技术待遇支付的业务处理流程示意图。具体如下：
1、受益人通过企业向受托人提交待遇支付申请材料；
2、受托人审核后发送账户管理人(即账管人)；
3、账管人进行审核、计算给付权益，并生成待遇支付详细信息发送给受托人；
4、受托人根据待遇支付详细信息向托管人发送待遇支付指令；
5、托管人根据受托人指令进行权益支付并反馈受托人支付结果。
当受托人提交给账管人的一批多个受益人的待遇支付申请中存在账管人审核不通过的信息时，将出现这批待遇支付申请被账管打回的异常处理情况，需要将本次待遇支付申请作废，重新提交全部材料并再次发起新一次的待遇支付申请，业务操作繁琐，用户体验差，人力成本较高。
针对上述技术问题，本申请实施例提供一种业务处理方法，适用于待遇支付的业务处理场景。如图2所示，为本申请实施例基于的处理系统的架构示意图。该处理系统可以包括受托系统、账管系统、托管系统及企业的终端。其中受托系统可以包括受托服务器和受托终端，账管系统可以包括账管服务器和账管终端，托管系统也可以包括托管服务器和托管终端，具体可以根据实际需求设置。用户(企业成员或受益人)可以通过企业终端向受托系统发送待遇支付申请信息，受托系统接收到终端发送的待遇支付申请信息可以对其进行审核，在审核通过后发送给账管系统，账管系统对其进行审核，若审核不通过，则向受托系统返回申请打回消息，将申请打回到补充资料节点，申请打回消息具体可以包括审核不通过的原因及其他相关信息。受托系统接收到账管系统发送的申请打回消息后，可以根据申请打回消息获取补充申请页面数据发送给终端进行显示补充申请页面，这里终端可以是企业的终端由企业管理人员进行补充，也可以是受托终端，企业方可以将资料发送给受托方相关管理人员，由受托方相关管理人员进行补充，具体可以根据实际需求设置。相关人员通过补充申请页面提交被打回的各受益人的相关信息，比如待遇支付明细信息或者放弃支付证明等。待遇支付明细信息表示该受益人请求继续支付，放弃支付证明表示该受益人放弃支付。相关人员在补充申请页面输入各受益人的相关信息后，终端则可以获取到这些信息作为补充提交申请数据发送给受托系统，受托系统接收到终端发送的补充提交申请数据后，可以再次进行审核，审核通过后发送给账管系统，账管系统可以再次审核补充提交申请数据，若审核通过，则可以计算给付权益，生成待遇支付详细信息发送给受托系统，受托系统可以根据待遇支付详细信息向托管系统发送待遇支付指令，由托管系统进行权益支付。由于业务处理流程增加了补充材料的节点，可以有效方便用户操作，提高业务处理效率，提高用户体验。
此外，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。在以下各实施例的描述中，“多个”的含义是两个以上，除非另有明确具体的限定。
下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本发明的实施例进行描述。
本申请一实施例提供一种业务处理方法，用于待遇支付的业务处理。本实施例的执行主体为业务处理装置，该装置可以设置在受托系统中。
如图3所示，为本实施例提供的业务处理方法的流程示意图，该方法包括：
步骤101，接收账管系统发送的申请打回消息。
具体的，申请打回消息可以包括被打回的受益人的相关信息、被打回原因等信息。用户(企业成员或受益人)可以通过企业终端向受托系统发送待遇支付申请信息，受托系统接收到终端发送的待遇支付申请信息可以对其进行审核，在审核通过后发送给账管系统，账管系统对其进行审核，若账管系统审核不通过，可以向受托系统返回申请打回消息，将业务申请打回到补充资料节点，受托系统则可以接收到账管系统发送的申请打回消息。
可选地，申请打回消息可以是全打回消息也可以是部分打回消息，具体根据账管系统的不同返回的申请打回消息类型不同。具体来说，账管行(即账管系统)可能支持全部回滚方式，或者支持部分回滚方式。支持全部回滚方式的账管行返回的即为全打回消息，支持部分回滚方式的账管行返回的即为部分打回消息。
其中，账管行全部回滚方式是指：账管行对待遇支付申请信息进行审核，待遇支付申请信息可以包括一个或多个受益人的申请，遇到审核不通过的受益人申请，则全部申请被打回流程中的补充提交待遇支付申请材料节点(可简称为补充资料节点)。全部受益人需要通过企业终端或者需要受托方相关人员重新上传待遇支付明细信息(比如待遇支付明细表)或放弃支付证明材料。待遇支付明细信息表示该受益人请求继续支付，放弃支付证明表示该受益人放弃支付。
账管行部分回滚方式是指：账管行对所有受益人信息进行审核，通过的受益人申请正常流转到下一节点，未通过审核的受益人申请被打回流程中的补充提交待遇支付申请材料节点。对于审核未通过的受益人，需要相关受益人或企业成员或受托管理人员重新上传待遇支付明细信息或放弃支付证明材料。
步骤102，根据申请打回消息获取补充申请页面数据。
受托系统接收到账管系统发送的申请打回消息后，可以根据申请打回消息获取补充申请页面数据，补充申请页面数据用于展示补充申请页面，以使相关人员可以通过补充申请页面补充提交各受益人的相关信息。
可选地，针对不同类型的申请打回消息，可以设置不同的补充申请页面，具体的补充申请页面可以根据实际需求设置，本实施例不做限定。
步骤103，将补充申请页面数据发送给终端。
受托系统获取到补充申请页面数据后，可以发送给终端，以使终端显示补充申请页面，相关人员可以通过补充申请页面提交被打回的各受益人的相关信息，相关人员在补充申请页面输入各受益人的相关信息后，终端则可以获取到这些信息作为补充提交申请数据发送给受托系统。
步骤104，接收终端发送的补充提交申请数据。
步骤105，将补充提交申请数据发送给账管系统。
受托系统接收到终端发送的补充提交申请数据后，可以发送给账管系统，以使账管系统可以再次审核补充提交申请数据，若审核通过，则可以计算给付权益，生成待遇支付详细信息发送给受托系统，受托系统可以根据待遇支付详细信息向托管系统发送待遇支付指令，由托管系统进行权益支付。由于业务处理流程增加了补充材料的节点，可以有效方便用户操作，提高业务处理效率，提高用户体验。
本实施例提供的业务处理方法，若账管系统审核不通过，可以向受托系统返回申请打回消息，将申请打回到补充资料节点，受托系统可以根据申请打回消息获取补充申请页面数据发送给终端进行显示补充申请页面，相关人员通过补充申请页面提交被打回的各受益人的相关信息，相关人员在补充申请页面输入各受益人的相关信息后，终端则可以获取到这些信息作为补充提交申请数据发送给受托系统，受托系统接收到终端发送的补充提交申请数据后，可以发送给账管系统，以使账管系统可以再次审核补充提交申请数据，若审核通过，则可以计算给付权益，生成待遇支付详细信息发送给受托系统，受托系统可以根据待遇支付详细信息向托管系统发送待遇支付指令，由托管系统进行权益支付。由于业务处理流程增加了补充材料的节点，可以有效方便用户操作，提高业务处理效率，提高用户体验。
本申请另一实施例对上述实施例提供的业务处理方法做进一步补充说明。
如图4所示，为本实施例提供的业务处理方法的流程示意图。
作为一种可实施的方式，在上述实施例的基础上，可选地，在步骤101之前，该方法还可以包括：
步骤2011，接收终端发送的待遇支付申请信息。
步骤2012，对待遇支付申请信息进行审核。
步骤2013，若审核通过，将待遇支付申请信息发送给账管系统。
具体的，用户(企业成员或受益人)可以通过企业终端向受托系统发送待遇支付申请信息，待遇支付申请信息可以包括一个或多个受益人的申请，每个受益人的申请可以包括申请时间、申请人信息、受益人信息、支付方式、受益人账户及其他相关信息。
受托系统接收到终端发送的待遇支付申请信息可以对其进行审核，在审核通过后发送给账管系统，以使账管系统进行审核，并在审核通过后计算给付权益，生成待遇支付详细信息。
可选地，受托系统对待遇支付申请信息进行审核可以是将待遇支付申请信息通过受托终端进行展示，由受托管理人员进行审核，来确定是否审核通过。
可选地，受托系统对待遇支付申请信息进行审核也可以是预先设置审核规则，由受托系统自动对其进行审核，审核规则可以根据受益人类型(包括退休、身故、出境定居等)设置不同的审核规则。比如对于退休类型的受益人，审核规则可以包括年龄规则(比如年龄要高于65岁)，受托系统根据各受益人的年龄及审核规则判断受益人是否符合年龄规则等。若受益人满足所有审核规则，则该受益人审核通过。具体的审核规则可以根据实际需求设置，本实施例不做限定。
作为另一种可实施的方式，在上述实施例的基础上，可选地，在接收终端发送的补充提交申请数据之后，该方法还包括：
步骤2021，对补充提交申请数据进行审核。
将补充提交申请数据发送给账管系统，包括：
步骤2022，若审核通过，将补充提交申请数据发送给账管系统。
具体的，对于补充提交申请数据的审核可以与上述对待遇支付申请信息的审核类似，具体审核规则可以根据实际需求设置为与上述审核规则相同或不同，本实施例不做限定。
补充提交申请数据可以包括各受益人的待遇支付明细信息或放弃支付证明。比如，若某个受益人的审核不通过原因无法克服，比如年龄不满足年龄规则，则只能放弃支付，可以针对该受益人补充提交放弃支付证明，若受益人审核不通过的原因可以克服，比如缺少了某些信息内容，只要补充即可，则可以补充提交该受益人的待遇支付明细信息。受托系统将补充提交申请数据再发送给账管系统进行审核，若审核通过则可以计算给付权益，生成待遇支付详细信息。
作为另一种可实施的方式，在上述实施例的基础上，可选地，根据申请打回消息获取补充申请页面数据，包括：
步骤2031，若申请打回消息为全打回消息，根据申请打回消息获取第一页面数据，第一页面数据用于展示第一页面，以使用户在第一页面补充全部受益人的相关信息。
可选地，根据申请打回消息获取补充申请页面数据，包括：
步骤2041，若申请打回消息为部分打回消息，根据申请打回消息获取第二页面数据，第二页面数据用于展示第二页面，以使用户在第二页面补充账管系统审核未通过的受益人的相关信息。
具体的，根据账管系统的不同返回的申请打回消息类型不同。具体来说，账管行(即账管系统)可能支持全部回滚方式，或者支持部分回滚方式。支持全部回滚方式的账管行返回的即为全打回消息，支持部分回滚方式的账管行返回的即为部分打回消息。
其中，账管行全部回滚方式是指：账管行对待遇支付申请信息进行审核，待遇支付申请信息可以包括一个或多个受益人的申请，遇到审核不通过的受益人申请，则全部申请被打回流程中的补充提交待遇支付申请材料节点(可简称为补充资料节点)。全部受益人需要通过企业终端或者需要受托方相关人员重新上传待遇支付明细信息(比如待遇支付明细表)或放弃支付证明材料。待遇支付明细信息表示该受益人请求继续支付，放弃支付证明表示该受益人放弃支付。
账管行部分回滚方式是指：账管行对所有受益人信息进行审核，通过的受益人申请正常流转到下一节点，未通过审核的受益人申请被打回流程中的补充提交待遇支付申请材料节点。对于审核未通过的受益人，需要相关受益人或企业成员或受托管理人员重新上传待遇支付明细信息或放弃支付证明材料。
针对账管行的不同回滚方式，提供了不同的补充申请页面，对于全部回滚方式，提供第一页面，对于部分回滚方式提供第二页面。
示例性的，受托系统可以保存待遇支付申请信息的提交页面数据，当申请被打回时，可以根据申请打回消息包括的受益人信息及预先保存的提交页面数据，来获取补充申请页面数据。比如当申请打回消息为全打回消息时，可以获取原来的提交页面数据，展示提交页面，即第一页面，各受益人的原来提交的相关信息均存在，相关人员只要针对被打回原因，修改或补充有问题的信息即可。对于部分打回消息，可以根据申请打回消息包括的受益人信息及预先保存的提交页面数据，只获取被打回受益人相关的页面数据，展示第二页面，相关人员在第二页面补充被打回受益人相关信息即可。具体的页面可以根据实际需求设置，本实施例不做限定。
作为另一种可实施的方式，在上述实施例的基础上，可选地，在接收终端发送的补充提交申请数据之后，该方法还包括：
若补充提交数据仅包括被打回受益人的放弃支付证明，业务结束，则不执行将补充提交申请数据发送给账管系统的步骤。
若补充提交数据包括至少一个被打回受益人的待遇支付明细信息及其他被打回受益人的放弃支付证明，则将补充提交申请数据发送给账管系统。
具体来说，对于全打回消息和部分打回消息，若被打回的受益人全部放弃支付，不需要提交待遇支付明细信息，只需要提交放弃支付证明材料，业务完成，受托系统可以不向账管系统发送补充提交申请数据，或者向账管系统发送业务结束的消息。
若被打回受益人有部分放弃支付，其他受益人仍需要支付，则需要提交进行支付的受益人的待遇支付明细信息及放弃支付受益人的放弃支付证明材料，受托系统将补充提交申请数据发送给账管系统进行审核。
若被打回受益人全部需要进行支付，则需要补充全部进行支付受益人的待遇支付明细信息，不需要提交放弃支付证明材料，业务流转到账管系统节点再次审核。
作为另一种可实施的方式，在上述实施例的基础上，可选地，该方法还可以包括：
步骤2051，接收账管系统发送的待遇支付详细信息。
步骤2052，根据待遇支付详细信息向托管系统发送待遇支付指令，以使托管系统根据待遇支付指令进行权益支付处理。
步骤2053，接收托管系统返回的支付结果。
账管系统在对初次提交的待遇支付申请信息或者补充提交的申请数据审核通过后，则可以计算给付权益，生成待遇支付详细信息发送给受托系统，待遇支付详细信息可以包括各受益人对应的支付方式、支付金额、账户信息及其他相关信息，比如支付方式为分期支付，则待遇支付详细信息还包括如何分期，支付金额则包括每期应支付金额等等。也即待遇支付详细信息包括了具体如何向各受益人支付。
受托系统可以根据待遇支付详细信息向托管系统发送待遇支付指令，由托管系统根据待遇支付指令进行权益支付。待遇支付指令可以包括待遇支付详细信息。
托管系统根据待遇支付指令进行权益支付后，可以向受托系统发送支付结果，支付结果可以包括支付成功信息或支付失败信息，若包括支付成功信息，还可以包括具体支付信息，比如被支付方账户、支付时间、支付金额等等，具体可以根据实际需求设置。
受托系统可以将支付结果进行存储，以备后续查看。
作为一种示例性的可实施方式，如图5所示，为本实施例提供的待遇支付的业务流程示意图。
示例性的，如图6所示，为本实施例提供的补充提交待遇支付申请材料节点的处理逻辑示意图。
具体来说，待遇支付申请被账管系统打回的异常处理，根据账管行的不同，会有如下两种情况：
1、账管行全部回滚情况：
账管行对受益人信息进行审核，遇到审核不通过的受益人申请，全部申请被打回流程中的补充提交待遇支付申请材料节点。
全部受益人，需要受托人重新上传重待遇支付明细表和放弃支付证明材料，根据业务需要，会有以下三种处理方式：
(1)受益人全部放弃支付，不需要提交待遇支付明细表，只需要提交放弃支付证明材料，业务完成。
(2)受益人部分放弃支付，需要提交进行支付的受益人的支付明细表，及放弃支付受益人的放弃支付证明材料，业务流转到账管节点再次审核。
(3)受益人全部进行支付，需要提交全部进行支付人员的待遇支付明细表，不需要提交放弃支付证明材料，业务流转到账管节点再次审核。
2、账管行部分回滚情况：
账管行对所有受益人信息进行审核，通过的受益人申请正常流转到下一节点，未通过审核的受益人申请被打回流程中的补充提交待遇支付申请材料节点。
审核未通过的受益人，需要受托人重新上传重待遇支付明细表和放弃支付证明材料，根据业务需要，会有以下三种处理方式：
(1)未通过审核的受益人全部放弃支付，不需要提交待遇支付明细表，只需要提交放弃支付证明材料，业务完成。
(2)未通过审核的受益人部分放弃支付，需要提交进行支付的受益人的支付明细表，及放弃支付受益人的放弃支付证明材料，业务流转到账管节点再次审核。
(3)未通过审核的受益人全部进行支付，需要提交全部进行支付人员的待遇支付明细表，不需要提交放弃支付证明材料，业务流转到账管节点再次审核。
账管系统可以根据受托系统发送的补充提交申请数据所包括的补充材料的类型，根据上述情况自动进行差异化处理。对于放弃支付的受益人不予计算给付权益，对于进行支付的受益人计算给付权益，生成待遇支付详细信息。
作为另一种示例性的可实施方式，待遇支付的业务流程具体如下：
1、假设a企业10名受益人通过a企业向受托人提交待遇支付申请；
2、受托人审核通过后发送账户管理人b；
3、账管人b对这10名受益人的待遇支付申请进行审核，其中7名受益人的申请通过审核，3名受益人的申请审核不通过，账管人b的管理规则是全部回滚的方式，则这10名收益人的待遇支付申请全部被打回到补充提交待遇支付申请材料节点；
4、假设申请不通过的3名受益人选择放弃支付，则企业可以选择上传审核通过的7名受益人的待遇支付申请明细表以及其余3名受益人放弃支付证明材料；
5、受托人重新审核后发送账户管理人b；
6、账管人b进行审核、计算给付权益，并生成7名受益人的待遇支付详细信息发送受托人；
7、受托人根据待遇支付详细信息向托管人发送待遇支付指令；
8、托管人根据受托人指令进行权益支付并反馈受托人支付结果。
本申请实施例中，对待遇支付申请被账管系统打回的异常情况，增加了补充资料节点，提高系统自动化性能，提高业务处理效率，使用户满意度更高。
需要说明的是，本实施例中各可实施的方式可以单独实施，也可以在不冲突的情况下以任意组合方式结合实施本申请不做限定。
本实施例提供的业务处理方法，若账管系统审核不通过，可以向受托系统返回申请打回消息，将申请打回到补充资料节点，受托系统可以根据申请打回消息获取补充申请页面数据发送给终端进行显示补充申请页面，相关人员通过补充申请页面提交被打回的各受益人的相关信息，相关人员在补充申请页面输入各受益人的相关信息后，终端则可以获取到这些信息作为补充提交申请数据发送给受托系统，受托系统接收到终端发送的补充提交申请数据后，可以发送给账管系统，以使账管系统可以再次审核补充提交申请数据，若审核通过，则可以计算给付权益，生成待遇支付详细信息发送给受托系统，受托系统可以根据待遇支付详细信息向托管系统发送待遇支付指令，由托管系统进行权益支付。由于业务处理流程增加了补充材料的节点，可以有效方便用户操作，提高业务处理效率，提高用户体验。
本申请再一实施例提供一种业务处理装置，用于执行上述实施提供的业务处理方法。
如图7所示，为本实施例提供的业务处理装置的结构示意图。该业务处理装置30包括第一接收模块31、处理模块32、第一发送模块33、第二接收模块34和第二发送模块35。
其中，第一接收模块，用于接收账管系统发送的申请打回消息；处理模块，用于根据申请打回消息获取补充申请页面数据；第一发送模块，用于将补充申请页面数据发送给终端；第二接收模块，用于接收终端发送的补充提交申请数据；第二发送模块，用于将补充提交申请数据发送给账管系统。
关于本实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。
根据本实施例提供的业务处理装置，若账管系统审核不通过，可以向受托系统返回申请打回消息，将申请打回到补充资料节点，受托系统可以根据申请打回消息获取补充申请页面数据发送给终端进行显示补充申请页面，相关人员通过补充申请页面提交被打回的各受益人的相关信息，相关人员在补充申请页面输入各受益人的相关信息后，终端则可以获取到这些信息作为补充提交申请数据发送给受托系统，受托系统接收到终端发送的补充提交申请数据后，可以发送给账管系统，以使账管系统可以再次审核补充提交申请数据，若审核通过，则可以计算给付权益，生成待遇支付详细信息发送给受托系统，受托系统可以根据待遇支付详细信息向托管系统发送待遇支付指令，由托管系统进行权益支付。由于业务处理流程增加了补充材料的节点，可以有效方便用户操作，提高业务处理效率，提高用户体验。
本申请又一实施例对上述实施例提供的业务处理装置做进一步补充说明。
作为一种可实施的方式，在上述实施例的基础上，可选地，第二接收模块，还用于接收终端发送的待遇支付申请信息；处理模块，还用于对待遇支付申请信息进行审核；第二发送模块，还用于若审核通过，将待遇支付申请信息发送给账管系统。
作为另一种可实施的方式，在上述实施例的基础上，可选地，处理模块，还用于对补充提交申请数据进行审核；第二发送模块，具体用于若审核通过，将补充提交申请数据发送给账管系统。
作为另一种可实施的方式，在上述实施例的基础上，可选地，处理模块，具体用于：
若申请打回消息为全打回消息，根据申请打回消息获取第一页面数据，第一页面数据用于展示第一页面，以使用户在第一页面补充全部受益人的相关信息。
可选地，处理模块，具体用于：
若申请打回消息为部分打回消息，根据申请打回消息获取第二页面数据，第二页面数据用于展示第二页面，以使用户在第二页面补充账管系统审核未通过的受益人的相关信息。
可选地，处理模块，还用于若补充提交数据仅包括被打回受益人的放弃支付证明，业务结束，则不执行将补充提交申请数据发送给账管系统的步骤；第二发送模块，还用于若补充提交数据包括至少一个被打回受益人的待遇支付明细信息及其他被打回受益人的放弃支付证明，则将补充提交申请数据发送给账管系统。
作为另一种可实施的方式，在上述实施例的基础上，可选地，第一接收模块，还用于接收账管系统发送的待遇支付详细信息；第二发送模块，还用于根据待遇支付详细信息向托管系统发送待遇支付指令，以使托管系统根据待遇支付指令进行权益支付处理；第一接收模块，还用于接收托管系统返回的支付结果。
关于本实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。
需要说明的是，本实施例中各可实施的方式可以单独实施，也可以在不冲突的情况下以任意组合方式结合实施本申请不做限定。
根据本实施例的业务处理装置，若账管系统审核不通过，可以向受托系统返回申请打回消息，将申请打回到补充资料节点，受托系统可以根据申请打回消息获取补充申请页面数据发送给终端进行显示补充申请页面，相关人员通过补充申请页面提交被打回的各受益人的相关信息，相关人员在补充申请页面输入各受益人的相关信息后，终端则可以获取到这些信息作为补充提交申请数据发送给受托系统，受托系统接收到终端发送的补充提交申请数据后，可以发送给账管系统，以使账管系统可以再次审核补充提交申请数据，若审核通过，则可以计算给付权益，生成待遇支付详细信息发送给受托系统，受托系统可以根据待遇支付详细信息向托管系统发送待遇支付指令，由托管系统进行权益支付。由于业务处理流程增加了补充材料的节点，可以有效方便用户操作，提高业务处理效率，提高用户体验。
本申请再一实施例提供一种电子设备，用于执行上述实施例提供的业务处理方法。该电子设备可以为服务器，设置在受托管理系统中。
如图8所示，为本实施例提供的电子设备的结构示意图。该电子设备50包括：至少一个处理器51和存储器52；
存储器存储计算机执行指令；至少一个处理器执行存储器存储的计算机执行指令，使得至少一个处理器执行如上任一实施例提供的方法。
根据本实施例的电子设备，若账管系统审核不通过，可以向受托系统返回申请打回消息，将申请打回到补充资料节点，受托系统可以根据申请打回消息获取补充申请页面数据发送给终端进行显示补充申请页面，相关人员通过补充申请页面提交被打回的各受益人的相关信息，相关人员在补充申请页面输入各受益人的相关信息后，终端则可以获取到这些信息作为补充提交申请数据发送给受托系统，受托系统接收到终端发送的补充提交申请数据后，可以发送给账管系统，以使账管系统可以再次审核补充提交申请数据，若审核通过，则可以计算给付权益，生成待遇支付详细信息发送给受托系统，受托系统可以根据待遇支付详细信息向托管系统发送待遇支付指令，由托管系统进行权益支付。由于业务处理流程增加了补充材料的节点，可以有效方便用户操作，提高业务处理效率，提高用户体验。
本申请又一实施例提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，当处理器执行计算机执行指令时，实现如上任一实施例提供的方法。
根据本实施例的计算机可读存储介质，若账管系统审核不通过，可以向受托系统返回申请打回消息，将申请打回到补充资料节点，受托系统可以根据申请打回消息获取补充申请页面数据发送给终端进行显示补充申请页面，相关人员通过补充申请页面提交被打回的各受益人的相关信息，相关人员在补充申请页面输入各受益人的相关信息后，终端则可以获取到这些信息作为补充提交申请数据发送给受托系统，受托系统接收到终端发送的补充提交申请数据后，可以发送给账管系统，以使账管系统可以再次审核补充提交申请数据，若审核通过，则可以计算给付权益，生成待遇支付详细信息发送给受托系统，受托系统可以根据待遇支付详细信息向托管系统发送待遇支付指令，由托管系统进行权益支付。由于业务处理流程增加了补充材料的节点，可以有效方便用户操作，提高业务处理效率，提高用户体验。
在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
本领域技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (10)

1.一种业务处理方法，其特征在于，包括：
接收账管系统发送的申请打回消息；
根据所述申请打回消息获取补充申请页面数据；
将所述补充申请页面数据发送给终端；
接收所述终端发送的补充提交申请数据；
将所述补充提交申请数据发送给所述账管系统。
2.根据权利要求1所述的方法，其特征在于，在接收账管系统发送的申请打回消息之前，所述方法还包括：
接收所述终端发送的待遇支付申请信息；
对所述待遇支付申请信息进行审核；
若审核通过，将所述待遇支付申请信息发送给所述账管系统。
3.根据权利要求1所述的方法，其特征在于，在接收所述终端发送的补充提交申请数据之后，所述方法还包括：
对所述补充提交申请数据进行审核；
所述将所述补充提交申请数据发送给所述账管系统，包括：
若审核通过，将所述补充提交申请数据发送给所述账管系统。
4.根据权利要求1所述的方法，其特征在于，若所述申请打回消息为全打回消息，所述根据所述申请打回消息获取补充申请页面数据，包括：
根据所述申请打回消息获取第一页面数据，所述第一页面数据用于展示第一页面，以使用户在第一页面补充全部受益人的相关信息。
5.根据权利要求4所述的方法，其特征在于，若所述申请打回消息为部分打回消息，所述根据所述申请打回消息获取补充申请页面数据，包括：
根据所述申请打回消息获取第二页面数据，所述第二页面数据用于展示第二页面，以使用户在第二页面补充账管系统审核未通过的受益人的相关信息。
6.根据权利要求5所述的方法，其特征在于，在接收所述终端发送的补充提交申请数据之后，所述方法还包括：
若所述补充提交数据仅包括被打回受益人的放弃支付证明，业务结束，则不执行将所述补充提交申请数据发送给所述账管系统的步骤；
若所述补充提交数据包括至少一个被打回受益人的待遇支付明细信息及其他被打回受益人的放弃支付证明，则将所述补充提交申请数据发送给所述账管系统。
7.根据权利要求1-6任一项所述的方法，其特征在于，所述方法还包括：
接收所述账管系统发送的待遇支付详细信息；
根据所述待遇支付详细信息向托管系统发送待遇支付指令，以使所述托管系统根据所述待遇支付指令进行权益支付处理；
接收所述托管系统返回的支付结果。
8.一种业务处理装置，其特征在于，包括：
第一接收模块，用于接收账管系统发送的申请打回消息；
处理模块，用于根据所述申请打回消息获取补充申请页面数据；
第一发送模块，用于将所述补充申请页面数据发送给终端；
第二接收模块，用于接收所述终端发送的补充提交申请数据；
第二发送模块，用于将所述补充提交申请数据发送给所述账管系统。
9.一种电子设备，其特征在于，包括：至少一个处理器和存储器；
所述存储器存储计算机执行指令；
所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如权利要求1-7任一项所述的方法。
10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如权利要求1-7任一项所述的方法。
CN201911067394.1A 2019-11-04 2019-11-04 业务处理方法、装置、设备及存储介质 Pending CN110796437A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911067394.1A CN110796437A (zh) 2019-11-04 2019-11-04 业务处理方法、装置、设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911067394.1A CN110796437A (zh) 2019-11-04 2019-11-04 业务处理方法、装置、设备及存储介质

Publications (1)

Publication Number Publication Date
CN110796437A true CN110796437A (zh) 2020-02-14

Family

ID=69442599

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911067394.1A Pending CN110796437A (zh) 2019-11-04 2019-11-04 业务处理方法、装置、设备及存储介质

Country Status (1)

Country Link
CN (1) CN110796437A (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8688479B1 (en) * 2008-05-29 2014-04-01 United Services Automobile Association (Usaa) Systems and methods for providing an annuity
CN108510397A (zh) * 2017-07-25 2018-09-07 平安科技（深圳）有限公司 年金管理系统、方法、服务器和存储介质
CN109427020A (zh) * 2017-08-21 2019-03-05 阿里巴巴集团控股有限公司 在线签证的处理方法及装置
CN109767324A (zh) * 2018-12-28 2019-05-17 上汽通用五菱汽车股份有限公司 客户端、服务器的车辆分期方法、客户端以及服务器

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8688479B1 (en) * 2008-05-29 2014-04-01 United Services Automobile Association (Usaa) Systems and methods for providing an annuity
CN108510397A (zh) * 2017-07-25 2018-09-07 平安科技（深圳）有限公司 年金管理系统、方法、服务器和存储介质
CN109427020A (zh) * 2017-08-21 2019-03-05 阿里巴巴集团控股有限公司 在线签证的处理方法及装置
CN109767324A (zh) * 2018-12-28 2019-05-17 上汽通用五菱汽车股份有限公司 客户端、服务器的车辆分期方法、客户端以及服务器

Similar Documents

Publication Publication Date Title
US20230129822A1 (en) Resource transfer system
JP6704985B2 (ja) デジタル資産仲介電子決済プラットフォーム
JP2022547130A (ja) ブロックチェーンベースの記録プロセスを提供するシステムおよび方法
US20140172679A1 (en) Systems And Methods Of An Online Secured Loan Manager
CN107016544B (zh) 跨实体的验证规则管理
US20160086177A1 (en) Smart Gross Management of Repairs and Exceptions for Payment Processing
US11568495B2 (en) Computer systems and software for self-executing code and distributed database
JP2023015223A (ja) 電子ブロックチェーンに組み込まれる取引の妥当性を確認するシステムと方法
US11430063B2 (en) Trading proposal arrangement, system and method
US20230274361A1 (en) Distributed ledger technology for asset-backed securities
US8478666B2 (en) System and method for processing data related to management of financial assets
WO2017021998A1 (ja) 電子稟議書の更新方法およびシステム
WO2014098796A1 (en) Systems and methods of an online secured loan manager
CN110796437A (zh) 业务处理方法、装置、设备及存储介质
CN111429248A (zh) 一种非实时保险业务的出单方法及装置
US20190213574A1 (en) Prepaid multinational program
CN111178826A (zh) 基于区块链的消费金融风险管理方法及云平台
US11615447B2 (en) Zero invoicing by replicated state
CN116645093A (zh) 银行跨境汇款处理方法、装置、设备及存储介质
CN113487436A (zh) 业务处理的方法、装置、电子设备和存储介质
CN117114786A (zh) 核心企业管理方法、系统、计算机设备及存储介质
CN116523448A (zh) 保险代理机构的保单手续费管理系统及方法
US20110225092A1 (en) Secure Transaction Execution
Rules Today’s Agenda

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
TA01 Transfer of patent application right

Effective date of registration: 20211109

Address after: Taikang Life Building, 156 fuxingmennei street, Xicheng District, Beijing 100031

Applicant after: TAIKANG INSURANCE GROUP Co.,Ltd.

Applicant after: TAIKANG PENSION INSURANCE Co.,Ltd.

Address before: Taikang Life Building, 156 fuxingmennei street, Xicheng District, Beijing 100031

Applicant before: TAIKANG INSURANCE GROUP Co.,Ltd.

TA01 Transfer of patent application right
RJ01 Rejection of invention patent application after publication

Application publication date: 20200214

RJ01 Rejection of invention patent application after publication