SAP 對HU做貨物移動報錯-Only 0 serial numbers entered instead of 30 -

SAP 對HU做貨物移動報錯-Only 0 serial numbers entered instead of 30 -

元旦剛過,就收到客戶的業(yè)務(wù)人員報錯說,當(dāng)其對HU做轉(zhuǎn)庫(同一個公司代碼下工廠到工廠或者同一個工廠下存儲地點對存儲地點)都不成功,報錯如下:

Only 0 serial numbers entered instead of 30/

以第一個HU為例,里面是包含有30個序列號的,

HU的狀態(tài)是WHSE,表明HU里的貨物是在庫狀態(tài)。數(shù)據(jù)都是正常的,HU狀態(tài)等都一如從前正常。

那為啥用的好好的事務(wù)代碼,過了一個新年就不能正常運行呢?這個報錯信息,是加入項目近一年以來第一次遇到的。無論是業(yè)務(wù)人員還是我們運維團隊,都感到奇怪!到底是為什么?

項目上對HU執(zhí)行轉(zhuǎn)庫的事務(wù)代碼,沒有使用VLMOVE,而是在VLMOVE的基礎(chǔ)上做了一個封裝,允許一次對多個HU批量進行轉(zhuǎn)庫操作,其核心功能還是VLMOVE的功能。

1),我們?nèi)ロ椖可系腟AP測試系統(tǒng)上測試,發(fā)現(xiàn)如果把過賬日期改成2019-12-31,不是當(dāng)天(2020-1-3)的話,就報相同的錯誤:

如果不修改過賬日期,就是用系統(tǒng)自己建議的日期,

執(zhí)行,

成功了!

也就是說,這個不是對HU轉(zhuǎn)庫的程序問題。不過真的奇怪,跨了一個年就不能對含有序列號的HU轉(zhuǎn)庫過賬了?這不合常理啊。

2),我們就這個問題向SAP公司發(fā)了一個Message。得到的回復(fù),正如預(yù)期的回復(fù)一樣,因我們使用的不是SAP標(biāo)準(zhǔn)事務(wù)代碼,而是一個自開發(fā)的事務(wù)代碼(雖然這個自開發(fā)事務(wù)代碼核心功能還是調(diào)用標(biāo)準(zhǔn)VLMOVE功能),所以SAP公司不提供支持。

3),當(dāng)然,我們也同時找了開發(fā)同事去調(diào)試程序。沒有哪個問題是開發(fā)顧問調(diào)試程序找不到原因的!經(jīng)過開發(fā)同事的努力,我們有新發(fā)現(xiàn):當(dāng)我們將過賬日設(shè)置為2019年年底的時候,程序生成的物料憑證過賬日期是2019年的,但是序列號相關(guān)年度是取的自然年度的日期2020年,這樣會導(dǎo)致物料憑證不完整。也就是說標(biāo)準(zhǔn)SAP系統(tǒng)里VLMOVE不支持為含有序列號的HU做跨年轉(zhuǎn)庫等過賬操作。

我們可以說是SAP系統(tǒng)的一個bug吧。

解決方案,自然不是去打Notes了,而是由開發(fā)同事在相關(guān)檢查的地方加了增強代碼,跳過相關(guān)的檢查繞過這個報錯,最終問題解決。



2019-01-03 寫于銀川市。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容