1.本发明属于计算机信息处理技术领域，尤其涉及一种用于电力系统的付款订单信息生成方法及系统。
背景技术：
2.本部分的陈述仅仅是提供了与本发明相关的背景技术信息，不必然构成在先技术。
3.目前电力系统付款订单由各单位业务部门在erp系统发起，财务部门审核后进行支付。近年来，对资金支付的管控力度逐步提升，9游会的支付方式需要由市县直接支付转变为省级集中支付。为达到资金集约化的目的，需要对现有系统流程进行调整，现有系统存在以下不足，主要包括：
4.公司前端业务系统在项目立项环节至采购环节中，未要求项目与采购订单进行一对一匹配，在后续进行到付款环节时，若一个采购订单下挂接两个及以上项目时，会存在以下两种问题：
5.(1)将一个资金支付申请表的金额，拆分成多条付款订单进行支付时，将导致付款的信息与资金支付申请表的信息不一致。
6.(2)若按照两个项目拆分付款，但穿透查询发现，其中一个项目还未挂账，存在未挂账先付款的风险。
7.以上现有情况影响资金安全，并对财务部门审核造成困难。
8.另外，业务部门在提报付款订单时，需将纸质版合同扫描成pdf上传、财务部门在审核付款订单时需逐个点击附件进行查看，对关键信息进行人工比对，存在的问题是：重复劳动、效率低下且可能存在误差。
9.还有，业务部门在erp系统创建付款订单时，需汇集获取前端各业务阶段信息，根据付款订单提报(预付款、进度款、验收款、质保款)等不同阶段，调取不同业务数据，生成相应阶段的付款订单，便于后续审核验证。由此，现有系统存在问题是：由于项目类型、采购订单类型不同，erp业务数据来源于不同的业务系统，且数据信息缺失较多。财务部门无法直接查看各前端业务系统，对信息准确性、真实性审核无法确认。
10.最后，截至目前使用内外部账户的供应商主数据平台仅能维护一个基本账户和三个农民工工资账户。存在问题是：为适应不同业务使用内外部账户的需要，如招投标业务要求使用外部银行账户，内部结算要用内部账户，同一供应商的基本户被基层单位反复修改，影响结算效率。
技术实现要素：
11.为克服上述现有技术的不足，本发明提供了一种用于电力系统的付款订单信息生成方法，达到资金支付事前校验、合规管控的效果。
12.为实现上述目的，本发明的一个或多个实施例提供了如下技术方案：
13.第一方面，公开了一种用于电力系统的付款订单信息生成方法，包括：
14.接收立项信息，并验证强控字段，若不满足强控规则，则进行预警，提示修改，若满足强控规则，则保存；
15.接收采购申请信息，根据采购申请的类型，验证强控字段，将采购信息进行保存；
16.基于立项信息及采购申请信息提取关键信息，完成合同签订并保存；
17.将服务确认环节所需信息进行保存；
18.将发票校验环节所需信息进行保存；
19.预置付款订单信息生成所需各强控规则，并基于预置的规则校验所保存的信息是否完整，若存在缺失则提供集成页面供用户进行补录，得到业务环节强控信息；
20.集成业务环节强控信息，根据提报付款订单的类型，调取相应阶段信息合并生成付款订单，进行数据展示，生成付款订单。
21.作为进一步的技术方案，所述接收立项信息并验证强控字段时，根据项目不同类型，通过esb技术集成各项目立项系统，在立项阶段验证强控字段，包括开工日期、批复文件、概算金额。
22.作为进一步的技术方案，立项信息保存之前，若历史数据已流转至后续业务，则在提报付款订单时要求补录项目信息。
23.作为进一步的技术方案，采购申请信息保存之前，若历史数据已流转至后续业务，则在提报付款订单时要求补录项目信息。
24.作为进一步的技术方案，生成付款订单之前还包括采购订单对应项目过滤步骤：
25.当生成付款订单时，关联当前采购订单包含的所有项目，在报表中以下拉列表的形式展示该采购订单所有的项目代码、项目名称关键信息，从中选择一条项目进行付款，可申请金额按所选项目计算。
26.作为进一步的技术方案，还包括：根据不同业务需要对供应商设置不同的账户类型，在生成付款订单时选择供应商对应付款账户，获得供应商主数据。
27.作为进一步的技术方案，生成付款订单之后还包括：付款订单审核步骤：
28.根据历史订单校验，对与设定时间内历史支付记录“同一供应商、同一采购订单、相同金额”的付款订单，提示重复支付预警；
29.对疑似重付校验的付款订单进一步的筛查。
30.第二方面，公开了一种用于电力系统的付款订单信息生成系统，包括：
31.项目立项模块，被配置为：接收立项信息，并验证强控字段，若不满足强控规则，则进行预警，提示修改，若满足强控规则，则保存；
32.项目采购模块，被配置为：接收采购申请信息，根据采购申请的类型，验证强控字段，将采购信息进行保存；
33.合同签订模块，被配置为：基于立项信息及采购申请信息提取关键信息，完成合同签订并保存；
34.服务确认模块，被配置为：将服务确认环节所需信息进行保存；
35.发票校验模块，被配置为：将发票校验环节所需信息进行保存；
36.业务环节强控模块，被配置为：预置付款订单信息生成所需各强控规则，并基于预置的规则校验所保存的信息是否完整，若存在缺失则提供集成页面供用户进行补录，得到
业务环节强控信息；
37.付款订单生成模块，被配置为：集成业务环节强控信息，根据提报付款订单的类型，调取相应阶段信息合并生成付款订单，进行数据展示，生成付款订单。
38.以上一个或多个技术方案存在以下有益效果：
39.本发明的整体技术方案通过采购订单对应项目过滤步骤来判断采购订单是否存在多项目的情形，若采购订单号与项目号一一对应，则满足一对一关系，付款订单只针对该采购订单下该项目进行提报；若采购订单号对应多条项目编码，通过open sql技术关联当前采购订单包含的所有项目，在alv报表中以下拉列表的形式展示该采购订单所有的项目代码、项目名称等关键信息，只允许用户从中选择一条项目进行付款，可申请金额按所选项目计算。以此达到“项目-订单-付款订单”规范化控制。继而能够规范项目与订单对应关系、实现合同签订无纸化、对前端业务系统进行强控并优化供应商账户类型，提高工作效率。
40.本发明的技术方案对付款订单审核，对与90天内历史支付记录“同一供应商、同一采购订单、相同金额”的付款订单，提示重复支付预警，达到“事中校验”的效果。通过对疑似重付校验的付款订单进一步的筛查，确保资金支付安全。
41.本发明的技术方案构建了用于电力系统的付款订单信息生成方法及系统，通过“项目-订单-付款订单”一对一规范化控制，提报付款订单，使得信息一致，避免了未挂账先付款的风险；通过经法系统无纸化合同签订模块，提高合同签订效率及合同信息传递效率、合同信息共享准确率；通过业务环节强控模块，规范各业务环节填报信息标准化，提高各业务阶段信息获取准确性、完整性；通过增加供应商主数据的业务类型避免供应商账号信息被反复修改，提高资金结算效率。通过多方面的改造，涉及项目立项至付款订单审批各业务环节有机结合，达到资金支付事前合规管控效果，确保付款订单项目、合同等信息完整准确，实现“一键审核”。
42.本发明附加方面的优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。
附图说明
43.构成本发明的一部分的说明书附图用来提供对本发明的进一步理解，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。
44.图1为本发明实施例系统模块逻辑示意图。
具体实施方式
45.应该指出，以下详细说明都是示例性的，旨在对本发明提供进一步的说明。除非另有指明，本文使用的所有技术和科学术语具有与本发明所属技术领域的普通技术人员通常理解的相同含义。
46.需要注意的是，这里所使用的术语仅是为了描述具体实施方式，而非意图限制根据本发明的示例性实施方式。
47.在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。
48.实施例一
49.本实施例公开了一种用于电力系统的付款订单信息生成方法，包括：
50.项目立项步骤：接收立项信息，并验证强控字段，若不满足强控规则，则进行预警，提示修改，若满足强控规则，则保存；
51.项目采购步骤：接收采购申请信息，根据采购申请的类型，验证强控字段，将采购信息进行保存；
52.合同签订步骤：基于立项信息及采购申请信息提取关键信息，完成合同签订并保存；
53.服务确认步骤：将服务确认环节所需信息进行保存；
54.发票校验步骤：将发票校验环节所需信息进行保存；
55.业务环节强控步骤：预置付款订单信息生成所需各强控规则，并基于预置的规则校验所保存的信息是否完整，若存在缺失则提供集成页面供用户进行补录，得到业务环节强控信息；
56.在服务确认步骤、发票校验步骤等环节调用业务环节强控步骤，保证服务确认、发票校验的合规性、完整性，在付款订单生成步骤中，用户只能通过选择服务确认、发票校验对应的阶段来支付相应的款项(付款订单生成步骤中)，后续审核及支付也是对应付款订单进行，避免出现付款订单再拆分的操作，确保申请金额与支付金额保持一致。
57.付款订单生成步骤：集成业务环节强控信息，根据提报付款订单的类型，调取相应阶段信息合并生成付款订单，进行数据展示，生成付款订单。
58.需要说明的是，在项目采购步骤中生成采购信息，调用业务强控步骤校验合规性、完整性；在采购订单对应项目过滤步骤时限定付款订单只能针对单一项目进行创建，来达到该风险的避免。
59.在合同签订步骤中调用业务环节强控步骤对合同签订信息进行校验。
60.项目立项步骤；项目采购步骤；合同签订步骤；服务确认步骤；发票校验步骤；业务环节强控步骤；采购订单对应项目过滤步骤中均进行审核，确保各阶段信息真实性、完整性。
61.利用供应商主数据形成步骤来解决目前使用内外部账户的供应商主数据平台存在的问题。
62.在具体实施例子中，具体的，项目立项步骤：根据项目不同类型，通过esb技术集成各项目立项系统(erp、规划计划、统一项目储备库、pms系统等)，部署强控模块，在立项阶段通过enhancement等技术验证强控字段(如开工日期、批复文件、概算金额)，当用户填报立项信息不满足强控规则时进行预警，提示用户进行修改；立项成功后并将信息通过接口回传至强控模块保存；若历史数据已流转至后续业务，则在提报付款订单时要求补录项目信息。
63.强控模块用于对立项步骤中输入的数据进行完整性、合规性校验，包括(项目名称、项目定义、电压等级、项目状态、开工日期、计划完工日期、可研批复日期、可研批复文号、项目核准日期、项目核准文号、投资计划金额、概算金额、总投资预算金额、年度投资预算金额)等信息。例如：基建项目、技改项目电压等级必输；信息化项目计划完工时间、可研批复日期等必输。计划完工日期要》计划开工日期，总投资预算金额》年度投资预算金额等。
64.强控模块的输出：将各系统各类型项目立项信息汇总存储，流转至下一步骤。
65.上述步骤中的历史数据指未部署本案技术手段之前的立项信息：假设7月份增加
了强控模块，则3月份系统中完成立项的数据，没有经过强控模块，其字段有可能不完整、不合规。在提报付款订单时提供界面确认及补充早期立项信息。
66.若历史数据已流转至后续业务，具体指业务数据已流转至立项步骤之后，提报付款订单之前。
67.补录项目信息，具体指：提供页面补充、确认立项信息，比如未填写开工日期、计划完工日期；总投资预算金额》年度投资预算金额，电压等级缺失等等不完整不规范的内容。
68.项目采购步骤：根据采购申请不同类型，通过esb技术集成采购阶段业务系统(erp、电子商务平台、ecp系统等)，部署强控模块，通过enhancement等技术验证强控字段。将采购信息等传回强控模块保存；若历史数据已流转至后续业务，则在提报付款订单时要求补录项目信息。
69.验证强控字段，具体包括：根据采购申请的类型不同，校验各系统采购信息的回传完整性。物资类、服务类采购订单的合同付款比例必输、采购方式必输；合同签订日期必输；电子商务平台需带有电商采购标识等。
70.合同签订步骤：通过经法系统，采用电子签章技术手段，通过数字证书保证安全性，完成合同签订无纸化。使用ocr技术将关键信息提取，通过esb集成将数据回传强控模块。
71.上述项目立项步骤完成后后方可进行项目采购步骤完成采购活动，采购成功后进行合同签订步骤。
72.使用ocr技术将关键信息提取，具体指从电子版合同中识别提取关键信息，如合同编号、甲乙方、合同工期、签订日期、合同金额、付款方式等。
73.服务确认步骤：在erp系统部署强控功能，通过rfc、enhancement等技术验证强控规则，验证通过后利用rfc技术将服务确认环节所需信息传递至强控模块进行保存。
74.发票校验步骤：部署强控功能，通过rfc、enhancement等技术验证强控规则，验证通过后利用rfc技术将发票校验环节所需信息传递至强控模块进行保存。
75.需要说明的是，发票校验步骤调用强控模块时，校验并传递发票校验阶段的规则，例如发票编号、税码、金额、发票日期等等，满足必输及规则后存储该阶段信息。
76.业务环节强控步骤：该模块预置付款订单信息生成所需各强控规则，并校验保存的信息是否完整，若存在缺失提供集成页面供用户进行补录。
77.业务环节强控步骤，即为“强控模块”来实现，该模块贯穿于自“立项”起至“发票校验“至各步骤或者模块中，当每一模块业务发生保存时均调用该强控模块，根据预先设置的规则校验每个阶段、每种业务类型的字段必输、字段类型合规性、内在逻辑等等。
78.通过该业务环节强控步骤与每个阶段的互动检查校验，保证了付款订单信息生成时信息完整、准确。
79.自“立项”起至“发票校验“各模块业务发生保存时调用该强控模块功能，根据业务发生阶段、业务发生类型调用不同规则，检验业务数据的合规性。
80.例如立项阶段-大修项目。调用立项阶段中对应大修阶段应该满足的条件，检验保存数据是否合规。
81.该模块强控规则如下：
82.关于项目信息：
83.业务系统所需字段规划计划系统：电压等级、计划完工时间、可研批复日期、可研批复文号、项目核准日期、项目核准文号、投资计划金额。统一项目储备库管理系统：总投资预算金额、年度投资预算金额。erp系统：项目状态、实际开工时间、概算金额。pms系统：电压等级、计划完工时间、投资计划金额、可研批复文号。
84.采购订单及合同信息：
85.业务系统所需字段经法系统合同编号、合同名称、合同金额、合同签订日期、合同付款比例(物资类必输)、采购方式(物资类必输)、供应商erp系统(未通过ecp签订合同)合同编号、合同名称、合同金额、合同签订日期、合同付款比例、采购方式、供应商电子商务平台电商采购标识ecp系统合同编号、合同名称、合同金额、合同签订日期、合同付款比例(服务类)、采购方式(服务类)、供应商
86.采购订单对应项目过滤步骤：为了项目支付信息统计准确，限定付款订单只能针对单一项目进行创建。
87.针对采购订单中存在多项目的情形，当用户生成付款订单时，调用本过滤步骤，通过open sql技术关联当前采购订单包含的所有项目，在alv报表中以下拉列表的形式展示该采购订单所有的项目代码、项目名称等关键信息，只允许用户从中选择一条项目进行付款，可申请金额按所选项目计算。
88.通过open sql技术关联当前采购订单包含的所有项目，具体指：根据采购订单表(ekko)中采购订单号(ebeln)字段为主键，使用项目定义编号(pspid)字段去关联项目定义表(proj)中的项目信息。或者说是使用采购订单表中存储的项目定义编号去关联项目信息。
89.供应商主数据形成步骤：根据不同业务需要对供应商设置不同的账户类型，例如“基本账户”、“农民工工资账户”、“一般结算账户”，在生成付款订单时选择供应商对应付款账户，通过分类控制，避免频繁修改供应商主数据，提高资金结算效率。
90.供应商主数据是以供应商编码为主的一组信息，在发生与供应商相关业务时通过选择供应商主数据从而可以进一步选择供应商的相关信息。
91.例如通过搜索鲁软供应商主数据，可以查到法人是谁，注册资本是多少、营业执照信息、单位地址、银行基本户是哪个。
92.例如付款时，选择供应商001后，相关的银行开户行再选择时，现实的是001名下的银行，银行卡是001名下的银行卡。通过供应商编码进行数据联动选择。而不需要一个字段一个字段的人工输入。
93.付款订单生成步骤中：集成业务环节强控模块信息，根据业务用户提报付款订单的类型(预付款、进度款、验收款、质保款)，调取相应阶段信息合并生成付款订单，通过alv及dynpro技术进行数据展示，用户确认无误后，通过调用bapi生成付款订单。
94.付款订单审核步骤：通过alv技术展示付款订单信息，实现“一键审核”。根据历史订单校验，对与90天内历史支付记录“同一供应商、同一采购订单、相同金额”的付款订单，提示重复支付预警，达到“事中校验”的效果。通过对疑似重付校验的付款订单进一步的筛查，确保资金支付安全。
95.实施例二
96.本实施例的目的是提供一种计算机装置,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方法的步骤。
97.实施例三
98.本实施例的目的是提供一种计算机可读存储介质。
99.一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时执行上述方法的步骤。
100.实施例四
101.参见附图1所示，本实施例的目的是提供一种用于电力系统的付款订单信息生成系统，包括：
102.项目立项模块，被配置为：接收立项信息，并验证强控字段，若不满足强控规则，则进行预警，提示修改，若满足强控规则，则保存；
103.项目采购模块，被配置为：接收采购申请信息，根据采购申请的类型，验证强控字段，将采购信息进行保存；
104.合同签订模块，被配置为：基于立项信息及采购申请信息提取关键信息，完成合同签订并保存；
105.服务确认模块，被配置为：将服务确认环节所需信息进行保存；
106.发票校验模块，被配置为：将发票校验环节所需信息进行保存；
107.业务环节强控模块，被配置为：预置付款订单信息生成所需各强控规则，并基于预置的规则校验所保存的信息是否完整，若存在缺失则提供集成页面供用户进行补录，得到业务环节强控信息；
108.付款订单生成模块，被配置为：集成业务环节强控信息，根据提报付款订单的类型，调取相应阶段信息合并生成付款订单，进行数据展示，生成付款订单。
109.在本实施例子中，还包括采购订单对应项目过滤模块、供应商主数据模块及付款订单审核模块，具体内容参见实施例子一中的采购订单对应项目过滤步骤、供应商主数据步骤及付款订单审核步骤。
110.本技术整体技术方案通过前面步骤的层层校验，最终生成付款订单，本技术整体技术方案通过强控模块，只能按首付款、质保金等阶段来选择付款阶段，无法再任意拆分，保持了付款申请信息与支付信息的一致，能够解决一个资金支付申请表的金额，拆分成多条付款订单进行支付，导致付款的信息与资金支付申请表的信息不一致的问题。
111.在采购订单对应项目过滤模块时完成项目-订单-付款订单对应关系，避免按项目拆分付款、查询时还有未挂账等问题解决，例如现有系统按照两个项目拆分付款，但穿透查询发现，其中一个项目还未挂账，存在未挂账先付款的风险。
112.合同签订模块无纸化及ocr提取并保存技术解决了扫描合同带来的重复劳动、效率低下且可能存在误差。合同签订模块能够实现提质增效、一次收集后信息复用；提高合同签订效率及合同信息传递效率、合同信息共享准确率。
113.从立项阶段到付款订单申请，完成了付款订单所需信息的层层校验及收集，解决了由于项目类型、采购订单类型不同，erp业务数据来源于不同的业务系统，且数据信息缺失较多。财务部门无法直接查看各前端业务系统，对信息准确性、真实性审核无法确认的问题。通过业务环节强控模块，规范各业务环节填报信息标准化，提高各业务阶段信息获取准确性、完整性。
114.供应商主数据模块通过增加供应商主数据的业务类型避免供应商账号信息被反
复修改，提高资金结算效率。解决了适应不同业务使用内外部账户的需要(如招投标业务要求使用外部银行账户，内部结算要用内部账户)，同一供应商的基本户被基层单位反复修改，影响结算效率的问题。
115.以上实施例二、三和四的装置中涉及的各步骤与方法实施例一相对应，具体实施方式可参见实施例一的相关说明部分。术语“计算机可读存储介质”应该理解为包括一个或多个指令集的单个介质或多个介质；还应当被理解为包括任何介质，所述任何介质能够存储、编码或承载用于由处理器执行的指令集并使处理器执行本发明中的任一方法。
116.本领域技术人员应该明白，上述本发明的各模块或各步骤可以用通用的计算机装置来实现，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。本发明不限制于任何特定的硬件和软件的结合。
117.上述虽然结合附图对本发明的具体实施方式进行了描述，但并非对本发明保护范围的限制，所属领域技术人员应该明白，在本发明的技术方案的基础上，本领域技术人员不需要付出创造性劳动即可做出的各种修改或变形仍在本发明的保护范围以内。