前兩天做提成系統的時候發現一個很奇怪的問題，由此引發了我的思考，程序開發的過程中到底是忠於數據還是忠於業務？數據跟業務之間應該是相輔相成的，爲什麼也會出現相互矛盾的時候？
問題描述：原本的員工提成是按照非標準月生成的，比如本月20號生成上月21號到本月20號的提成業績，下個月10號發放該提成。依此類推~~~~而提成是由用戶的投保額來計算的，比如用戶於10月22號投三月保1萬元，提成記錄點爲1月22日。則該用戶對應的員工可以在11月20號、12月20號、1月20號各獲取一次提成，總共三次提成。（提成統計統計節點之後記錄而非節點之前或節點期間的）
現覺得非標準月的方式非常麻煩，想改成正常月的方式，則每月月底生成員工一個月的提成業績，下個月10號發放上月提成。
如何解決：上次生成提成業績爲11月20日，如按照老的方式來說的話應該在12月20號生成11月21到12月20的業績。按照新的方式來說的話，則是在12月31號生成12月1號到12月30號的業績。由此可見，此次系統整改中11月21號到11月30號的業績提成被跨越過去了。於是我單獨統計了11月21號到11月30號的業績，未曾想問題就是出在這裏
另外一組告知，此階段的業績提成不用給，因爲如果給了，公司相當於多給了一份業績。比如以前每次發提成都是30天，這個月就多給了10天變40天了。兩方爭辯未果，給出數據實例，天生愚鈍，不知道何種方案正確，求見解~~~
我們組的方案就是A方案吧，比如用戶於10月22號投三月保1萬元,提成記錄點爲1月22日；如果用老的方案統計的話該用戶對應的員工可以在11月20號、12月20號、1月20號各獲取一次提成。如果用新的方案的統計的話該用戶對應的員工在11月20號、12月30號只可以拿到兩次提成。到了1月30號的時候已經拿不到該筆提成了，綜合所見少了一次。
另外一組的方案就是B方案。還是上面的方案，他們認爲原本用戶在10月22投保的話，原本12月20號的提成，1月10號才發放。而現在12月30號的提成，1月10號就發放了，其實相當於日子順延了10天，所以如果補充提成給他們的話，勢必會照成多給一筆。同時還列出例證如下：比如用戶於10月22號投三月保1萬元,提成記錄點爲1月22日；到1月22日的該筆投保金額返給用戶，用戶繼續續保1萬，這時候新一筆的投保記錄提成記錄點爲4月22日。那麼對於用戶在12月30號取到的提成業績有兩筆，但是如果按照老的來的話，該用戶在12月20號取的提成業績只有一筆。同樣對於12月的業績來說，該用戶的業績就被取了兩次。
關於這個故事的後續：
其實明眼人都看出來，A方案是正確的了，B方案只是在各種兜圈子，爲什麼要兜這個圈子那？B組人是非技術而是人事，試想下以前一個員工在下個月拿的是上個月30天的提成，突然有一個月30天的提成變40天了，人事當然不幹了。當然其中還有個隱含的計算：如果員工A辭職了，根據老方案，他只能拿到當月到21號的提成，但是如果根據新方案，他可以拿到當月到月底的提成。
其實人事也認死理，他們覺得一個月的提成就是給30天，給40天就是虧了。
但是人事不能說這10天我要給你扣掉吧，他們找了一個很好的藉口，說我們組幫他們把這10天的提成順延了。其實壓根不存在順延這種情況。
於是乎員工在發覺這10天沒有了，覺得是我們組動的手腳，沒有聽懂人事的交代，給他們剋扣掉了。
做技術也有3年之久了，一直被放在一個與世無爭的位置上。偶爾爭吵還是因爲需求變更，第一次被當成靶子，幾分心寒幾分無奈。