Endorsement 业务逻辑介绍

本文主要介绍保单系统中Endorsement功能的基本逻辑和过程，主要参考OIC系统

####保单系统 保险公司用来管理保单的信息系统，这里简称为保单系统。主要作用是收集和维护投保人信息和投保信息，计算保费，生成/打印电子保单，以及后续的保单变更、续保等
####常用术语介绍 1. Quote - 收集的保单信息，用于生成保单，根据情况不同又分为： 1. 收集主要信息的Quote - Quick/Lightning Quote 1. 收集详细信息的Quote,根据情况不同可分为： 1. 全新的详细Quote - Full Quote，可从Quick Quote转变而来 2. 为了修改已有的保单而生成的Quote - Endorsement Quote(简称EQ)，绑定后保单状态转为Endorsement(简称EN) 3. 为了续保而生成的Quote - Renew Quote，绑定后将生成下一个周期的保单，保单状态为Renewal 1. 绑定 - 从Quote转换为保单的过程 1. Policy - 已生成的保单，根据情况不同又分为： 1. 第一次生成保单 - New Business 2. 修改后的保单 - Endorsement 3. 续保的保单 - Renewal 1. OOS Endorsement - 多次对Policy的修改的生效时间不是从前到后的Endorsement。比如我们对Policy进行了3次修改，第一次生效时间为2017/02/01，第二次生效时间为2017/02/05，第三次生效时间为2017/02/10，那么这就是一个顺序的修改过程，如果我们第二次修改的时间为2017/02/15，第三次的修改生效时间就在第二次修改之前了，我们说第三次的修改就不按顺序的修改，是一个OOS Endorsement。

Endorsement业务流程简述

在保单的有效期间可以对保单进行修改，一般在policy信息的action标签下可以找到这个入口，有的系统可能需要相应的权限才能操作。简化的流程是这样的：1. 填写修改生效时间，修改原因等，2. 点击生成EQ，3. 修改Quote信息，4. 绑定成保单。流程看似很简单，但是在绑定的过程中有很多事情要做。

Endorsement业务流程常见处理过程

1. Quote阶段
   在EQ创建的时候选择生效时间，在EQ创建之后一般是不允许修改的(部分系统拥有权限的用户允许修改)，EQ的其他信息基本都是从原来的Policy复制而来的，在不进行任何修改的情况下保费不会发生改变，修改了投保信息，投保范围和保额等信息后，在Quote Result页面进行保费计算后能看到保费的变化，包括保费(Premium)，其他费用(Fee)，总保费，本次修改后实际应付总保费金额(系统成为Written Premium，是根据修改变化和实际的变化生效时间计算出的保费)。

2. 绑定阶段
   绑定阶段要做的事情很多：

   1. 标记EQ为已绑定
   2. 当前Policy的所有的EQ标记为失效,对应数据表的字段为PQ_CurrentRecord=0
   3. 调用usp_CreatePolicyFromQuote存储过程，从Quote生成Policy数据
   4. 调用endorsepolicyrecord
      1. 如果是OOS Endorsement，就需要将已经做过的生效时间在本次生效时间之后EN全部Void掉也就是取消掉，本法就是Copy这些EN的原始Policy并使其生效，相当于对冲掉了修改。部分系统中可能需要将这些Viod掉的EN在OOS EN之后再重新应用到系统，整个过程就像是按照生效时间将所有的EN重新捋顺了一样。
      2. 更新Policy的PD_TransOrder，PD_AccountingDate
      3. 将原policy标记为失效，因为PolicyCode是不变的，只能有一个有效的Policy
      4. 计算WrittenPremium和WrintenPremiumLevel，WrittenPremium记录了每一项保费相对于上一状态的Policy的实际变化，WrintenPremiumLevel记录的是更细化一层的保费变化，如一个Policy中为10辆车购买了第三方责任险，那么WP记录总的第三方责任险,WPL就会记录每辆车的第三方责任险。注意Quote Result页面也进行了WP的计算，但是对于OOS的情况计算记过是不准确的，因为系统的原因整个暂时没有办法调整。
      5. 检查WP的commission percent的设定，不能有为空的
      6. 根据增加/减少的保费(Premium)和费用(Fee)添加Accounting记录，PolicyAccounting记录了所有的操作引起的费用变化
   5. 将Quote阶段产生的Document/Attachment转到新的Policy下，如果有Document/Attachment的话
   6. 如果原始的Policy处于计划Cancel状态，需要将用于标记计划Cancel的Document转到新的Policy下，主要更新PD_ID
   7. 重新计算账单，如果是分期付款，待付账单金额会有变化，如果是一次性付款的，保费增加时需要生成额外的账单(Additional Premium Bill)
   8. 计算Policy的Balance(应付款总额-已付款总额)
      
      

总结

不同的系统在绑定的时候可能或多或少的需要加入一些各自的处理过程，但主要的逻辑过程基本都是这样的，这里主要是参考OIC系统的Endorsement，对照系统代码将更有利于理解和掌握。

posted @ 2017-02-06 10:32 by Mark