今天一大早，收到商務部發來的訊息，說某乙個客戶的額度超額了，但實際上並未超額。從sap系統中反饋的額度來看，顯示超了2萬多。後來經過在bp畫面檢查信用段發現，這個客戶額度占用裡面，某乙個未清訂單已經部分交貨並開票了，這點在未清發票裡面也有體現，但未清訂單裡這個訂單額度仍舊是總額，如此額度就被重複占用了。這明顯違反了sap裡面額度計算的規則，很明顯這是sap新版本的bug！後來我在測試系統中想還原該問題，卻沒辦法能夠重現情景，這個單子的異常到底是什麼情況就不知道了。
那麼接下來就得重新計算該客戶的額度了，直接修改表是不被允許的。就只能寄望於系統是否有提供這樣的標準function或者程式了。
上圖顯示該銷售訂單只是部分交貨開票。
在額度的占用明細裡，該訂單仍舊是總額。
於是問sap群裡，有fico給出f.28這個事務**或執行程式rfdkli20 來調整客戶額度，誰知道在s4系統裡面這個作業**已經失效了！
後來又有高手給出通過sa38/se38執行程式rvkred88 和 rvkred77來調整額度，但s4裡面仍舊不被支援，系統會報錯：
如此ecc下的方法怕是行不通了。然後又有fico網友給出新的程式：
ukm_rvkred88（查閱） / ukm_rvkred77（更新）
執行ukm_rvkred88這支程式查閱可知系統也得到了正確的銷售訂單額度值！
這下s4系統是可以支援的了，但我意外發現執行了ukm_rvkred77之後，該客戶的額度裡面未清訂單居然翻倍了！
比如原來額度是18100這樣子：
未清訂單占用如下圖：
執行了ukm_rvkred77之後：
很明顯，額度占用金額已經增大了不少
上圖未清訂單的額度占用已經翻倍。
如果該程式執行多次，就會一直翻倍，額度占用越來越多，簡直太讓人心驚了！！不得不說這個程式真的不適合s4系統！
但這個時候無論是sap群，還是sap官網和外國英文部落格全部找不到解決的方案！
我想這既然這個東西是ukm開頭的程式，或許其他類似的程式可以搞定也不准，於是我在se38裡面搜尋ukm開頭的程式，果然讓我找到了：
ukm_rfdkli20 ：更新未清訂單額度
ukm_rfdkli20_ar ： 更新未清發票額度
繼續：
系統已經重建了額度占用，這個時候回到bp的畫面，發現額度已經回來了！
不得不說，s4系統目前還是不太完善，特別是1511這個版本。這個額度的bug本身就是系統莫名其妙出的問題，而官方給的幾個程式更是莫名其妙，執行之後額度居然會翻倍，這個在sap系統裡面是非常少出現的低階的錯誤。好在最後還是搞定了！整個過程還是很驚心動魄的，因為這個問題商務部那邊已經在抓狂等待下單了！
CISSP認證考試驚心動魄的回憶
我參加了今年3月26日的上海考試。這個日子對我而言比較特殊，因為這一天正是我的生日，更重要的是我差點在cissp的大門前嘎然止步！3月25日晚上，我還在不停地翻all in one cissp prep guide和學習筆記，特別是重點看了secuirty mode。對security mode部分...
記一次驚心動魄的上線問題
專案上線了，跑了一段時間，就出現卡死的情況。一看伺服器的cpu或者記憶體並沒有多高。後來重啟了一下nginx和php fpm後就正常了。通過檢視nginx錯誤日誌104 connection reset by peer，發現需要修改配置。nginx的buffer太小，timeout太小。client...
驚心動魄，網路傳輸非常慢，而且客戶端上傳頻繁超時。
一次線上的經歷，乙個客戶實施後台，客戶端通過程式上傳，在一定時間內頻繁超時。從6月份開始直到10月份才解決這個問題。1 排查客戶端，開始扯皮網路，搜尋證據，動用什麼網路分析家，更重分析軟體，找到證據，都在迴避問題，客戶端也在弄乾淨問題，耗時乙個月。2 排查網路，什麼客戶方的網路技術專家，什麼防火牆，...