直到筆者寫這篇博文的時候，這個開發專案名義上已經上線，但其實開發以及優化的工作還在繼續，資料的修復也仍在繼續...
IT系統環境很簡單，一個基於JAVA+Mysql的Web平臺，一個是宇宙第一的SAP系統，彼此之間用的是Webservice的方式資料對接；
在此之前，公司的業務形式上都是買進賣出，不留庫存。雖然有一個所謂“集採”的業務，但其實根本沒有在走單，系統能不能走得通都還是未知數。於是現在又有一個新的業務上來了，買與賣不平衡導致了會有庫存差異，而之前的業務和開發都是基於零庫存的模式下進行。這就意味著之前的業務模式走不通，需要重新設立新的業務場景，做一定程度的開發擴充套件。因為這個業務跟“集採”有所類似，所以打算大部分沿用“集採”的介面，我們把它叫做“貿易通”。“貿易通”中採購端與銷售端並沒有直接的單據關聯（部分），下單，收貨，開單，出貨，對賬等都是獨立的。
開發過程如下：
一、Web下單時採購價格確定
Web呼叫SAP的介面，利用Bapi生成銷售訂單或採購訂單。但是在採購價格確定的時候，之前是參考的銷售價，但因為銷售與採購分離，需要Web上指定一個採購價格。但是呼叫Bapi的時候，老是會出錯，報錯說採購價格必須大於0。看來建立採購訂單的時候系統會去取資訊記錄，可是既然使用者指定了採購價格就應該用人工指定的。這個問題偶爾會發現，於是直到上線了也沒根斷。後面經常報錯，我突然記起來應該是一個增強搞的鬼。那個增強是在採購建立和修改的時候，跟價格有關的就會強制重新定價，就是這個錯誤。於是把增強去掉，此問題解決。
我很好奇當初顧問做這個增強的意義在哪裡，而且我也曾經把這個增強給去掉了，如今又冒出來，不解。
二、Web平臺發貨簽收
Web平臺上對採購做發貨確認，順利通過介面到達SAP做過賬。但問題是生成的Mseg表並沒有記錄到簽收單號，以至於後面對採購訂單做發票預製的時候會提示找不到入庫憑證而報錯。而之前的零庫存訂單在對賬的時候做過賬，而且系統會記錄這個單號資訊。這個問題其實很嚴重，但當初給忽略掉了，因為介面裡沿用的是原來零庫存的業務類別，但這樣會跟實際實物不相符。修改此介面新增相關欄位資訊即解決；
三、Web平臺收貨確認
Web上對銷售做收貨確認的時候，新的單據型別就是直接過賬了，與零庫存的業務在對賬時過賬不同。但還是當初業務模式沒有界定清楚，把單據型別定位零庫存的型別，於是這也跟實際庫存業務不相符。但既然用了“集採”的單據型別，就意味著Web平臺那邊需要修改。哪知道修改的時候Web平臺因為技術原因一直開不了服務，折騰了大半天才搞定！但就是因為這樣的錯誤，業務在補單的時候提交了非常多的單據，也在系統裡面生成了非常多的自建表垃圾資料。所以還得IT人工在SAP裡面一條一條修正，非常費力。
收貨確認的時候，Web首先會去讀SAP上轉單的庫存，取的是MATDOC這表移動型別為413的記錄，意思是隻取從倉庫庫存轉到銷售訂單庫存的資料。但實際上這個大錯特錯。作為IT人員，永遠不要想著框死限制使用者的操作。所以商務在系統中補單的時候，是各種操作都會出現，比如從銷售訂單庫存轉銷售訂單庫存，從銷售訂單庫存轉倉庫庫存，甚至還有很多衝銷的單據。如果這些都不考慮進去的話，Web上顯示的永遠都是錯的。所以這個介面又得大概，變成了取實時銷售訂單庫存表Mska。問題才徹底得到根絕！
因為開發介面的時候太侷限了，考慮的場景單一，也給後續IT的維護和擴充套件阻礙了不少！
四、採購對賬
既然在發貨簽收的時候採購就做了過賬，所以採購對賬的時候只是就基本上沒有采購啥事兒了，只是生成了對賬單而已。但整個對賬單正確與否直接關係到後續的發票預製。
五、銷售對賬
“貿易通”的銷售對賬事兒也很多。因為收貨確認環境裡就已經做了過賬，所以在對賬的畫面這些記錄的狀態都是不對的，過賬會報錯。同時更搞的是一旦碰到月初補單，而財務未完成月結未開賬就會出現Web上收貨確認到系統中只是做了一個交貨單建立而已，實際上連過賬都過不了，而對賬的這個畫面的記錄狀態自然也都是錯的，經常會提示簽收單修改失敗或開票失敗等情況。對賬畫面本身也有缺陷，並沒有考慮到月初補單的情況，也會出現賬期未開的報錯。還得讓使用者手動去修改交貨單裡面的實際交貨日期，再過賬，這個是很不對的操作方式。
因為“集採”/“貿易通”的對賬程式存在跟業務不符的情況，比如把倉庫發貨到客戶的環節（S5）當成是退貨來處理，這點就很匪夷所思了，並沒有測通或者沒有考慮完全的情況，因此依舊會出現對不了賬的情況，甚至還會出現開票金額出現錯誤的情況。
六、介面模式問題
本來SAP提供的RFC是非常完美的跟第三方介面的解決方案，但不知道為何當初乙方顧問就摒棄了RFC模式改為Webservice。導致了現在SAP裡面所有跟Web的介面都整合在一個Webservice地址裡，這樣每修改一次介面（涉及到傳入傳出結構調整），就要釋出一次Webservice，非常的麻煩。而且一旦有兩個開發專案都動用到了介面，因為共用一個Webservice地址的原因，會出現“串位”的情況，給IT的開發和維護帶來超極大的不便麻煩。用RFC通通沒有以上那麼多的原因。
有心推翻現有模式，對SAP來說並沒影響，但Web那邊，就哭天搶地了，無能為力...
以上大概記錄這次“貿易通”專案的開發情況。感慨的是作為IT人員，對解決方案的制定以及業務模式的理解，並完美得落地到系統中並不容易，總是會有遺漏疏漏得地方，就得後期一筆一筆來修復資料，耗費極大的時間。對專案的後期測試尤其重要，多測試幾個場景，不能怕修改，不能怕麻煩，但考慮的地方儘可能周全，也不要抱有希望去限定和框定使用者的操作方式。對使用者的培訓也是至關重要的一個環節，否則資料會產生很多不必要的垃圾。方案制定的人需要具有非常靈敏敏感的頭腦，對介面模式的制定也需要考慮到後續的擴充套件性。就像Webservice的方案，完完全全就是一個糟糕的設計，真心不像是一個乙方顧問應有的專業體現出來的。
