直到筆者寫這篇博文的時候，這個開發(fā)項(xiàng)目名義上已經(jīng)上線，但其實(shí)開發(fā)以及優(yōu)化的工作還在繼續(xù)，數(shù)據(jù)的修復(fù)也仍在繼續(xù)...
IT系統(tǒng)環(huán)境很簡單，一個基于JAVA+Mysql的Web平臺，一個是宇宙第一的SAP系統(tǒng)，彼此之間用的是Webservice的方式數(shù)據(jù)對接；
在此之前，公司的業(yè)務(wù)形式上都是買進(jìn)賣出，不留庫存。雖然有一個所謂“集采”的業(yè)務(wù)，但其實(shí)根本沒有在走單，系統(tǒng)能不能走得通都還是未知數(shù)。于是現(xiàn)在又有一個新的業(yè)務(wù)上來了，買與賣不平衡導(dǎo)致了會有庫存差異，而之前的業(yè)務(wù)和開發(fā)都是基于零庫存的模式下進(jìn)行。這就意味著之前的業(yè)務(wù)模式走不通，需要重新設(shè)立新的業(yè)務(wù)場景，做一定程度的開發(fā)擴(kuò)展。因?yàn)檫@個業(yè)務(wù)跟“集采”有所類似，所以打算大部分沿用“集采”的接口，我們把它叫做“貿(mào)易通”?！百Q(mào)易通”中采購端與銷售端并沒有直接的單據(jù)關(guān)聯(lián)（部分），下單，收貨，開單，出貨，對賬等都是獨(dú)立的。
開發(fā)過程如下：
一、Web下單時采購價格確定
Web調(diào)用SAP的接口，利用Bapi生成銷售訂單或采購訂單。但是在采購價格確定的時候，之前是參考的銷售價，但因?yàn)殇N售與采購分離，需要Web上指定一個采購價格。但是調(diào)用Bapi的時候，老是會出錯，報錯說采購價格必須大于0。看來創(chuàng)建采購訂單的時候系統(tǒng)會去取信息記錄，可是既然用戶指定了采購價格就應(yīng)該用人工指定的。這個問題偶爾會發(fā)現(xiàn)，于是直到上線了也沒根斷。后面經(jīng)常報錯，我突然記起來應(yīng)該是一個增強(qiáng)搞的鬼。那個增強(qiáng)是在采購創(chuàng)建和修改的時候，跟價格有關(guān)的就會強(qiáng)制重新定價，就是這個錯誤。于是把增強(qiáng)去掉，此問題解決。
我很好奇當(dāng)初顧問做這個增強(qiáng)的意義在哪里，而且我也曾經(jīng)把這個增強(qiáng)給去掉了，如今又冒出來，不解。
二、Web平臺發(fā)貨簽收
Web平臺上對采購做發(fā)貨確認(rèn)，順利通過接口到達(dá)SAP做過賬。但問題是生成的Mseg表并沒有記錄到簽收單號，以至于后面對采購訂單做發(fā)票預(yù)制的時候會提示找不到入庫憑證而報錯。而之前的零庫存訂單在對賬的時候做過賬，而且系統(tǒng)會記錄這個單號信息。這個問題其實(shí)很嚴(yán)重，但當(dāng)初給忽略掉了，因?yàn)榻涌诶镅赜玫氖窃瓉砹銕齑娴臉I(yè)務(wù)類別，但這樣會跟實(shí)際實(shí)物不相符。修改此接口添加相關(guān)欄位信息即解決；
三、Web平臺收貨確認(rèn)
Web上對銷售做收貨確認(rèn)的時候，新的單據(jù)類型就是直接過賬了，與零庫存的業(yè)務(wù)在對賬時過賬不同。但還是當(dāng)初業(yè)務(wù)模式?jīng)]有界定清楚，把單據(jù)類型定位零庫存的類型，于是這也跟實(shí)際庫存業(yè)務(wù)不相符。但既然用了“集采”的單據(jù)類型，就意味著Web平臺那邊需要修改。哪知道修改的時候Web平臺因?yàn)榧夹g(shù)原因一直開不了服務(wù)，折騰了大半天才搞定！但就是因?yàn)檫@樣的錯誤，業(yè)務(wù)在補(bǔ)單的時候提交了非常多的單據(jù)，也在系統(tǒng)里面生成了非常多的自建表垃圾數(shù)據(jù)。所以還得IT人工在SAP里面一條一條修正，非常費(fèi)力。
收貨確認(rèn)的時候，Web首先會去讀SAP上轉(zhuǎn)單的庫存，取的是MATDOC
