某SAP專案進銷存報表優化小記

該專案是一個民營企業專案，幾年前就已經上線了，目前處於運維階段。民營企業的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專案實踐中常見問題之一。

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