Refund
Refund介绍
Refund指的是保险公司将保费退还给投保人的操作过程. 比如一个人一次性交了两个月的保费, 但是由于某种原因, 他在保单只生效了一个月的时间就把保单cancel了, 这样的话他就多交了一个月的保费, 这个时候保险公司是要把那个多交的钱退还给他的. 还有一种常见的会引起退款的原因是endorsement把保费降低, 比如本来保费是1000块钱, 投保人一次性把保费都交齐了. 但是后来做了一次endorsement, 保费降低到了800块钱, 这个时候保险公司也要把多交的那200块钱退还给投保人.下面看一下例子来熟悉整个操作过程.
1. 有一份Policy, ADAZ0000975-00, 投保人一次性交齐了钱. 这个时候balance是0.
2. 对它做cancel操作. 我们发现balance是-2411. 这个钱是怎么算出来的呢.
我们看到Policy下面的信息
所以这是一个12个月的保单, 保费是2619, 那么每天保费是2619/365=7.18, 而从这份保单生效到被cancel一共是29天, select datediff(day, '02/20/2017', '03/21/2017'). 这样这份保单一共生效的保费就是 7.18* 29 = 208.22, 所以做完cancel后就应该把多的钱退还回去, 也就是 2619-208.22 = 2410.78. 跟我们页面上的2411差了几毛钱, 这是在计算过程中由于小数点的允许误差范围内的.
3. 下面就是如何把这多出来的钱退给投保人了. 我们用下面这个DTS来完成这个操作.
打开文件DTS_ReturnPremiumCheck.vrm, 先判断policy的balance是否超过了最小的需要退的钱.
如果满足条件, 那么判断在ReturnPremium表里是否还有这个Policy没有处理的数据.
ReturnPremium是这整个操作的主表, 他记录了哪个Poilcy需要退还多少钱. 其中关键字段是RP_PaidUserID, 如果这个字段有值且大于0, 说明这个钱已经退回去了. 否则就是还没有退回去. 而我们这个DTS主要就是往这个表里插数据, 当然刚插进去的数据RP_PaidUserID都是空的, 具体处理还在后面.
好了, 接着刚才的话题, 如果发现在这个表里这个policy没有示处理的数据, 那么直接把这个Poilcy相关的信息插到ReturnPremium表就行了, 主要是把退的金额插进去.
如果这个表里还有这个Poilcy没处理完的数据, 直接update原先的那条数据的金额. 下面我们跑一下这个SST来看一下有什么变化.
我们发现returnpremiuim表里多了一条记录, 记录了要退的钱是2411块钱, 而我们的transaction现在没有任何变化的, 还是显示需要退这么多钱. 所以我们跑完DTS后并没有把钱给退回去.
4. 退钱操作是要在页面进行的, 下面看详细操作.
点这个Link进入到页面, 选到policy相应的LOB等信息, 发现这个Policy存在于要退钱的行列.
选中这条记录往后走, 有个Print check的操作, 点击他就会打印出一张check出来, 一般是会拿这张check核对相关的信息对不对.
点击完这个print checks后来到后一个页面, 需要在这个页面里save, 才是真正地把钱给退回去了.
这个时候我们再去看页面, balance就是0了, 说明钱已成功退回. 客户拿着刚才那张支票就可以去领到钱了.
另外, 在transaction页面上还有一个特殊的地方也可以实现退钱. 比如我们在刚才那个Policy上付200块钱,
这个时候保险公司又要把钱还给客户了. 但是保险公司不想那么麻烦又是DTS又要页面操作来退款, 这个时候页面上有个功能
我们用这个refund check来退这200块钱, 做一个这个操作, 发现页面上并没有什么反应.
但是我们去查数据库, 发现这200块钱已经加到了ReturnPremium表里了. 而他的来源也标得很清楚, 是手动refund加进去的.
这个时候你可以不用再去跑DTS了, 而是直接在页面上操作把钱退了.
但是, 如果你跑DTS的话, 会发现系统会多生成一条数据出来退钱, 这样就相当于退两遍, 那么就会又是客户欠200了…
我们试验一下,把这两条都退了.发现果然balance变成了200.
所以说如果想要用页面上的手动退款操作的话, 就不要去跑DTS, 直接操作完后再去页面上把钱退了. 之所以有这个功能是因为我们的DTS是每天自动跑的, 所以returnpremium的数据要到第二天才会生成出来, 而客户如果急用钱的话, 我们就直接在页面上退给他就好了.
