用于垫款支付的信息处理方法、装置、设备和介质与流程

1.本公开涉及人工智能技术领域，可用于金融科技领域，更具体地涉及一种用于处理代理财政支付业务中的垫款支付的信息处理方法、装置、设备、介质和程序产品。


背景技术：

2.代理财政支付业务可以包括垫款支付、垫款清算、退款和退库清算四个环节。其中，垫款支付环节，是指代理财政支付业务的机构(例如，银行)收到财政部门的支付指令后，可以先将内部账户自有资金垫款至零余额账户并向实际收款人付款。垫款清算环节，是指银行通过与清算方的资金清算，收回所垫付的款项，其中，清算方一般为指定单位。退款，是指银行向实际收款人付款未成功或收款人主动退款，导致该笔资金原路退回零余额账户，然而在此之前该笔资金已经经过了垫款清算，此时需要将该笔资金先暂时退回银行垫款内部账户，等待退库清算。退库清算，是指将退款环节中暂时退回给银行的资金，再退回给清算方的过程。
3.现有技术中，非电子化场景下，电子支付指令所依托的财政系统与银行系统未形成交互，电子指令与纸质指令双线传递，垫款支付过程需要经办人员人工核对财政下发的纸件支付指令和电子支付指令，来确认指令的真实性、完整性和准确性，然后经办人员手动输入垫款支付交易的信息，并经过远程授权等后台审核通过后才可以进行交易支付。
4.这个过程中，一方面垫款支付交易信息依赖人工核对及手工录入，，存在操作风险；另一方面，远程授权中审核的垫款交易信息、以及纸件支付指令的扫描影像都是由同一个经办人员提供，可能存在“一手清”、篡改指令等风险敞口。


技术实现要素：

5.鉴于上述问题，本公开实施例提供了提高垫款支付过程中的自动化程度以及准确率的用于处理代理财政支付业务中的垫款支付的信息处理方法、装置、设备、介质和程序产品。
6.本公开实施例的第一方面，提供了一种用于处理代理财政支付业务中的垫款支付的信息处理方法。所述方法包括：利用机器人流程自动化rpa系统从财政系统中查询经业务人员确认过的、且银行尚未进行实际账务处理的电子支付指令；对于查询到的第一电子支付指令，利用所述rpa系统按照预设的支付凭证信息模板从所述第一电子支付指令中提取数据，得到第一支付凭证信息；其中，所述第一电子支付指令为查询到的任意一个电子支付指令；以及基于所述第一支付凭证信息，对所述第一电子支付指令对应的垫款支付交易进行账务处理。
7.根据本公开的实施例，所述利用机器人流程自动化rpa系统从财政系统中查询经业务人员确认过的、且银行尚未进行实际账务处理的电子支付指令，包括控制所述rpa系统从浏览器界面中以所述财政系统的用户的身份登陆所述财政系统。
8.根据本公开的实施例，所述利用机器人流程自动化rpa系统从财政系统中查询经
业务人员确认过的、且银行尚未进行实际账务处理的电子支付指令包括：定时触发所述rpa系统以所述财政系统的用户的身份登陆所述财政系统；或者基于人工操作触发所述rpa系统以所述财政系统的用户的身份登陆所述财政系统。
9.根据本公开的实施例，所述利用机器人流程自动化rpa系统从财政系统中查询经业务人员确认过的、且银行尚未进行实际账务处理的电子支付指令还包括：通过对所述rpa系统的用户分配和/或业务流程的权限设置，限制所述rpa系统仅对具有权限的业务流程的电子支付指令进行查询。
10.根据本公开的实施例，所述利用所述rpa系统按照预设的支付凭证信息模板从所述第一电子支付指令中提取数据，得到第一支付凭证信息包括：利用所述rpa系统下载对应字段的数据，并匹配到所述支付凭证信息模板，形成excel数据表；以及提取所述excel数据表中各个字段的信息，得到所述第一支付凭证信息。
11.根据本公开的实施例，所述基于所述第一支付凭证信息，对所述第一电子支付指令对应的垫款支付交易进行账务处理，包括调用专用交易模块执行如下操作：向所述专用交易模块中导入所述第一支付凭证信息；按照预定的校验规则对所述第一支付凭证信息中的各个字段的值进行校验；在校验通过后，按照在所述专用交易模块中预先封装的账务处理流程，处理所述第一支付凭证信息对应的垫款支付交易，其中，所述账务处理流程中一个支付凭证信息能够触发两借两贷的操作。
12.根据本公开的实施例，所述在校验通过后，按照在所述专用交易中预先封装的账务处理流程，处理所述第一支付凭证信息对应的垫款支付交易包括：在校验通过后，等待并接收对所述第一电子支付指令对应的垫款支付交易的用户确认操作；以及响应于接收到所述用户确认操作，按照在所述专用交易模块中预先封装的账务处理流程，处理所述第一支付凭证信息对应的垫款支付交易。
13.根据本公开的实施例，所述专用交易模块中还封装有垫款内部账户的信息。其中，在校验通过后，按照在所述专用交易模块中预先封装的所述账务处理流程以及所述垫款内部账户的信息，处理所述第一支付凭证信息对应的垫款支付交易。
14.根据本公开的实施例，所述基于所述第一支付凭证信息，对所述第一电子支付指令对应的垫款支付交易进行账务处理，包括通过业务集中渠道对所述垫款支付交易进行账务处理，具体包括：获取至少一个影像数据，其中，每个影像数据为与所述财政系统中的电子支付指令核对一致的纸件支付指令的扫描数据；利用光学字符识别技术从每个影像数据中，按照所述支付凭证信息模板中的字段进行字段识别和切割，得到垫款交易信息；当第一垫款交易信息与所述第一支付凭证信息核对一致时，按照预定的校验规则对所述第一支付凭证信息中的各个字段的值进行校验，其中，所述第一垫款交易信息为从与所述第一电子支付指令对应的纸件支付指令的影像数据中识别得到的垫款交易信息；以及在校验通过后，对包含所述第一电子支付指令对应的垫款支付交易在内的交易进行集中账务处理。
15.根据本公开的实施例，所述基于所述第一支付凭证信息，对所述第一电子支付指令对应的垫款支付交易进行账务处理，还包括：在进行实际的资金流转之前，查询所述第一电子支付指令对应的垫款支付交易所涉及的财政单位账户的状态；以及在所述财政单位账户状态正常的情况下，再进行实际的资金流转。
16.根据本公开的实施例，所述基于所述第一支付凭证信息，对所述第一电子支付指
令对应的垫款支付交易进行账务处理，还包括：在进行实际的资金流转之前，查询所述第一电子支付指令对应的垫款支付交易的状态；仅当所述第一电子支付指令对应的垫款支付交易的状态为未支付时，允许进行账务处理。
17.根据本公开的实施例，所述基于所述第一支付凭证信息，对所述第一电子支付指令对应的垫款支付交易进行账务处理，还包括：在账务处理的同时，同步更新所述第一电子支付指令对应的垫款支付交易的状态。
18.根据本公开的实施例，在基于所述第一支付凭证信息，对所述第一电子支付指令对应的垫款支付交易进行账务处理之后，所述方法还包括：在进行包括所述第一电子支付指令对应的垫款交易的第一垫款清算账务处理时，生成第一垫款清算凭证记录。
19.根据本公开的实施例，在所述生成第一垫款清算凭证记录之后，所述方法还包括：若收到所述第一电子支付指令对应的垫款交易的退库清算指令时，在基于所述退库清算指令进行退库清算账务处理时，同步生成退库清算凭证记录。
20.本公开实施例的第二方面，提供了一种用于处理代理财政支付业务中的垫款支付的信息处理装置。所述装置包括rpa模块和账务处理模块。所述rpa模块包括机器人流程自动化rpa系统，用于利用所述机器人流程自动化rpa系统从财政系统中查询经业务人员确认过的、且银行尚未进行实际账务处理的电子支付指令；以及对于查询到的第一电子支付指令，利用所述rpa系统按照预设的支付凭证信息模板从所述第一电子支付指令中提取数据，得到第一支付凭证信息；其中，所述第一电子支付指令为查询到的任意一个电子支付指令。所述账务处理模块用于基于所述第一支付凭证信息，对所述第一电子支付指令对应的垫款支付交易进行账务处理。
21.根据本公开的实施例，所述账务处理模块包括专用交易模块。所述专用交易模块用于执行如下操作：导入所述第一支付凭证信息；按照预定的校验规则对所述第一支付凭证信息中的各个字段的值进行校验；在校验通过后，按照在所述专用交易模块中预先封装的账务处理流程，处理所述第一支付凭证信息对应的垫款支付交易，其中，所述账务处理流程中一个支付凭证信息能够触发两借两贷的操作。
22.根据本公开的实施例，所述账务处理模块包括业务集中模块。所述业务集中模块用于获取至少一个影像数据，其中，每个影像数据为与所述财政系统中的电子支付指令核对一致的纸件支付指令的扫描数据；利用光学字符识别技术从每个影像数据中，按照所述支付凭证信息模板中的字段进行字段识别和切割，得到垫款交易信息；当第一垫款交易信息与所述第一支付凭证信息核对一致时，按照预定的校验规则对所述第一支付凭证信息中的各个字段的值进行校验；其中，所述第一垫款交易信息为从与所述第一电子支付指令对应的纸件支付指令的影像数据中识别得到的垫款交易信息；以及在校验通过后，对包含所述第一电子支付指令对应的垫款支付交易在内的交易进行集中账务处理。
23.根据本公开的实施例，所述装置还包括记录生成模块。所述记录模块用于在进行包括所述第一电子支付指令对应的垫款交易的第一垫款清算账务处理时，生成第一垫款清算凭证记录，其中，所述第一垫款清算凭证记录用于记录所述第一垫款清算账务处理的业务背景信息。
24.根据本公开的实施例，所述记录生成模块用于当进行退库清算账务处理时，同步生成退库清算凭证记录，所述退款请求清算凭证记录用于记录所述退库清算账务处理的业
务背景信息。
25.本公开实施例的第三方面提供了一种电子设备，包括：一个或多个处理器和一个或多个存储器。所述一个或多个存储器用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得一个或多个处理器执行上述方法。
26.本公开实施例的第四方面还提供了一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时使处理器执行上述方法。
27.本公开实施例的第五方面还提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述方法。
附图说明
28.通过以下参照附图对本公开实施例的描述，本公开的上述内容以及其他目的、特征和优点将更为清楚，在附图中：
29.图1示意性示出了根据本公开实施例的代理财政支付业务的应用场景图；
30.图2示意性示出了根据本公开实施例的代理财政支付业务中的银行系统与财政系统的信息交互场景；
31.图3示意性示出了根据本公开一实施例的用于处理代理财政支付业务中的垫款支付的信息处理方法的系统架构；
32.图4示意性示出了根据本公开一实施例的用于处理代理财政支付业务中的垫款支付的信息处理方法的流程图；
33.图5～图7示意出了将rpa系统与财政系统对接的各种可实施方案；
34.图8示意出了根据本公开实施例的rpa系统的运行流程图；
35.图9示意性示出了根据本公开另一实施例的用于处理代理财政支付业务中的垫款支付的信息处理方法的流程图；
36.图10示意性示出了根据本公开实施例的方法中通过专用交易渠道进行账务处理的流程图；
37.图11示意性示出了根据本公开实施例的方法中通过业务集中渠道进行账务处理的流程图；
38.图12示意性示出了根据本公开另一实施例的方法中通过专用交易渠道和业务集中渠道进行账务处理中共有的部分操作流程；
39.图13示意性示出了根据本公开再一实施例的用于处理代理财政支付业务中的垫款支付的信息处理方法的流程图；
40.图14示意性示出了根据本公开一实施例的用于处理代理财政支付业务中的垫款支付的信息处理装置的框图；以及
41.图15示意性示出了适于实现根据本公开实施例的用于处理代理财政支付业务中的垫款支付的信息处理方法的电子设备的方框图。
具体实施方式
42.以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细
节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。
43.在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。
44.在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。
45.在使用类似于“a、b和c等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有a、b和c中至少一个的系统”应包括但不限于单独具有a、单独具有b、单独具有c、具有a和b、具有a和c、具有b和c、和/或具有a、b、c的系统等)。
46.在本文中，需要理解的是，说明书及附图中的任何元素数量均用于示例而非限制，以及任何命名(例如，第一电子支付指令、第一支付凭证信息)都仅用于区分，而不具有任何限制含义。
47.图1示意性示出了根据本公开实施例涉及的代理财政支付业务的应用场景图。
48.如图1所示，在应用场景100中，代理财政支付业务的交易对手方涉及财政、商业银行、清算方和实际收款人。
49.在应用场景100，代理财政支付业务的全生命周期环节包括垫款支付、垫款清算、退款和退库清算四个环节的资金流转。各环节的账务处理过程简述如下。
50.在垫款支付环节，商业银行收到某个财政单位或财政预算单位向实际收款人进行支付的支付指令后，审核支付指令，并在审核通过后严格依据指令先将内部账户自有资金垫款给该财政单位或财政预算单位的零余额账户，然后再由该财政单位或预算单位的零余额账户向实际收款人的账户进行支付，从而实现向实际收款人的财政支付。其中，在垫款支付环节的账务处理中，商业银行的会计分录为：
51.借：商业银行的垫款内部账户
52.贷：财政零余额账户或预算单位零余额账户
53.借：财政零余额账户或预算单位零余额账户
54.贷：实际收款人账户
55.其中，商业银行的垫款内部账户用于记录商业银行在垫款支付环节中垫款的明细。财政零余额账户或预算单位零余额账户指财政部门或预算单位经财政部门批准，在代理财政支付业务的银行开立的，用于办理财政集中支付的银行结算账户，受业务性质决定，财政单位一般并不会预先在该账户中存储金额。正常情况下财政零余额账户或预算单位零余额账户(简称“零余额账户”)的资金余额应当为零。根据垫款支付环节的会计分录，可以看到在垫款支付环节实际涉及了垫款交易和支付交易两步，即，涉及两借两贷操作。
56.在垫款清算环节，商业银行可以通过与清算方的资金清算，收回所垫付的款项。其中，在垫款清算环节的账务处理中，商业银行的会计分录为：
57.借：清算方账户
58.贷：商业银行的垫款内部账户
59.其中，清算方账户为清算方开设的用于代理财政支付清算的账户，包括且不限于财政在中央银行国库部门开设的国库存款账户(简称“国库单一账户”)、财政在代理财政支付的银行开设的预算外资金财政专户(以下简称“预算外资金专户”)等。在通过财政和银行的一系列额度审批手续后，可以通过该账户的资金来偿还银行垫付的财政款项。
60.在退款环节，商业银行向实际收款人跨行支付失败的退汇资金，或与财政、国库协商一致主动退回的款项等，应原路先退回给零余额账户。然而，如果该笔款项已经经过垫款清算，则该笔款项形成代理财政支付业务中的退款，暂时退回商业银行并要等待退库清算。其中，在退款环节的账务处理中，商业银行的会计分录为：
61.借：财政零余额账户或预算单位零余额账户
62.贷：商业银行的垫款内部账户
63.在退库清算环节，商业银行将退款环节中形成的一笔或多笔退款，退回给清算方。其中，在退库清算环节的账务处理中，商业银行的会计分录为：
64.借：商业银行的垫款内部账户
65.贷：清算方账户
66.由此可见，代理财政支付业务的全生命周期所包括的垫款支付、垫款清算、退款和退库清算四个环节，紧密联系，相互依赖。
67.图2示意性示出了根据本公开实施例的代理财政支付业务中的退款业务的信息交互场景。
68.如图2所示，根据本公开实施例，信息交互场景200可以分为两种运行模式：非电子化模式和电子化模式。
69.在非电子化模式下，信息交互场景200可以包括银行系统210和财政系统220，但不包括电子凭证库230。在非电子化模式下，财政系统220不与银行系统210联通。财政系统220下发的电子指令(包括电子支付指令、退库清算凭证等)依靠部署于互联网或布设在银行系统的独立专线等单线传输，同时财政单位向银行递送与电子指令对应的纸件指令。
70.在电子化模式下，信息交互场景200可以包括银行系统210、财政系统220以及电子凭证库230。银行系统210和财政系统220可以通过电子凭证库230交换电子指令。另外，财政单位仍可以向银行递送纸件指令，以便核对电子指令的真实性。
71.目前有的地区的财政系统与银行系统之间已实现电子化模式，有的地区的财政系统与银行系统之间尚使用非电子化模式。
72.相关技术中，非电子化模式下银行系统210在处理垫款支付等交易时，集中体现人工依赖度强的问题，主要表现在人工核对信息填写交易信息要素、后台审核无法获取源头财政电子指令等，其中，交易信息要素往往多达十余项。操作复杂且易出错、问题揭示主要依赖事后检查，事前及事中防范较为薄弱。
73.鉴于此，本公开实施例提供了一种用于处理代理财政支付业务的信息处理方法、装置、设备、介质和程序产品，通过引进机器人流程自动化rpa技术，在一定程度上提高了垫款支付环节的自动化程度。
74.根据本公开实施例的方法可以由银行系统210执行，具体包括：利用机器人流程自动化rpa系统从财政系统中查询经业务人员确认过的、且银行尚未进行实际账务处理的电
子支付指令；对于查询到的第一电子支付指令，利用所述rpa系统按照预设的支付凭证信息模板从所述第一电子支付指令中提取数据，得到第一支付凭证信息；其中，所述第一电子支付指令为查询到的任意一个电子支付指令；以及基于所述第一支付凭证信息，对所述第一电子支付指令对应的垫款支付交易进行账务处理。
75.根据本公开的另一些实施例，银行系统210在账务处理时还可以通过专用交易渠道或者业务集中渠道进行自动化或半自动化处理，其中，在处理过程中可以通过参数化配置等对电子支付指令中的各个字段的信息进行自动化校验。从而提高了垫款支付环节的信息校验的效率和准确性。
76.根据本公开的再一些实施例，银行系统210还可以在退款环节、或者退库清算环节记录业务背景信息，形成，实现垫款支付、垫款清算、退款、退库清算全流程业务信息流的关联和资金流闭环管理。
77.相应地，本公开实施例的用于处理代理财政支付业务的信息处理方法、装置、设备、介质和程序产品也可以设置于银行系统210中。
78.需要说明的是，本公开实施例确定的信息处理方法、装置、电子设备、介质和程序产品可用于金融领域，也可用于除金融领域之外的任意领域，本公开对应用领域不做限定。
79.图3示意性示出了根据本公开实施例的用于处理代理财政支付业务中的垫款支付的信息处理方法的系统架构。
80.如图3所示，该系统架构300可以包括银行系统310、银行系统终端机301以及财政系统320。其中，银行系统终端机301与银行系统310通信连接，例如银行系统终端机301可以通过银行内网连接到银行系统310。银行系统310可以通过在银行系统终端机301上的浏览器，登录财政系统320的网站，从而与财政系统320进行通信。
81.具体地，银行系统310可以包括rpa系统311。根据本公开的实施例，可以通过rpa系统311从银行系统终端机301中的浏览器上打开财政系统320的网站，从中查询需要进行垫款支付处理的电子支付指令，并按照预设的支付凭证信息模板爬取支付凭证信息。然后据此来生成垫款支付交易的交易信息。
82.银行系统310还可以包括地标系统312。地标系统312为专门用于处理财政代理集中支付业务的系统，可以用于依托业务背景设置参数、存储或生成各类财政凭证及报文、销账文件的编制和上送等。根据本开的实施例，rpa系统311从财政系统320爬取得到的支付凭证信息可以通过地标系统312中的参数化设置按照预定规则进行校验，以此来实现对财政系统310下发的电子支付凭证的自动化校验，既避免了人工校验的人力消耗，提高了校验效率，还能够使校验过程标准化，有助于提高校验的准确性。另外，rpa系统311从财政系统320爬取得到的支付凭证信息可以存储在地标系统312中，这样可以极大地方便银行系统310的指令全生命周期跟踪储存，尤其是对于非电子化模式。
83.银行系统310在进行账务处理时，可以通过调用专用交易渠道313或业务集中渠道314二者之一来实现垫款支付交易的流程控制。
84.其中，在专用交易渠道313下，银行系统310中预先开发并部署有针对垫款支付交易的专用交易模块。其中，该专用交易模块可以从地标系统312中导入其中存储的每一笔支付凭证信息。然后专用交易模块可以控制与支付凭证信息对应的账务处理流程，包括信息校验、财政单位账户状态的安全性校验、避免重复支付的校验、账户借贷操作的触发、支付
明细状态的调整和/或支付明细对应的业务背景信息的记录等。
85.在业务集中渠道314下，可以接收人工单个扫描或批量扫描的纸件支付指令的影像数据，然后通过影像数据切割和地标系统312中存储的支付凭证信息的核对，来确认各个支付指令的真实性。然后，在信息真实性校验通过后，可以将支付凭证信息上送后台进行业务集中处理，包括控制信息校验、财政单位账户状态的安全性校验、避免重复支付的校验、账户借贷操作的触发和/或支付明细状态的调整等。在业务集中渠道314下，银行柜台的工作人员可以仅通过单个扫描或批量扫描上传纸件支付指令的影像数据，后续的真实性核验、以及账务处理流程都可以借助于银行系统的后台管理系统进行处理。可以有效释放银行柜台的工作人员的压力。
86.银行系统310还包括主机系统315。主机系统315可以是银行系统310中用于存储账户信息、处理账户之间资金流动和/或进行会计分录记账的底层系统。
87.需要说明的是，系统架构300中银行系统310为前述银行系统210的一个具体实施例，其中rpa系统、地标系统312、专用交易渠道313、业务集中渠道314以及主机系统315中的任意一个可以拆封为更多部分，或者其中的任意多个也可以合并在一起实现。对此本公开不予限定。
88.以下将结合图3描述的系统架构，通过图4～图13对公开实施例的用于处理代理财政支付业务中的垫款支付的信息处理方法进行示例性描述。需要注意的是，图3所示系统架构仅为示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他架构、设备、系统、环境或场景。
89.图4示意性示出了根据本公开一实施例的用于处理代理财政支付业务中的垫款支付的信息处理方法的流程图。
90.如图4所示，根据该实施例的信息处理方法可以包括操作s410～操作s430。
91.首先在操作s410，利用机器人流程自动化rpa系统311从财政系统320中查询经业务人员确认过的、且银行尚未进行实际账务处理的电子支付指令。
92.在操作s410之前当银行收到财政单位送达的纸件支付指令时，需要人工登录财政系统320核对对应的电子支付指令的信息，核对一致后点击确认支付，该指令在财政系统320中就视为已支付(即为经过业务人员确认过的电子支付指令)。接下来，相关技术中需要银行业务人员人工录入垫款支付要素信息等，并进行远程授权审核等。而与此不同，本公开的实施例中会驱动rpa机器人从财政系统320获取支付信息，提高信息处理的自动化程度。
93.具体地，在操作s410中可以控制所述rpa系统311从浏览器界面中以所述财政系统320的用户的身份登陆所述财政系统320，从中查询显示已人工确认过的电子支付指令。在一些实施例中，可以设置查询的指令的产生时间，以此过滤出尚未处理的指令。在另一些实施例中，可以根据该电子支付指令的指令编号是否属于已处理过的指令，来筛选出银行尚未进行实际账务处理的电子支付指令。
94.根据本公开的实施例，可以定时触发所述rpa系统311以所述财政系统320的用户的身份登陆所述财政系统320。或者基于人工操作触发所述rpa系统311以所述财政系统320的用户的身份登陆所述财政系统320。
95.根据本公开的另一些实施例中，还可以通过对所述rpa系统311的用户分配和/或业务流程的权限设置，限制所述rpa系统311仅对具有权限的业务流程的电子支付指令进行
查询。
96.然后在操作s420，对于查询到的第一电子支付指令，利用所述rpa系统311按照预设的支付凭证信息模板从所述第一电子支付指令中提取数据，得到第一支付凭证信息。其中，所述第一电子支付指令为查询到的任意一个电子支付指令。在本文中使用第一电子支付指令是为了描述清楚对于单个指令的处理过程。在本文中，操作s410中查询到的每个电子支付指令都可以被视为第一电子支付指令。
97.具体地，操作s420中例如可以利用所述rpa系统311在银行系统终端机301本地下载对应字段的数据，并匹配到所述支付凭证信息模板，形成excel数据表。然后在通过地标系统312提取所述excel数据表中各个字段的信息，得到所述第一支付凭证信息。例如，将excel表，导入地标系统312对应的“支付凭证信息管理”菜单，形成支付凭证信息。
98.接下来在操作s430，基于所述第一支付凭证信息，对所述第一电子支付指令对应的垫款支付交易进行账务处理。
99.从而本公开的实施例，通过引进机器人流程自动化rpa技术，可以减少人工从财政系统320中查询电子支付指令以及填写交易要素信息，在一定程度上提高了垫款支付环节的自动化程度。
100.而且，通过rpa系统311爬取到支付凭证信息，可以形成银行系统310的凭证信息存储，尤其是在非电子化模式下，有利于银行对代理财政支付业务中的指令的全生命周期管理。rpa系统311可以形成财政系统与银行系统的对接通道，实现了财政系统的支付指令信息的自动获取和匹配，避免了纸质凭证被篡改、重复记账等风险，提高了支付业务的真实性、准确性。图5～图7示意出了将rpa系统与财政系统对接的各种可实施方案。
101.参考图5～图7，开发环境搭建形式中，考虑测试环境的系统一般要比生产环境优越，且测试环境中的系统是未来会投入的系统，而且测试环境中出现的问题也容易被矫正处理，因此优先争取rpa测试环境与财政系统320测试环境相连通(如图5所示)；其次考虑以作为开发机器连接财政系统320生产环境，打通办公环境端机与rpa生产环境防火墙(如图6所示)；最次考虑以办公环境端机作为开发机器连接财政系统320生产环境，在办公环境端机安装rpa单机环境(如图7所示)，但这需要rpa系统厂家授权安装，并且要恢复生产公共数据到单机版。根据本公开的实施例，rpa系统的安装和运行，对于财政系统而言，除了要求开放与银行系统之间的防火墙外，可以不作其他同步开发改动，从而可以极大方便与财政系统的推介，便于应用推广。rpa系统311与财政系统320的对接规则说明如下。rpa系统311仅可以进行信息查询、只读类的研发，原则上rpa系统311使用财政系统320的用户，只能是“有且仅有查询权限”的用户。执行内容仅为财政系统320中已完成“确认支付”操作的指令。执行方式可以包括查询、数据下载、匹配至模板、数据导入等。执行条件可以包括定时执行、应急人工触发执行。可以支持场景管理员手工登录控制器，选定指定场景后触发rpa系统311实时启动。
102.银行系统中可以设置pra管理平台。通过该管理平台，在使用rpa系统311与财政系统320对接时，可以定期对rpa系统311的用户密码自动更新；可以绑定财政系统320、用户号码、用户密码、密码更换周期等；场景绑定用户后，用户密码可以随机生成，定期更改，并加密存储；解除绑定后续不再对该用户密码进行管理。
103.另外，pra管理平台可以统一为rpa系统生成统一认证、主机系统专用用户号，供
rpa系统311登录地标系统312使用。
104.rpa系统311登录财政系统320，可以通过定时触发执行或者应急人工触发执行。支持通过指定业务流程进行限定启动，即可以通过对rpa系统311的用户分配和/或指定业务流程的权限设置，对可启动的业务流程进行隔离。
105.rpa系统311可以导出财政系统320中状态为已人工确认的电子支付指令。其中，财政系统320中已人工确认的指令，意味着银行和财政已经就该支付指令的真实性，在财政系统320一端达成一致确认意见。rpa系统311可以选取对应字段加工套入“支付凭证信息模板”excel表，然后导入地标系统312对应辖属范围的“支付凭证信息管理”菜单，凭证状态为(主机)“未支付”(即，银行系统尚未进行实际账务处理)。
106.其中，在该支付凭证信息模板中，其中可以包括“凭证编号”、“业务年度”、“凭证类型(直接支付、授权支付)”、“辖属区域信息”“付款人账号”、“付款人名称”、“用途”、“资金性质”、“凭证日期”、“金额”、“指令来源”等字段。渠道来源标签强制赋值为“rpa”。以“年度”“凭证类型”“凭证编号”“凭证状态”作为关键字，仅支持对应于主机系统中的状态“未支付”指令，随rpa爬回覆盖更新。
107.图8示意出了根据本公开实施例的rpa系统的运行流程图。
108.如图8所示，可以在rpa系统311中对于每个独立的流程步骤进行脚本设计，通过托拉拽控件的方式或者脚本代码编写的方式，可以使rpa机器人抓取财政系统320上的元素字段信息，并模拟用户日常手工操作，如鼠标点击、键盘输入、复制\粘贴等，完成自动执行某一个特定的原子流程。脚本用的技术包括按照软件接口方式、基于窗口句柄方式和浏览器操作，来实现操作流程的自动化。
109.具体地，可以通过rpa系统311将财政系统320中的电子指令爬回地标系统312储存。
110.主要流程包括：a)业务人员收到纸件指令后在财政系统320确认电子指令状态；b)rpa机器人定时启动打开浏览器进入财政系统320的网站，输入用户和密码信息登陆；c.根据预设的查询条件，包括辖属区域信息、查询日期、支付状态等条件，在财政系统320功能页面查询抓取或导出确认指令；d.转换数据填写导入模板；e.登陆地标系统312导入支付凭证数据。
111.具体地，在垫款支付环节rpa系统311的运行流程包括：1)业务人员收到纸件支付指令后在财政系统320确认电子支付指令的状态；
112.2)rpa机器人从浏览器登陆财政系统320；3)在财政系统320功能页面查询抓取或导出已人工确认的电子支付指令；4)转换数据填写导入模板；5)登陆地标系统312导入支付凭证数据，生成支付凭证信息。
113.或者，在垫款清算流程中rpa系统311的运行流程包括：：1)业务人员在财政系统320打印清算凭证；2)rpa机器人登陆财政系统320；3)在财政系统320清算功能页面中查询抓取或导出经过人工确认的电子支付指令；4)转换数据填写导入模板；5)登陆地标系统312导入清算凭证数据。
114.可见，本公开实施例的方法可以打通信息壁垒，通过人机交互替代人工完成跨系统数据自动抓取、信息回填、智能校验，完成各个系统的数据共享，在保障指令真实性、准确性的同时大幅度提升支付效率。图9示意性示出了根据本公开另一实施例的用于处理代理
财政支付业务中的垫款支付的信息处理方法的流程图。
115.如图9所示，根据本公开实施例的该信息处理包括操作s410、操作s420、操作s430a或操作s430b。其中，操作s430a和操作s430b提供了操作s430中账务处理的两种不同渠道。
116.在操作s410，利用机器人流程自动化rpa系统311从财政系统320中查询经业务人员确认过的、且银行尚未进行实际账务处理的电子支付指令。
117.在操作s420，对于查询到的第一电子支付指令，利用所述rpa系统311按照预设的支付凭证信息模板从所述第一电子支付指令中提取数据，得到第一支付凭证信息；其中，所述第一电子支付指令为查询到的任意一个电子支付指令。
118.该实施例中，操作s410和操作s420与上文内容一致，此处不再赘述。
119.接下来可以通过操作s430a或操作s430b两种不同的渠道来实现账务处理。
120.具体地，在操作s430a，通过专用交易渠道313对第一电子支付指令对应的垫款交易进行账务处理。其中，在专用交易渠道313中可以开发有专用交易模块，是专门针对代理财政支付业务中的垫款支付交易开发的用于控制账务处理流程的程序模块。该专用交易模块中可以封装有利用一个支付凭证信息来触发两借两贷的操作的账务处理流程等，从而避免垫款和支付两步操作的分离。
121.在操作s430b，通过业务集中渠道314对对所述第一电子支付指令对应的垫款支付交易进行账务处理。业务集中渠道314可以进行垫款支付交易的批量处理，并且将前端柜员与后端的账务处理分离，有助于缓解前端柜员的业务压力。
122.操作s430a或操作s430b通过两种不同的渠道，均可以提供对垫款支付交易的信息校验，全自动或半自动替代人工触发主机执行资金流转和会计分录记账账务处理等。在实际使用中，可以根据需要选择专用渠道或者业务集中渠道314中二者之一对该垫款支付交易进行处理。该两种渠道各自的具体实现过程可以参考下午图9和图10的相关描述。
123.图10示意性示出了根据本公开实施例的方法中操作s430a通过专用交易渠道进行账务处理的流程图。
124.如图10所示，根据该实施例操作s430a可以包括操作s1001～操作s1003。
125.在操作s1001，向专用交易模块导入所述第一支付凭证信息。
126.在操作s1002，按照预定的校验规则对所述第一支付凭证信息中的各个字段的值进行校验。例如，专用交易模块可以调用地标系统312对述第一支付凭证信息中的各个字段的值进行校验。
127.在操作s1003，在校验通过后，按照在所述专用交易模块中预先封装的账务处理流程，处理所述第一支付凭证信息对应的垫款支付交易，其中，所述账务处理流程中一个支付凭证信息能够触发两借两贷的操作。
128.在一些实施例中，所述专用交易模块中还封装有垫款内部账户的信息。其中，在校验通过后，按照在所述专用交易模块中预先封装的所述账务处理流程以及所述垫款内部账户的信息，处理所述第一支付凭证信息对应的垫款支付交易。这样无需人工录入银行的垫款内部账户信息，避免人工手动录入账号的麻烦和出错。
129.在一些实施例中，在校验通过后，可以先等待并接收对所述第一电子支付指令对应的垫款支付交易的用户确认操作，然后响应于接收到所述用户确认操作，按照在所述专用交易模块中预先封装的账务处理流程，处理所述第一支付凭证信息对应的垫款支付交
易。例如，在校验通过后，可以将“金额”“收款人账号”设计为一录一校，由人工比照纸质支付指令录入，点击确认后与地标系统312内对应字段的值校验一致，则允许记账。以此方式可以强化经办人根据支付指令向收款人支付的概念。
130.根据本公开的实施例，可以预先开发专用交易模块来控制垫款支付的账务处理流程。以下结合系统架构300，对该专用交易模块的一种实现方式进行示例性描述。
131.具体地，例如，在该专用交易模块中，可以设置以“辖属区域信息”、“年度”、“凭证类型”、“凭证编号”、“收款人账号”等作为关键字段在交易首屏录入，然后逐笔调用地标系统312中存储的支付凭证信息(即，第一支付凭证信息)并可以对收款人、金额等详细支付指令信息通过人工确认补充，仅对于主机系统中状态为“未支付”的指令可编辑。
132.可以预先在地标系统312中参数化定义以下a～d所描述的内容用于操作s1002中的校验。
133.a.参数化定义财政单位的信息、以及财政单位与银行的绑定信息。系统判断支付指令中关于财政单位的名称、属性或级别等字段是否与在银行中设置的预设值一致，以此来验证该笔支付指令的业务是否属于银行的业务。以此保证银行系统使用专用交易模块来调用自己职权范围内的支付指令。
134.b.参数化定义收款人账户的辖属区域信息。地标系统312判断支付指令中“付款人账号”“付款人名称”是否与主机系统中的开户信息一致，是否已参数化定义与银行有绑定关系的财政单位的信息。以此保证银行系统使用专用交易模块仅能调用与自己具有绑定关系的财政单位下发的支付指令。
135.c.参数化定义垫款内部账户。可以使用专用交易模块通过一笔操作同时执行两借两贷。其中，垫款内部账户参数化封装，无需柜面手工录入。
136.d.参数化定义服务时间。可以判断支付指令确认时间是否在预定义的服务时间(例如，起始日期格式为yyyy
‑
mm
‑
dd hh：mm：ss，一般时间可以设定在工作日银行营业后至下午，结束时间早于每日的清算时间)内，超时则记账失败。
137.经过以上a～d的信息校验通过后，可以将“付款人账户”“付款人名称”“收款人名称”“摘要”等十余个字段均直接识读rpa爬回的原指令信息展现于专用交易模块中交易界面的第二页，无需人工核对。
138.此外，在专用交易模块中还可以对“金额”“收款人账号”设计一录一校，由人工比照纸质指令录入，点击确认后与地标系统312内字段值校验则一致允许记账，强化经办人员支付指令已向收款人支付概念。
139.图11示意性示出了根据本公开实施例的方法中操作s430b通过业务集中渠道进行账务处理的流程图。
140.如图11所示，根据该实施例操作s430可以包括操作s1101～操作s1104。
141.在操作s1101，获取至少一个影像数据，其中，每个影像数据为与所述财政系统320中的电子支付指令核对一致的纸件支付指令的扫描数据。
142.在操作s1102，利用光学字符ocr识别技术从每个影像数据中，按照所述支付凭证信息模板中的字段进行字段识别和切割，得到垫款交易信息。
143.在操作s1103，当第一垫款交易信息与所述第一支付凭证信息核对一致时，按照预定的校验规则对所述第一支付凭证信息中的各个字段的值进行校验。其中，所述第一垫款
交易信息为从与所述第一电子支付指令对应的纸件支付指令的影像数据中识别得到的垫款交易信息。具体地校验过程与操作s1002类似，可以调用地标系统312对支付凭证信息中的各个字段进行校验，具体可以参考前述内容。
144.在操作s1104，在校验通过后，对包含所述第一电子支付指令对应的垫款支付交易在内的，按照所述校验规则校验通过的垫款支付交易进行集中账务处理。
145.例如，银行工作人员可以按照“业务年度”“辖属区域信息”“资金性质”“支付方式(直接支付、授权支付)”等维度，将纸件支付指令分批扫描影像并上传至银行系统后台的集约运营平台。这个过程中，支持单笔扫描及批量扫描。然后通过对支付凭证版式预定义及ocr识别技术，切割定义字段并上送后台补录信息、并通过审核岗核对，核对一致后提交地标系统312进行校验。校验通过后可以通过银行系统后台进行批量账务处理。
146.根据本公开的实施例，无论是专用交易渠道313，还是业务集中渠道314，在垫款支付的账务处理中，通过rpa+场景驱动校验，可以有效保障垫款支付环节指令来源真实有效。
147.图12示意性示出了根据本公开另一实施例的方法中通过专用交易渠道和业务集中渠道进行账务处理中共有的部分操作流程。
148.如图12所示，参阅图9～图11，无论是通过操作s430a中专用交易渠道处理账务，还是通过操作s430b中业务集中渠道处理账务，都可以包括操作s1201～操作s1204。
149.具体地，在在触发主机系统进行最终的资金划转和会计分录记账之前，上述两种渠道中都可以通过操作s1201或操作s1202中的至少之一进行账户状态安全性校验。
150.在操作s1201，在进行实际的资金流转之前，查询所述第一电子支付指令对应的垫款支付交易所涉及的财政单位账户的状态。若否，则结束该笔交易。若是，则继续该笔交易。从而，仅在所述财政单位账户状态正常的情况下，进行实际的资金流转。
151.具体地，可以调用地标系统312来校验财政单位账户的状态，状态异常的不能完成记账，避免垫款后该账户只收不付，待法院诉讼完成后才能收回垫款(最长达半年)。以此方式，可以提前预判财政单位账户的状态，确保垫款支付的正常进行。
152.另外在操作s1202，在进行实际的资金流转之前，查询所述第一电子支付指令对应的垫款支付交易的状态是否为未支付。若否，则结束该笔交易。若是，则继续该笔交易。从而，仅当所述第一电子支付指令对应的垫款支付交易的状态为未支付时，允许进行账务处理。
153.操作s1202的目的是对垫款支付交易的查重校验，进一步避免因为账务处理时间差，导致的重复处理。例如，在操作s410中爬取某个指令时该指令对应的垫款支付交易在主机系统中尚未处理，然而在触发主机系统进行资金划转操作之前，这段时间内该指令对应的垫款支付交易已经被处理了，那么通过操作s1202的重复校验就可以踢出掉这种情况。
154.在进行操作s1202的重复校验时，可以调用地标系统312，以“辖属区域信息”、“年度”、“凭证类型”、“凭证编号”查询地标系统312内的支付凭证信息的状态，仅当对应于主机系统的状态为“未支付”时允许记账，“支付处理中”“支付成功”或“支付失败”不允许记账。
155.账户状态安全性校验中可以同时设置操作s1201和操作s1202的校验操作，也可以仅设置操作s1201和操作s1202其中之一。具体根据实际需要来确定。
156.继续参考图12，当账户状态安全性校验通过后，可以在操作s1203，将第一支付凭证信息上送主机系统记账，包括资金划转以及会计分录记录等。
157.接下来还可以在操作s1204，在账务处理的同时，同步更新所述第一电子支付指令对应的垫款支付交易的状态。例如，更新地标系统312中的垫款支付交易的状态。
158.校验通过后上送主机系统记账，实现垫款及支付两借两贷会计分录记账，防范手工记账脱节。同时更新主机系统中支付状态为“支付处理中”“支付成功”或“支付失败”，便于银行查询和追溯所有支付状态下的汇总、明细支付指令清单。
159.图13示意性示出了根据本公开再一实施例的用于处理代理财政支付业务中的垫款支付的信息处理方法的流程图。
160.如图13所示，根据该实施例的信息处理方法除了操作s410～操作s430以外，还可以包括操作s1340和/或操作s1350。其中，操作s410～操作s430可以参考上文相关描述，此处不再赘述。
161.在操作s1340，在进行包括所述第一电子支付指令对应的垫款交易的第一垫款清算账务处理时，生成第一垫款清算凭证记录，其中，所述第一垫款清算凭证记录用于记录所述第一垫款清算账务处理的业务背景信息。
162.清算方账户信息在地标系统312中可以按照“辖属区域信息+资金性质+凭证类型(退库清算凭证/垫款支付清算凭证)+支付方式(授权支付/直接支付)”参数化设置，银行账户信息在地标系统312中可以按照“辖属区域信息+业务类型”来设置。
163.在非电子化模使下，经办人员可以登录财政系统320生成清算凭证，根据“辖属区域信息+资金性质+凭证类型(退库清算凭证/垫款支付清算凭证)+支付方式”调用借贷方账户记账信息，信息灰显的部分不允许经办人员修改，经办人员仅需录入金额及附言即可确认记账。
164.通过平台或专用交易场景驱动实现的垫款清算，同步在地标系统312生成一笔清算凭证记录，支持查询及追溯。通过嵌套地标系统参数，清算方账户为银行本行场景下，通过封闭借贷方账户控制资金流向。对于系统内垫款支付清算，即银行同时作为垫款方，又作为清算方的开户行的清算，可以开发专用交易实现发报联动记账。
165.在操作s1350，若收到所述第一电子支付指令对应的垫款交易的退库清算指令时，在基于所述退库清算指令进行退库清算账务处理时，同步生成退库清算凭证记录。清算方账户信息在地标系统312中可以按照“辖属区域信息+资金性质+凭证类型(退库清算凭证/垫款支付清算凭证)+支付方式(授权支付/直接支付)”进行参数化设置，银行账户信息在地标系统312中可以按照“辖属区域信息+业务类型”设置。
166.在电子化模式下，退库清算凭证由地标系统312生成，一个退库清算凭证可以包含系统中该辖属区域内的各资金性质、支付方式下状态为退款成功未退库清算的所有电子指令。点击确认发送，系统依托电子凭证库中退库清算凭证生成逻辑，自动生成退库发报报文，同时联动借记垫款内部账户，依据“辖属区域信息+资金性质+凭证类型(退库清算凭证/垫款支付清算凭证)+支付方式(授权支付/直接支付)”维度查找地标系统312内对应清算方账户信息，主动将退划资金划转清算方账户。
167.在非电子化模式下，退库清算凭证由财政系统320生成，包含系统中该区域各资金性质、支付方式下状态为退款成功未退库清算的所有电子指令。经办人员核对垫款内部账户中应退余额，在财政系统320内办理退库申请，，依据“辖属区域信息+资金性质+凭证类型(退库清算凭证/垫款支付清算凭证)+支付方式(授权支付/直接支付)”维度查找地标系统
312内对应清算方账户信息。信息灰显则不允许前台经办人员修改，经办人员仅需录入金额及附言即可确认记账。
168.平台或专用交易场景驱动实现的退库清算，同步在地标系统312生成一笔清算凭证记录，支持查询及追溯。
169.根据本公开实施例，退库清算时可以系统硬控退库发报报文类型。电子化模式下可以实现退库清算平台发报联动记账，精简操作环节；全模式通过嵌套地标系统参数，封闭借贷方账户控制资金流向。本公开的实施例，针对代理财政支付业务中存在的系统断点、管理难点和服务痛点问题，依托rpa机器人流程自动化、支付环节财政单位账户状态预判、指令全生命周期跟踪储存等手段，实现垫款支付、垫款清算、退款、退库清算全流程业务信息流和资金流闭环管理，促进财政、清算方、银行和实际收款人四方资金流转效率提升，有效保障代理财政支付业务中各方的资金安全。
170.基于上述用于处理代理财政支付业务中的垫款支付的信息处理方法，本公开还提供了一种用于处理代理财政支付业务中的垫款支付的信息处理装置。以下将结合图14对该装置进行详细描述。
171.图14示意性示出了根据本公开实施例的用于处理代理财政支付业务中的垫款支付的信息处理装置1400的框图。
172.如图14所示，根据本公开的实施例，该装置1400可以包括rpa模块1410和账务处理模块1420。另外，根据本公开的再一些实施例，该装置1200还可以进一步包括记录生成模块1430。该装置1400可以是银行系统210的一种具体实施例，可以用于实现参考图4～图12所描述的方法。
173.所述rpa模块1410包括机器人流程自动化rpa系统，例如可以执行操作s410和操作s420，用于利用机器人流程自动化rpa系统从财政系统320中查询经业务人员确认过的、且银行尚未进行实际账务处理的电子支付指令，以及对于查询到的第一电子支付指令，利用所述rpa系统按照预设的支付凭证信息模板从所述第一电子支付指令中提取数据，得到第一支付凭证信息。其中，所述第一电子支付指令为查询到的任意一个电子支付指令。
174.所述账务处理模块1420例如可以执行操作s430，用于基于所述第一支付凭证信息，对所述第一电子支付指令对应的垫款支付交易进行账务处理。
175.所述记录模块1430例如可以执行操作s1240，用于在进行包括所述第一电子支付指令对应的垫款交易的第一垫款清算账务处理时，生成第一垫款清算凭证记录，其中，所述第一垫款清算凭证记录用于记录所述第一垫款清算账务处理的业务背景信息。
176.所述记录生成模块例如还可以执行操作s1250，用于当进行退库清算账务处理时，同步生成退库清算凭证记录，所述退款请求清算凭证记录用于记录所述退库清算账务处理的业务背景信息。
177.继续参考图14，根据本公开的另一些实施例，账务处理模块1420可以进一步包括专用交易模块1421和/或业务集中模块1422。
178.所述专用交易模块1421例如可以执行操作s430a，用于：导入所述第一支付凭证信息；按照预定的校验规则对所述第一支付凭证信息中的各个字段的值进行校验；在校验通过后，按照在所述专用交易模块中预先封装的账务处理流程，处理所述第一支付凭证信息对应的垫款支付交易，其中，所述账务处理流程中一个支付凭证信息能够触发两借两贷的
操作。
179.所述业务集中模块1422例如可以执行操作s430b，用于通过业务集中渠道对第一电子支付指令对应的垫款支付交易进行账务处理。具体包括：获取至少一个影像数据，其中，每个影像数据为与所述财政系统中的电子支付指令核对一致的纸件支付指令的扫描数据；利用光学字符识别技术从每个影像数据中，按照所述支付凭证信息模板中的字段进行字段识别和切割，得到垫款交易信息；当第一垫款交易信息与所述第一支付凭证信息核对一致时，按照预定的校验规则对所述第一支付凭证信息中的各个字段的值进行校验；其中，所述第一垫款交易信息为从与所述第一电子支付指令对应的纸件支付指令的影像数据中识别得到的垫款交易信息；以及在校验通过后，对包含所述第一电子支付指令对应的垫款支付交易在内的交易进行集中账务处理。
180.根据本公开的实施例，rpa模块1410、账务处理模块1420、记录生成模块1430、专用交易模块1421和业务集中模块1422中的任意多个模块可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。根据本公开的实施例，rpa模块1410、账务处理模块1420、记录生成模块1430、专用交易模块1421和业务集中模块1422中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(fpga)、可编程逻辑阵列(pla)、片上系统、基板上的系统、封装上的系统、专用集成电路(asic)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，rpa模块1410、账务处理模块1420、记录生成模块1430、专用交易模块1421和业务集中模块1422中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。
181.图15示意性示出了适于实现根据本公开实施例的用于处理代理财政支付业务中的垫款支付的信息处理方法的电子设备1500的方框图。该电子设备1500可以是银行系统210的一个具体实施例。
182.如图15所示，根据本公开实施例的电子设备1500包括处理器1501，其可以根据存储在只读存储器(rom)1502中的程序或者从存储部分1508加载到随机访问存储器(ram)1503中的程序而执行各种适当的动作和处理。处理器1501例如可以包括通用微处理器(例如cpu)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(asic))等等。处理器1501还可以包括用于缓存用途的板载存储器。处理器1501可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。
183.在ram 1503中，存储有电子设备1500操作所需的各种程序和数据。处理器1501、rom 1502以及ram 1503通过总线1504彼此相连。处理器1501通过执行rom 1502和/或ram 1503中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除rom 1502和ram 1503以外的一个或多个存储器中。处理器1501也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。
184.根据本公开的实施例，电子设备1500还可以包括输入/输出(i/o)接口1505，输入/输出(i/o)接口1505也连接至总线1504。电子设备1500还可以包括连接至i/o接口1505的以下部件中的一项或多项：包括键盘、鼠标等的输入部分1506；包括诸如阴极射线管(crt)、液
晶显示器(lcd)等以及扬声器等的输出部分1507；包括硬盘等的存储部分1508；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分1509。通信部分1509经由诸如因特网的网络执行通信处理。驱动器1510也根据需要连接至i/o接口1505。可拆卸介质1511，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1510上，以便于从其上读出的计算机程序根据需要被安装入存储部分1508。
185.本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。
186.根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、便携式紧凑磁盘只读存储器(cd
‑
rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的rom 1502和/或ram 1503和/或rom 1502和ram 1503以外的一个或多个存储器。
187.本公开的实施例还包括一种计算机程序产品，其包括计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。当计算机程序产品在计算机系统中运行时，该程序代码用于使计算机系统实现本公开实施例所提供的方法。
188.在该计算机程序被处理器1501执行时执行本公开实施例的系统/装置中限定的上述功能。根据本公开的实施例，上文描述的系统、装置、模块、单元等可以通过计算机程序模块来实现。
189.在一种实施例中，该计算机程序可以依托于光存储器件、磁存储器件等有形存储介质。在另一种实施例中，该计算机程序也可以在网络介质上以信号的形式进行传输、分发，并通过通信部分1509被下载和安装，和/或从可拆卸介质1511被安装。该计算机程序包含的程序代码可以用任何适当的网络介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。
190.在这样的实施例中，该计算机程序可以通过通信部分1509从网络上被下载和安装，和/或从可拆卸介质1511被安装。在该计算机程序被处理器1501执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。
191.根据本公开的实施例，可以以一种或多种程序设计语言的任意组合来编写用于执行本公开实施例提供的计算机程序的程序代码，具体地，可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。程序设计语言包括但不限于诸如java，c++，python，“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(lan)或广域网(wan)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。
192.附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
193.本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合或/或结合，即使这样的组合或结合没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。
194.以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。