該項目是一個民營企業項目，幾年前就已經上線了，目前處于運維階段。民營企業的SAP項目有一個特點，你懂的，就是各種增強開發很多很多，以至于SAP系統主要被當作一個數據庫來使用！很多標準的功能沒有被使用，一些標準的function module也被封裝了外殼然后在一些自定義的功能里被使用。像我這種沒有參與前期實施的過程在項目運維幾年后中途加入的外部顧問，進入這個項目立馬就被安排這種對于歷史遺留問題的優化任務，真有點掉入大坑兩眼一抹黑的感覺。

怎么辦？我來這里就是要幫助客戶解決問題，為客戶創造價值的，不是來喝茶聊天的。所以，雖然很難搞，也要迎難而上。

既然要優化報表，就得要了解現行報表的過去與現狀。

筆者首先與客戶的內部顧問了解了一下這個報表的一些情況。經過與內部顧問的溝通，得知該報表有2個硬傷，第一個硬傷是性能超級慢，基本不堪使用。我測試過了，發現查詢日期范圍，即使是昨天到今天2天，報表依舊會跑死，報ABAP Runtime Error。這確實不堪使用，讓業務部門多難受啊！第二個硬傷是期末庫存金額與財務科目余額表里的庫存金額對不上。

然后就是要找到導致報表兩大硬傷的原因。

據悉，性能慢是因為報表功能過于復雜以及超大的數據量。從報表第一版程序到現在，報表程序被改了無數次，增加了很多邏輯，功能越來越復雜。既要能按批次來查詢進銷存，還要能按照存儲地點來查詢；既要查詢庫存數量，還要計算金額，面積；而其面積的計算，又涉及到物料主數據和批次主數據里的分類視圖數據；加上客戶系統里的工廠代碼超過40個，日積月累，貨物移動方面的數據量巨大。筆者找了開發同事幫忙分析代碼，發現其性能瓶頸之一在查詢批次進銷存數據的時候，耗時太多。

為了找到起初期末庫存余額與科目余額表不一致的根本原因，我也找開同事幫忙一起分析代碼。經查，該報表是采取倒推方式計算期初庫存，其大致邏輯是首先拿到系統當前實時庫存，然后計算當前日期與期末日期以及期初日期之間的貨物移動數據，然后計算出期初期末庫存數量與金額。同時我們發現，現行報表程序計算庫存余額的時候，僅僅考慮到了貨物移動帶來的庫存價值的變化，卻未能考慮到非貨物移動比如修改物料成本價，比如發票校驗導致的庫存價值的變化，這是導致庫存余額跟科目表余額差異的原因。

找到了現行報表不堪使用的根本原因之后，筆者開始了報表優化的設計。

首先，我把報表功能進行裁剪，把查詢粒度加大，不再支持按批次按存儲地點級別的進銷存查詢，只在工廠級別出進銷存報表。這樣避免在大數據量以及邏輯復雜的情況下因查詢粒度過細再次出現性能問題。當然這些建議需要得到業務團隊的認可。客戶業務團隊因這個報表而受苦久矣，所以對于我提出的這個優化建議，對方欣然同意。

其次，我決定采用順推方式得到期末余額，先根據MBEWH/MSEG/MKPF/BSIM表里抓取到期初余額，然后抓取查詢日期范圍內貨物移動以及其它事務代碼導致的庫存變化數據，計算出期末余額。如果采用倒推方式，可能會出現性能問題，比如業務如果想查詢2015-01-01 到2015-01-31 這個期間的進銷存，倒推的方式需要得到當前（現在是2018年7月）庫存，然后計算當前日期到2015-01-31 這段時間段范圍內（三年多的時間范圍）貨物移動金額以及非貨物移動庫存金額差異，然后計算出期末余額，再計算期初余額，無疑這么做在數據量大的系統里還是會出現性能慢的問題。而采用順推方式，則先計算出2015-01-01的期初余額，這個可以從一些表里直接抓取數據，然后查詢一個很小時間段范圍內的貨物移動數據以及非貨物移動庫存金額差異數據就可以得到期初庫存，然后查詢到2015-01-01 到2015-01-31 這一個月時間段里的庫存變化數據，得到2015-01-31這天的庫存余額。這樣報表程序需要查詢的數據量明顯減少，當然性能上要好一些。

最后，在計算期初期末余額的時候，要去BSIM表里抓取到非貨物移動導致的庫存價值變化的數據。筆者總結了，需要去BSIM表里抓取憑證類型為ML/PR/RE等的財務憑證里的金額，按借方和貸方匯總，計入指定查詢日期范圍內非貨物移動的庫存差異金額欄位，這個欄位參與計算期末余額。同時筆者上網查詢資料得知，一些項目的進銷存報表里，常常因為沒有考慮到這BSIM表里這三種類型的財務憑證里的金額，導致進銷存報表余額與科目余額表數據不一致，看來這是SAP項目實踐中常見問題之一。

       在這幾個大的思路的指引下，開發出來的新的進銷存報表，性能快到讓業務人員喜出望外，與財務科目余額表的數據一致也讓財務業務人員不再為進銷存報表而痛心疾首了。