直到筆者寫這篇博文的時候，這個開發(fā)項目名義上已經(jīng)上線，但其實開發(fā)以及優(yōu)化的工作還在繼續(xù)，數(shù)據(jù)的修復(fù)也仍在繼續(xù)...

       IT系統(tǒng)環(huán)境很簡單，一個基于JAVA+Mysql的Web平臺，一個是宇宙第一的SAP系統(tǒng)，彼此之間用的是Webservice的方式數(shù)據(jù)對接；

       在此之前，公司的業(yè)務(wù)形式上都是買進賣出，不留庫存。雖然有一個所謂“集采”的業(yè)務(wù)，但其實根本沒有在走單，系統(tǒng)能不能走得通都還是未知數(shù)。于是現(xiàn)在又有一個新的業(yè)務(wù)上來了，買與賣不平衡導(dǎo)致了會有庫存差異，而之前的業(yè)務(wù)和開發(fā)都是基于零庫存的模式下進行。這就意味著之前的業(yè)務(wù)模式走不通，需要重新設(shè)立新的業(yè)務(wù)場景，做一定程度的開發(fā)擴展。因為這個業(yè)務(wù)跟“集采”有所類似，所以打算大部分沿用“集采”的接口，我們把它叫做“貿(mào)易通”?！百Q(mào)易通”中采購端與銷售端并沒有直接的單據(jù)關(guān)聯(lián)（部分），下單，收貨，開單，出貨，對賬等都是獨立的。

        seo優(yōu)化培訓(xùn),網(wǎng)絡(luò)推廣培訓(xùn),網(wǎng)絡(luò)營銷培訓(xùn),SEM培訓(xùn),網(wǎng)絡(luò)優(yōu)化,在線營銷培訓(xùn)

        開發(fā)過程如下：

        一、Web下單時采購價格確定

        Web調(diào)用SAP的接口，利用Bapi生成銷售訂單或采購訂單。但是在采購價格確定的時候，之前是參考的銷售價，但因為銷售與采購分離，需要Web上指定一個采購價格。但是調(diào)用Bapi的時候，老是會出錯，報錯說采購價格必須大于0。看來創(chuàng)建采購訂單的時候系統(tǒng)會去取信息記錄，可是既然用戶指定了采購價格就應(yīng)該用人工指定的。這個問題偶爾會發(fā)現(xiàn)，于是直到上線了也沒根斷。后面經(jīng)常報錯，我突然記起來應(yīng)該是一個增強搞的鬼。那個增強是在采購創(chuàng)建和修改的時候，跟價格有關(guān)的就會強制重新定價，就是這個錯誤。于是把增強去掉，此問題解決。

        我很好奇當初顧問做這個增強的意義在哪里，而且我也曾經(jīng)把這個增強給去掉了，如今又冒出來，不解。

         seo優(yōu)化培訓(xùn),網(wǎng)絡(luò)推廣培訓(xùn),網(wǎng)絡(luò)營銷培訓(xùn),SEM培訓(xùn),網(wǎng)絡(luò)優(yōu)化,在線營銷培訓(xùn)

        二、Web平臺發(fā)貨簽收

        Web平臺上對采購做發(fā)貨確認，順利通過接口到達SAP做過賬。但問題是生成的Mseg表并沒有記錄到簽收單號，以至于后面對采購訂單做發(fā)票預(yù)制的時候會提示找不到入庫憑證而報錯。而之前的零庫存訂單在對賬的時候做過賬，而且系統(tǒng)會記錄這個單號信息。這個問題其實很嚴重，但當初給忽略掉了，因為接口里沿用的是原來零庫存的業(yè)務(wù)類別，但這樣會跟實際實物不相符。修改此接口添加相關(guān)欄位信息即解決；

 

        三、Web平臺收貨確認

        Web上對銷售做收貨確認的時候，新的單據(jù)類型就是直接過賬了，與零庫存的業(yè)務(wù)在對賬時過賬不同。但還是當初業(yè)務(wù)模式?jīng)]有界定清楚，把單據(jù)類型定位零庫存的類型，于是這也跟實際庫存業(yè)務(wù)不相符。但既然用了“集采”的單據(jù)類型，就意味著Web平臺那邊需要修改。哪知道修改的時候Web平臺因為技術(shù)原因一直開不了服務(wù)，折騰了大半天才搞定！但就是因為這樣的錯誤，業(yè)務(wù)在補單的時候提交了非常多的單據(jù)，也在系統(tǒng)里面生成了非常多的自建表垃圾數(shù)據(jù)。所以還得IT人工在SAP里面一條一條修正，非常費力。

       收貨確認的時候，Web首先會去讀SAP上轉(zhuǎn)單的庫存，取的是MATDOC