本文主要介紹保單系統中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業務流程常見處理過程
quote階段
在eq建立的時候選擇生效時間，在eq建立之後一般是不允許修改的(部分系統擁有許可權的使用者允許修改)，eq的其他資訊基本都是從原來的policy複製而來的，在不進行任何修改的情況下保費不會發生改變，修改了投保資訊，投保範圍和保額等資訊後，在quote result頁面進行保費計算後能看到保費的變化，包括保費(premium)，其他費用(fee)，總保費，本次修改後實際應付總保費金額(系統成為written premium，是根據修改變化和實際的變化生效時間計算出的保費)。
繫結階段
繫結階段要做的事情很多：
標記eq為已繫結
當前policy的所有的eq標記為失效,對應資料表的字段為pq_currentrecord=0
呼叫usp_createpolicyfromquote儲存過程，從quote生成policy資料
呼叫endorsepolicyrecord
如果是oos endorsement，就需要將已經做過的生效時間在本次生效時間之後en全部void掉也就是取消掉，本法就是copy這些en的原始policy並使其生效，相當於對沖掉了修改。部分系統中可能需要將這些viod掉的en在oos en之後再重新應用到系統，整個過程就像是按照生效時間將所有的en重新捋順了一樣。
更新policy的pd_transorder，pd_accountingdate
將原policy標記為失效，因為policycode是不變的，只能有乙個有效的policy
計算writtenpremium和wrintenpremiumlevel，writtenpremium記錄了每一項保費相對於上一狀態的policy的實際變化，wrintenpremiumlevel記錄的是更細化一層的保費變化，如乙個policy中為10輛車購買了第三方責任險，那麼wp記錄總的第三方責任險,wpl就會記錄每輛車的第三方責任險。注意quote result頁面也進行了wp的計算，但是對於oos的情況計算記過是不準確的，因為系統的原因整個暫時沒有辦法調整。
檢查wp的commission percent的設定，不能有為空的
根據增加/減少的保費(premium)和費用(fee)新增accounting記錄，policyaccounting記錄了所有的操作引起的費用變化
將quote階段產生的document/attachment轉到新的policy下，如果有document/attachment的話
如果原始的policy處於計畫cancel狀態，需要將用於標記計畫cancel的document轉到新的policy下，主要更新pd_id
重新計算賬單，如果是分期付款，待付賬單金額會有變化，如果是一次性付款的，保費增加時需要生成額外的賬單(additional premium bill)
計算policy的balance(應付款總額-已付款總額)
總結不同的系統在繫結的時候可能或多或少的需要加入一些各自的處理過程，但主要的邏輯過程基本都是這樣的，這裡主要是參考oic系統的endorsement，對照系統**將更有利於理解和掌握。
posted @ 2017-02-06 10:32 by mark
業務邏輯處理
功能的實現，都是依靠業務邏輯來完成的，記得看過不能完成業務邏輯的程式設計師都不會成長的，確實是的，最近在完成業務邏輯的時候，程式的業務判斷有很多的，所以開始接觸，設計模式，看到來一些設計模式，看結合專案，確實是可以根據設計模式來改寫的，so，懂得設計模式可以快速的，寫好的 的。關於函式同步和非同步之...
業務邏輯漏洞
業務邏輯漏洞是一類特殊的安全漏洞，業務邏輯漏洞屬於設計漏洞而非實現漏洞，是業務邏輯設計不嚴謹導致的漏洞。大多數業務邏輯漏洞沒有明顯的攻擊特徵，難以通過漏洞掃瞄的方式發現，也難以通過安全裝置來防護。繞過驗證 主要指身份驗證體系設計存在缺陷，可以使用某些技術手段繞過驗證機制冒用他人身份。越權訪問 主要指...
業務邏輯設計
1.action設計 shfwpgdzlbdmanager.copy mannager裡面的相應方法 shfwpgdzlbd.getbdtpid 傳入的引數從哪獲取，型別應和mannager的方法需要的引數型別相同 2.manager設計 設計之前宣告物件 private shfwpgdzlbdda...