用友erp軟件4折優(yōu)惠_實現(xiàn)供應鏈協(xié)同信息共享_提高工作效率

問題描述：

160版本，用戶在查詢2月份的暫估材料余額表時發(fā)現(xiàn)本期報銷的竟然比期初暫估+本期報銷的數(shù)還多，結果結存數(shù)量和金額都變成了負數(shù)，這是咋回事？

暫估余額表一般常見的是上下月結存有金額尾差或是沒有結存數(shù)量，只有結存金額的情況，而這個現(xiàn)象我還是第一次見到。那其他月的暫估余額是否也有問題呢？誒，正常耶！

問題原因：

根據(jù)以往經驗直觀判斷，程序原因導致該現(xiàn)象的可能性不大，根據(jù)暫估表的數(shù)據(jù)來源分析有可能是存貨明細帳上的暫估或結算的記錄異常，直接打開后臺存貨明細帳表看下，結果手里杯子差點掉地上，這，這一點毛病沒有��！

一看就是單到回沖的，1月份暫估記賬了550個，金額36300，2月結算了550個（即本期報銷數(shù)），結算金額是56000，紅字回沖550，暫估回沖金額36300，2月份又暫估入帳了34個，暫估金額2618，暫估標識為1�？梢钥闯�2月的暫估余額應該就是34個，余額2618，這比正常還正常呢！

一般來講暫估余額表的數(shù)據(jù)來源主要就是明細帳啊，如果明細帳正常，那還可能與什么有關呢？別猜了，跟吧。。

通過第一個圖能判斷出問題應該是出自2月份的報銷回沖出的問題，那直接對2月份的報銷回沖的語句進行跟蹤分析：在插入一個臨時表時根據(jù)關聯(lián)條件（包括倉庫、存貨、自由項等）關聯(lián)了存貨總賬，按照腳本的意思應該是取藍字報銷單的數(shù)量。那咋還關聯(lián)重了呢？有可能….存貨總賬出事了！

2月份有條記錄后面的自由項是空！這貨到底有沒有自由項��？前臺一看，這貨不光自由項，還自由項核算呢！

那就怪了，都有自由項核算，那存貨總賬上這條自由項為空的記錄又是哪兒來的？！難道是后臺調整過核算自由項不成？

由于存貨總賬上的結果應該都是從存貨明細賬上匯總來的，那就看看存貨明細帳上是否有記錄異常的，結果還真發(fā)現(xiàn)了一條異常的入庫記錄，58號入庫單的存貨自由項為空，這是什么原因導致的？是程序判斷問題？還是人為故意修改過存貨屬性？這時，一個不起眼的細節(jié)引起了我的注意，就是這條暫估入庫記錄的制單人，這才明白它是由MES系統(tǒng)傳入的，由于傳入時不經過前臺程序的判斷與控制，直接寫入，因此出現(xiàn)了不該出現(xiàn)的問題！

存貨明細賬上的異常結果導致存貨總賬有異，但又是什么原因使暫估材料余額表中的本期報銷數(shù)出現(xiàn)錯誤的呢？

這話還得從之前那條從藍字結算單取數(shù)的關聯(lián)語句上說起： 本來正常通過藍字報銷單（明細帳autoid為80）關聯(lián)存貨總賬時，應只能關聯(lián)出存貨總賬中autoid為70的那條記錄就行了，但誰知它還順手關聯(lián)出了存貨總賬autoid=73的暫估入庫且自由項1為空的那條記錄，這原因何在？

那咱們就把它砸碎了一起分析看看：

其實問題的關鍵是語句中有一個OrIsNull(Ia_summary.cFree1,N‘‘)=N‘‘

或語句 導致的，去掉它一切就正常了，可是能去么？不能！為啥？腳本沒問題，因為確實存貨自由項有為空的正常情況，錯的應該是存貨總帳中自由項不應為空卻為空的記錄！

因此解決問題的關鍵是怎么讓存貨總賬中記錄結果正常，那還得先從存貨明細帳處理起。

解決方案：

經與用戶確定該存貨確有自由項核算，因此首先應與MES系統(tǒng)負責人溝通，后續(xù)傳入時需判斷存貨是否有自由項核算，若有則傳入時相關自由項的值不能為空。

其次對于已傳入的暫估入庫數(shù)據(jù)，由于此次為MSE系統(tǒng)的導入測試，并沒有太多需要補填的數(shù)據(jù)，且用戶表示不方便重新恢復記賬處理，做好數(shù)據(jù)備份后通過關聯(lián)存貨是否為自由項核算且明細賬相應存貨自由項值為空的記錄進行篩選，補填入庫單子表及存貨明細帳，并對存貨總帳進行重算處理。

案例總結：

這個案例也可以說是比較一波三折，給我的反思也是不少：

1、 任何問題不要僅看現(xiàn)象，就僅憑經驗輕易下結論

2、 快速處理問題首要判斷的是問題產生的方向

3、 注意問題的內含與外延的關聯(lián)性對結果判斷的影響

4、 對跟蹤結果的分析也不能只是停留在表面，一定要關聯(lián)性思考去深挖問題本質

5、 注重細節(jié)，不遺漏任何一處導致問題的可能性，逐一進行剝絲抽繭似的分析

6、 對復雜語句進行打碎處理，關注重點，簡潔明了，直擊問題所在！