保单的状态没有写在列里

保险合同状态并不是存放在某处的固定值，而是每次根据缴费记录和基准日重新计算出来的结果；因此，状态字段与事实总会出现分歧。

概念图: 不知道“失效”究竟意味着什么 · 由人决定的事件 · 由时间决定 · 投保申请

进入保险公司现场的第一周，你可能会收到这样的请求：“这份合同好像没有作失效处理，请帮忙看一下。”

查看日志，没有错误；夜间批处理也显示成功。打开数据表，status 字段中写着 정상。系统声称自己完全按照要求执行了操作，业务负责人却说结果不对。

卡在这里的原因并非技术能力，而是不知道“失效”究竟意味着什么。理解这个词，五秒钟内就能确定该查看哪里；不了解它，就会把一整天耗在日志里。

保险合同会按以下顺序流转。

청약 → 인수(언더라이팅) → 성립 → 유지(납입) → 실효 → 부활 → 해지 / 만기

前三项是由人决定的事件，后面的状态大多由时间决定。这种差异决定了数据的形态。

投保申请是客户申请加入保险的状态，此时还不是合同。在这一阶段，客户负有如实告知义务，需要说明既往疾病、正在服用的药物、职业等事项。

**承保（核保）**是公司决定是否接受这项风险的流程。结果有四种：标准体承保、加费承保、排除特定部位或疾病责任的除外承保，以及拒保。“投保申请在承保环节被退回”，意味着在这个阶段遭到拒绝。

合同成立发生在首期保费到账且公司作出承诺时，保障从此刻开始。

合同维持是按期缴纳每期保费的阶段，其中有两个重要日期：缴费到期日和宽限期。即使未在到期日缴费，合同也不会立刻中止，而会给予一段等待时间。

失效是本课程的第一个陷阱。失效不是一个实际发生并被记录的事件。 任何表中都不会有“这份合同已经失效”的事件记录。系统中只有一笔未缴期次和宽限规则，失效日期由此计算得出。

납입기일        2026-02-10
유예 만료일     2026-03-31   ← 납입 해당월의 다음 달 말일
실효일          2026-04-01   ← 유예 만료일 다음 날

直到宽限期到期日当天，合同仍然有效。这一天之差会造成真实纠纷：如果事故发生在 3 月 31 日，保险金应当赔付；发生在 4 月 1 日，则不应赔付。

复效也经常被误解。人们很容易认为，只要为失效合同补缴拖欠保费，合同就会自动恢复，但事实并非如此。复效需要重新完成复效申请、再次履行告知义务和审核。如果失效期间出现疾病，合同可能附加除外责任，也可能被拒绝复效。因此，失效后收到的缴费，只要没有复效事件，就不会让合同恢复有效。

那么，数据表里为什么会有 status 字段？因为每次重新计算成本太高，所以夜间批处理会计算状态并写入字段。就在这一刻，二者开始分离。

status 컬럼   어젯밤 배치가 계산한 '의견'
납입 이력      지금 다시 계산할 수 있는 '사실'

如果批处理失败、未反映复效处理，或没有跟随后续录入的更正，意见就会偏离事实。而且，批处理会静默失败。 不是完全没有错误日志，而是即使留下日志，也没有人把它与这份合同关联起来。

第一，被错误判定为失效的合同无法获得保险金赔付。 柜面会答复“合同已经失效，无法赔付”，客户可能争议数月，最终向金融监管机构投诉。调查后发现，原因只是复效处理批次在 3 月失败过一次。不当拒赔不仅要补付保险金和延迟利息，案件数量本身也会成为监管检查指出的问题。

第二，被错误保留为正常状态的失效合同更加危险。 客户并不知道保障已经中断，也不会收到通知。若在此状态下发生事故，客户直到那一刻才得知情况，公司和客户都会遭受损失。

第三，复效时没有再次取得告知信息的合同，会在数年后的理赔阶段爆发问题。 审核可能以“投保前未履行告知义务”为由拒赔，客户则会说“当时根本没人问过”。如果没有记录，公司就会败诉。

先在下一篇理论课中学习基准日与追溯更正，然后再进入实操。

你将亲自创建 40 份合同、480 期缴费记录、合同事件，以及之后录入的收款更正。随后根据这些数据，从缴费记录计算特定基准日的合同状态，并与系统的 status 字段对照，找出 9 份状态不一致的合同。不一致会分为三个方向，而每个方向给客户造成的损害都不同。