記一次SAP新業務開發項目

       直到筆者寫這篇博文的時候，這個開發項目名義上已經上線，但其實開發以及優化的工做還在繼續，數據的修復也仍在繼續...

       IT系統環境很簡單，一個基於JAVA+Mysql的Web平臺，一個是宇宙第一的SAP系統，彼此之間用的是Webservice的方式數據對接；

       在此以前，公司的業務形式上都是買進賣出，不留庫存。雖然有一個所謂「集採」的業務，但其實根本沒有在走單，系統能不能走得通都仍是未知數。因而如今又有一個新的業務上來了，買與賣不平衡致使了會有庫存差別，而以前的業務和開發都是基於零庫存的模式下進行。這就意味着以前的業務模式走不通，須要從新設立新的業務場景，作必定程度的開發擴展。由於這個業務跟「集採」有所相似，因此打算大部分沿用「集採」的接口，咱們把它叫作「貿易通」。「貿易通」中採購端與銷售端並無直接的單據關聯（部分），下單，收貨，開單，出貨，對帳等都是獨立的。

        

        開發過程以下：

        1、Web下單時採購價格肯定

        Web調用SAP的接口，利用Bapi生成銷售訂單或採購訂單。可是在採購價格肯定的時候，以前是參考的銷售價，但由於銷售與採購分離，須要Web上指定一個採購價格。可是調用Bapi的時候，總是會出錯，報錯說採購價格必須大於0。看來建立採購訂單的時候系統會去取信息記錄，但是既然用戶指定了採購價格就應該用人工指定的。這個問題偶爾會發現，因而直到上線了也沒根斷。後面常常報錯，我忽然記起來應該是一個加強搞的鬼。那個加強是在採購建立和修改的時候，跟價格有關的就會強制從新訂價，就是這個錯誤。因而把加強去掉，此問題解決。

        我很好奇當初顧問作這個加強的意義在哪裏，並且我也曾經把這個加強給去掉了，現在又冒出來，不解。

         

        2、Web平臺發貨簽收

        Web平臺上對採購作發貨確認，順利經過接口到達SAP作過帳。但問題是生成的Mseg表並無記錄到簽收單號，以致於後面對採購訂單作發票預製的時候會提示找不到入庫憑證而報錯。而以前的零庫存訂單在對帳的時候作過帳，並且系統會記錄這個單號信息。這個問題其實很嚴重，但當初給忽略掉了，由於接口裏沿用的是原來零庫存的業務類別，但這樣會跟實際實物不相符。修改此接口添加相關欄位信息即解決；

 

        3、Web平臺收貨確認

        Web上對銷售作收貨確認的時候，新的單據類型就是直接過帳了，與零庫存的業務在對帳時過帳不一樣。但仍是當初業務模式沒有界定清楚，把單據類型定位零庫存的類型，因而這也跟實際庫存業務不相符。但既然用了「集採」的單據類型，就意味着Web平臺那邊須要修改。哪知道修改的時候Web平臺由於技術緣由一直開不了服務，折騰了大半天才搞定！但就是由於這樣的錯誤，業務在補單的時候提交了很是多的單據，也在系統裏面生成了很是多的自建表垃圾數據。因此還得IT人工在SAP裏面一條一條修正，很是費力。

       收貨確認的時候，Web首先會去讀SAP上轉單的庫存，取的是MATDOC這表移動類型爲413的記錄，意思是隻取從倉庫庫存轉到銷售訂單庫存的數據。但實際上這個大錯特錯。做爲IT人員，永遠不要想着框死限制用戶的操做。因此商務在系統中補單的時候，是各類操做都會出現，好比從銷售訂單庫存轉銷售訂單庫存，從銷售訂單庫存轉倉庫庫存，甚至還有不少衝銷的單據。若是這些都不考慮進去的話，Web上顯示的永遠都是錯的。因此這個接口又得大概，變成了取實時銷售訂單庫存表Mska。問題才完全獲得根絕！

       由於開發接口的時候太侷限了，考慮的場景單一，也給後續IT的維護和擴展阻礙了很多！

       

        4、採購對帳

        既然在發貨簽收的時候採購就作了過帳，因此採購對帳的時候只是就基本上沒有采購啥事兒了，只是生成了對帳單而已。但整個對帳單正確與否直接關係到後續的發票預製。

 

        5、銷售對帳

        「貿易通」的銷售對帳事兒也不少。由於收貨確認環境裏就已經作了過帳，因此在對帳的畫面這些記錄的狀態都是不對的，過帳會報錯。同時更搞的是一旦碰到月初補單，而財務未完成月結未開帳就會出現Web上收貨確認到系統中只是作了一個交貨單建立而已，實際上連過帳都過不了，而對帳的這個畫面的記錄狀態天然也都是錯的，常常會提示簽收單修改失敗或開票失敗等狀況。對帳畫面自己也有缺陷，並無考慮到月初補單的狀況，也會出現帳期未開的報錯。還得讓用戶手動去修改交貨單裏面的實際交貨日期，再過帳，這個是很不對的操做方式。

        由於「集採」/「貿易通」的對帳程序存在跟業務不符的狀況，好比把倉庫發貨到客戶的環節（S5）當成是退貨來處理，這點就很匪夷所思了，並無測通或者沒有考慮徹底的狀況，所以依舊會出現對不了帳的狀況，甚至還會出現開票金額出現錯誤的狀況。

       

       6、接口模式問題

       原本SAP提供的RFC是很是完美的跟第三方接口的解決方案，但不知道爲什麼當初乙方顧問就摒棄了RFC模式改成Webservice。致使瞭如今SAP裏面全部跟Web的接口都整合在一個Webservice地址裏，這樣每修改一次接口（涉及到傳入傳出結構調整），就要發佈一次Webservice，很是的麻煩。並且一旦有兩個開發項目都動用到了接口，由於共用一個Webservice地址的緣由，會出現「串位」的狀況，給IT的開發和維護帶來超極大的不便麻煩。用RFC統統沒有以上那麼多的緣由。

        有心推翻現有模式，對SAP來講並沒影響，但Web那邊，就哭天搶地了，無能爲力...

         

        以上大概記錄此次「貿易通」項目的開發狀況。感慨的是做爲IT人員，對解決方案的制定以及業務模式的理解，並完美得落地到系統中並不容易，老是會有遺漏疏漏得地方，就得後期一筆一筆來修復數據，耗費極大的時間。對項目的後期測試尤爲重要，多測試幾個場景，不能怕修改，不能怕麻煩，但考慮的地方儘量周全，也不要抱有但願去限定和框定用戶的操做方式。對用戶的培訓也是相當重要的一個環節，不然數據會產生不少沒必要要的垃圾。方案制定的人須要具備很是靈敏敏感的頭腦，對接口模式的制定也須要考慮到後續的擴展性。就像Webservice的方案，完徹底全就是一個糟糕的設計，真心不像是一個乙方顧問應有的專業體現出來的。