camsi保单树优化

保单树优化"/>

camsi保单树优化

之前我做过的保单树的拆表工作，将以前的一张大的保单表按照个人属性、车辆属性、保单属性、保费浮动项属性、保费关联项属性、订单属性、支付属性进行了重新划分，将当时的思路记录下来，以便后期参考相关案例使用。

个人属性表（Plc_Autoparty）主要是记录跟客户相关的所有信息，通过客户代码字段进行唯一性标识，通过员工代码与电销操作员进行关联。这些字段在网销系统中的商机收集页面、车辆信息收集页面、投保预确认页面进行写入，并且在电销商机转网销时通过接口查询后也会进行写入。

车辆属性表（Plc_Autoinsuredvehicle）记录从精友网查询到的车辆信息，能够唯一确定这些信息的字段保存在保单属性表中，在老的投保流程中，保费计算主要是根据这些字段来进行的，新商改中该笔字段与保费浮动项属性共同参与保费计算。

保单属性表（Plc_Autoagreement）主要记录在投保确认前的一些信息，主要是车辆基本信息（用于跟精友系统交互唯一确定车辆标的），另外还包括一个电销商机ID，客户通过输入电销商机ID之后进入车辆信息收集页面，然后网销查询电销接口，并将电销返回的所有信息存储到本地，因此将此字段也归到此表中。

保费浮动项属性表（Plc_Autopremiumfloating），由于新商改中新增了一些保费浮动项因子，所以所有的保费浮动项均保持在这张表中，另外由于我们网销系统无法在初始时就获取这些信息，需要通过查询P09系统接口或者电销系统接口来获取，因此我也把定义为接口属性表，关于接口中的交互模式虽然不是我负责的，但是在该项目中实现方式别具一格，后期单独拎出来说。

保费关联项属性表（Plc_Autopremiuminvolved）,该表里面的属性不直接参与保费计算，但是会对保费浮动项进行一些限制，例如折扣下限浮动比例等，因此也单独列出来放在一张表中。

订单属性表（Sls_Order）存放的是此次交易的订单信息，在在线销售系统中，保单被当做商品来进行售卖，虽然该属性与保单无直接联系，也被归属于保单树中。

支付属性表（Sls_Payment）原本不属于保单树中的一部分，但是在整个网销流程中，业务方提出了如下需求：可以通过支付号来查找保单订单号，可以通过支付号来进行线下支付，可以通过支付号来取消保险订单，可以通过订单号来进行支付。因此该表也被我归入到保单树中。

以上所有表均存在一个唯一ID，并保存在保单主表（Plc_Auto）中，另外保单主表中还存放着一个商机id，这张表是整个网销系统共用的，主要作用是将此次交易信息同步给电销系统，如果此次交易终止，电销系统会根据同步过去的信息与客户进行联系并争取完成此次交易。通过以上id，其他模块的开发者均可以使用其中的任意一个id来查找其他属性。

另外顺带带一下我开发的另外一个功能。
页面通过ajaxAction发送一个JSON请求过来，JSON中包含一个id，该id我使用的是保单属性id或者订单属性id或者支付属性id，然后我将网销投保流程分为9个页面，分别为1：商机页面 2：车辆信息页面 3：商业险页面 4：交强险页面（3、4在页面中是同一页面，但是由于P09系统会分别进行校验，而且客户也可以选择只投保其中一个现在，所以日志信息需要分开保存） 5：提交支付页面 6：线上支付页面 7：线下支付页面（此页面为虚拟页面，客户线下支付后，网销收到支付系统支付完成通知）8.支付成功页面 9.保单落地页面（此页面也是虚拟页面，用来记录保单是否落地保单系统），在这9个页面中我通过传入不同的id来获取我需要的信息，并保存在日志表中，如果后续其他开发人员需要记录日志，仅仅需要传入任意一个id，无需传入复杂的参数。通过这样的拆表大大提升了其他模块的开发效率。

最后再谈下为什么叫保单树，以前IBM开发过的一个保单生成流程，我觉得这个流程设计的非常好，它被打成一个jar包，如果不是需要开发相关功能或者通过断点形式，是不会进入到这里的。

首先是获取到一个信息，这个信息代表了此次交易的险种信息，通过这个字段在Spec_Role表中查询到唯一的specId，然后通过该specId我们查询到该险种下的所有具体表项和费率表，然后根据查到的字段继续去关联该字段名下的子字段，如此循环直到获取不到为止，此模型比较类似一个树形结构，因此我们称它为保单树。

转载于: