声明：本文根据中科软科技股份有限公司 互联网金融事业部 刘伯夷对保监会需求的理解及其在该领域的相关知识结晶整理，版权归刘伯夷所有，未经允许不可用于盈利性活动。

整理者：Darker 2018年3月7日。

一、需求沟通

1. 演示

1.1 一般需求沟通，先介绍系统，再演示系统。演示是主干流程，后续的答疑包括方案，以及用户提出的变更均以流程演示为中心。

1.2 重要的事情说三遍，保监会报表对接的是保监会，保监会，保监会，不是中保信。我写邮件的时候总写成中保信，如果遇到了请脑改。

 1.3 如果演示系统过程中用户好奇，想让你点点这个，上传个那个，就和用户讲一下，这个是我们搭在云上的一个Demo，用来做演示用的，没有与核心交互，很多数据和配置都不完整暂时没法进行大流程的操作。

1.4 附件PPT如果看通透了，可以投出来给客户讲，如果不通透，千万不要讲。

1.5 沟通交流过程中，如果有的问题实在不了解，就说“这个问题我不太确认了，我先记下来会后我确认一下，邮件反馈给您。”

 1.6 别急着接受，也别急着拒绝，虽然最终还是要拒绝的。

1.7 对于系统功能，不建议做大的调整，因为一旦将来系统有比较大的升级动作，可能由于差异化较大，无法使用统一升级版本。一方面提高升级成本，另一方面可能导致不能如期满足保监会要求。

 1.8 对于一些小的改动，明显有利于用户操作的，可以尝试接受，比如导入页面提供导入模板。再大的就不行了。

 1.9 几个必须知道的点：

       i. 保监会报表又称统信报表或CIRC报表

       ii. 一般公司会由战略规划部，财务部或精算部其中一个部门负责保监会报表的报送，其他部门仅配合提供数据，但每个部门都要对自己提供的数据负责，一旦有误，由所属部门进行修改。原则上不赞成IT手工调平，因为错误信息过多的时候，原则上无法手工调平。我们在其他公司尝试过仅根据错误信息手工调平，在不清楚错误原因的情况下，投入了40多人，改了3天两夜。

       iii. 上报的形式是zip包，保重包含且仅包含一个xml文件。（文件形式见附件DATA000163201707ITEM (19).zip）

      iv. 上报的内容是科目+指标，细节看附件“保监会导入各个模块科目信息.xlsx”

      v. 绝大多数科目体系是树形结构，也有个别不是的，但一般不再我们考虑范围内。

      vi. 上报频率是每月报送2次，一次快报（每月4号之前报送），一次月报（每月10号之前报送），报送内容为上个月的数据。7月10号之前报送6月的半年报，8月10号之前报送7月的月报。 快报内容没区别，月报内容如下：

      vii. 上报对象是中保保监会统信部

      viii. 从10年之后，由于实行新的会计准则，保监会上报内容由原先的一次上报一个zip，变为分别上传两次区分新老会计准则的数据（分两次上传两个zip包，里面的xml内容根据新老会计准则的区别，数据值上会有区别，其他的都没区别）。

       ix. 上载过程是手动的，因为保监会不支持自动上载，也没有相关接口，必须手动。

1.10 介绍把握几个点

1.10.1 先讲故事（故事一般比的是谁讲的老，证明你是真研究系统的，连历史都研究过了）

    1. 1999年2月，中国保险监督管理委员会发布保险监管报表管理暂行办法

    2. 2003年6月，保监会财务部下发了关于规范保险监管报表报送格式的通知

    3. 2004年9月，中国保监会统计信息部下发关于启用中国保险统计信息系统的通知

    4. 2005年11月，中国保监会统计信息部召开中国保险统计信息系统增项工程研讨会

    5. 2006年12月，保监会正统信部下发关于开展新会计准则下保险统计制度转换和对接系统切换工作的通知。

    6. 2008年4月，保监会下发《健康保险统计制度》的通知

    7. 2009年2月，保险统计现场检查方案制定会议召开

    8. 2010年9月，保监会下发关于保险统计信息系统切换工作安排的通知

    9. 2013年10月，中国保监会关于印发《大病保险统计》。

( 记不住就记几点： 1. 保监会在99年就提出了监管报表的想法 2. 2004年开始正式执行 3. 中间由于国内保险行业的发展迅速，先后进行了包括健康险统计制度，新老会计准则等多次升级 4. 咱们的系统也是随着监管的要求，一并成长起来的。

附：保监会建设目标

1.10.2 我们的保监会系统实施了大量的公司，并在实施过程中兼容并蓄，吸收了很多优良实践，是符合行业内规范的软件，整个软件操作流程是基本算是行业标准流程

1.10.3 基于统一监管，我们将原有的保监会系统进行了整合，缩减的部分页面，但是功能基本都集成进来了。

1.10.4 我们的数据精细力度提取+按照树形结构汇总数据，是一套非常科学的针对保监会上报的数据构造体系，极大程度上保证了数据报送的正确性。

1.10.5 集成之后我们使用了更优的方法进行数据交互，也增加了将来调整数据口径的便利性。

1.10.6 统一监管平台也很大程度上节省了公司的硬件资源。（原先三个系统就要三台应用服务器+3台数据库服务器。整合为统一监管之后只要套就够了。别问资源会不会冲突，中保信是每天白天上报，稽核大部分都是监管有要求了才提数报送，保监会报表每个月进行报送，基本上不会有资源冲突。）

1.10.7 统一监管平台支持云部署，目前国宝就是云部署。原有老系统不支持云部署。

1.11 目前统一监管中的保监会报表流程如下：

1.11.1 报表时间维护

    1. 业务说明：由于是报表类系统，需要维护时间来确定具体的时间范围。

    2. 功能说明：为后台数据提取时拼接SQL使用

    3. 可能遇到的问题：

       a) 为什么时间不能自动根据报表月份及类型自动生成（部分公司统计时间口径可能不同，行业中存在公司使用财务月进行上报，因为一般财务月与实际月份大都存在不匹配的情况，所以开放给用户自行定义。大都会，交银的财务月一般是认为每个月在当月的22~25结束（具体那一天，由财务部门年初确定），如果系统自动生成月份匹配到每月的第一天和最后一天，可能存在业务和财务数据不一致的情况。）

       b) 如果不进行这个操作，系统怎么处理？（如果不录，业务数据提取时会进行校验，无法提取（这个校验看看有么有，没有赶紧加上））

1.11.2 数据提取（业务）

    1. 业务说明：从核心业务系统提取相关数据

    2. 功能说明：提取最细粒度的数据，是后面汇总提数的前提。也是我们数据构造的第一阶段。

    3. 可能遇到的问题：

      a) 这里提取的不是已经完成的数据？（回答参照功能说明）

      b) 这个提出来的数据，我们在哪能看到？（数据导入，导出能导出相关数据至（EXCEL/CSV确认一下，如果都支持就没问题，如果只支持Excel，那就说便于查看，如果只支持CSV，就说这个是平台的一个通用功能，将来数据量超过65535行，Excel会缺失数据，CSV不会））

      c) 你们的科目是否全面？（这个问题在这不提出，后面介绍数据导入的时候也会提） 保监从07年之后，没有提供过完整的科目体系，如果有更新的话，也仅提供更新的科目信息，所以目前没有哪家公司敢说自己的科目体系是完全没有错漏的。 但我们的系统包括科目体系的设置，目前在三峡，恒大，和谐健康，国联，中华联合，国华等公司目前都是正常使用上报的，所以基本上可以认定在一般情况下，是满足上报要求的。 我们也可以提供当前系统中的指标列表给用户确认。

1.11.3 数据导入（其他）

    1. 业务说明：外围系统，或者手工整理的数据导入到系统中来

    2. 功能说明：给外部数据提供一个入口

    3. 可能遇到的问题：

      a) 都公用一个页面是否会

        i. 不同模块之间操作错误造成数据覆盖

        ii. 如何控制导入的数据和目标表对应关系的正确性

        iii. 会不会有人误操作不属于他权限范围内的其他数据 上面几个是同一个问题，首先，我们的权限控制可以到下拉菜单，相关权限的人时无法操作相关菜单的。其次，我们对导入的数据表名会有强校验，如果和对应中间表不匹配是无法导入的。（这个可以先在页面做个简单的校验，如果文件名不符合“报表年+报表月+报表类型+中间表缩写”，系统直接提示“文件名与中间表不匹配！”）

      b) 用户提出‘如果我们有XX系统，你们能不能直接从系统中取数？’这个如果用户能提供系统的表结构说明和相关取数逻辑，我们不排斥从系统中直接提取数据。但相关逻辑最好不要太复杂，否则后续一旦对方系统升级，我们作为下游系统，不好进行维护。另一方面我们去学习其他系统的表结构也是有时间成本的，最好是由对方系统的开发商直接提供取数逻辑，或者我们开放中间表，让对方系统直接把数据存到我们中间表里。

      c) 你们怎么分哪些部门需要报送哪些数据？ 我们是有一套参照的Excel的，这个你应该有。Excel中的数据范围其实不是我们定的，是各家公司参照各部门职能不同指定的，我们职能给一个参考，如果用户认为其中某些指标需要由另外一个部门报送，只要把相关指标从一个sheet中剪切出来粘贴到另一个被要求上报的部门所在的sheet中。

1.11.4 数据确认

    1. 业务说明：如果各个部门的数据都已经进入系统，那么由主导的部门负责人来进行确认操作，一旦确认之后，各部分导入数据将视作最终数据，不能重新导入或者删除。

    2. 功能说明：一个功能性的节点

    3. 可能遇到的问题：

      a) 为什么要有这样一个功能 作为一个节点，确保在汇总提数，计算的过程中，不会出现数据被修改的情况。因为一旦在汇总阶段，数据被修改，中间表和生成上报数据的结果表中数据不一致，导致无法排查相关问题。

1.11.5 汇总提数

1.11.6 汇总计算

    1. 业务说明：这两个节点时根据业务中间表数据构造叶子节点（汇总提数），然后通过叶子节点汇总成整个科目树（汇总计算）的过程。这个汇总方式也是我们系统的一大亮点，使用基础数据，根据保监会规则向上汇总，能很大程度上满足保监会的科目之间总分校验。

    2. 功能说明：同业务说明

    3. 可能遇到的问题： 这个功能效率怎么样 这个和硬件性能，保单件数，分支机构数有关系。新成立的保险公司，一般情况下10几分钟即可。我们实施的客户，百万级的数据基本上半个小时左右，千万级保单量，100多家分支机构，一般在2个小时左右。

1.11.7 报表校验

    1. 业务说明：跟进保监会下发的规则（2200多条），对报表系统中的数据进行校验

    2. 功能说明：系统会根据公式里面的“=”将公式拆分为左侧，右侧两部分，分别进行计算，比对计算结果。如果不匹配，则存入系统中，通过“校验结果查询”功能进行查看。

    3. 可能遇到的问题： 校验公式是否全面 回答参照前面“科目是否完整”

1.11.8 校验结果查询 略

1.11.9 生成xml

   1. 业务说明：保监会上报，最终上载的是个zip包，里面有一个xml文件，参照附件。

    2. 功能说明：根据结果表lfxmlcoll 生成最终报送的数据

   3. 可能遇到的问题：  是否支持按区分新老会计准则科目 区分新老会计科目的全部为财务数据，需要看财务数据是否能一次性提供完整的新老会计科目指标。如果可以，可在这个页面分别生成新老会计准则上报数据。 x. 上载至中保信（系统外）

2、注意事项（补充）

2.1 今天确定保监会报表上报数据单位为 元！！！！！

2.2 保监会报表频率上报时，快报只上报新指标，其余频率需要上报新老两套指标！！！

2.3 保监会报表的新老指标分两个系统报送：