注:此文是筆者原創(chuàng),首發(fā)于AZSAP第一課堂: https://mp.weixin.qq.com/s/9yuDJohp1iNRR-hHTyT9WQ
專注于為中小企業(yè)提供做網(wǎng)站、網(wǎng)站設(shè)計服務(wù),電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)澄江免費做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都,凝聚了一批互聯(lián)網(wǎng)行業(yè)人才,有力地推動了1000多家企業(yè)的穩(wěn)健成長,幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。
上半年,筆者剛剛加入某運維項目,就接到了該項目客戶中國總部SAP運維部門負責(zé)人的工作分配,說是讓我?guī)兔?yōu)化一只進銷存報表,很可能是需要重新設(shè)計重新開發(fā)。
該項目是一個民營企業(yè)項目,幾年前就已經(jīng)上線了,目前處于運維階段。民營企業(yè)的SAP項目有一個特點,你懂的,就是各種增強開發(fā)很多很多,以至于SAP系統(tǒng)主要被當(dāng)作一個數(shù)據(jù)庫來使用!很多標準的功能沒有被使用,一些標準的function module也被封裝了外殼然后在一些自定義的功能里被使用。像我這種沒有參與前期實施的過程在項目運維幾年后中途加入的外部顧問,進入這個項目立馬就被安排這種對于歷史遺留問題的優(yōu)化任務(wù),真有點掉入大坑兩眼一抹黑的感覺。
怎么辦?我來這里就是要幫助客戶解決問題,為客戶創(chuàng)造價值的,不是來喝茶聊天的。所以,雖然很難搞,也要迎難而上。
既然要優(yōu)化報表,就得要了解現(xiàn)行報表的過去與現(xiàn)狀。
筆者首先與客戶的內(nèi)部顧問了解了一下這個報表的一些情況。經(jīng)過與內(nèi)部顧問的溝通,得知該報表有2個硬傷,第一個硬傷是性能超級慢,基本不堪使用。我測試過了,發(fā)現(xiàn)查詢?nèi)掌诜秶?,即使是昨天到今?天,報表依舊會跑死,報ABAP Runtime Error。這確實不堪使用,讓業(yè)務(wù)部門多難受?。〉诙€硬傷是期末庫存金額與財務(wù)科目余額表里的庫存金額對不上。
然后就是要找到導(dǎo)致報表兩大硬傷的原因。
據(jù)悉,性能慢是因為報表功能過于復(fù)雜以及超大的數(shù)據(jù)量。從報表第一版程序到現(xiàn)在,報表程序被改了無數(shù)次,增加了很多邏輯,功能越來越復(fù)雜。既要能按批次來查詢進銷存,還要能按照存儲地點來查詢;既要查詢庫存數(shù)量,還要計算金額,面積;而其面積的計算,又涉及到物料主數(shù)據(jù)和批次主數(shù)據(jù)里的分類視圖數(shù)據(jù);加上客戶系統(tǒng)里的工廠代碼超過40個,日積月累,貨物移動方面的數(shù)據(jù)量巨大。筆者找了開發(fā)同事幫忙分析代碼,發(fā)現(xiàn)其性能瓶頸之一在查詢批次進銷存數(shù)據(jù)的時候,耗時太多。
為了找到起初期末庫存余額與科目余額表不一致的根本原因,我也找開同事幫忙一起分析代碼。經(jīng)查,該報表是采取倒推方式計算期初庫存,其大致邏輯是首先拿到系統(tǒng)當(dāng)前實時庫存,然后計算當(dāng)前日期與期末日期以及期初日期之間的貨物移動數(shù)據(jù),然后計算出期初期末庫存數(shù)量與金額。同時我們發(fā)現(xiàn),現(xiàn)行報表程序計算庫存余額的時候,僅僅考慮到了貨物移動帶來的庫存價值的變化,卻未能考慮到非貨物移動比如修改物料成本價,比如發(fā)票校驗導(dǎo)致的庫存價值的變化,這是導(dǎo)致庫存余額跟科目表余額差異的原因。
找到了現(xiàn)行報表不堪使用的根本原因之后,筆者開始了報表優(yōu)化的設(shè)計。
首先,我把報表功能進行裁剪,把查詢粒度加大,不再支持按批次按存儲地點級別的進銷存查詢,只在工廠級別出進銷存報表。這樣避免在大數(shù)據(jù)量以及邏輯復(fù)雜的情況下因查詢粒度過細再次出現(xiàn)性能問題。當(dāng)然這些建議需要得到業(yè)務(wù)團隊的認可??蛻魳I(yè)務(wù)團隊因這個報表而受苦久矣,所以對于我提出的這個優(yōu)化建議,對方欣然同意。
其次,我決定采用順推方式得到期末余額,先根據(jù)MBEWH/MSEG/MKPF/BSIM表里抓取到期初余額,然后抓取查詢?nèi)掌诜秶鷥?nèi)貨物移動以及其它事務(wù)代碼導(dǎo)致的庫存變化數(shù)據(jù),計算出期末余額。如果采用倒推方式,可能會出現(xiàn)性能問題,比如業(yè)務(wù)如果想查詢2015-01-01 到2015-01-31 這個期間的進銷存,倒推的方式需要得到當(dāng)前(現(xiàn)在是2018年7月)庫存,然后計算當(dāng)前日期到2015-01-31 這段時間段范圍內(nèi)(三年多的時間范圍)貨物移動金額以及非貨物移動庫存金額差異,然后計算出期末余額,再計算期初余額,無疑這么做在數(shù)據(jù)量大的系統(tǒng)里還是會出現(xiàn)性能慢的問題。而采用順推方式,則先計算出2015-01-01的期初余額,這個可以從一些表里直接抓取數(shù)據(jù),然后查詢一個很小時間段范圍內(nèi)的貨物移動數(shù)據(jù)以及非貨物移動庫存金額差異數(shù)據(jù)就可以得到期初庫存,然后查詢到2015-01-01 到2015-01-31 這一個月時間段里的庫存變化數(shù)據(jù),得到2015-01-31這天的庫存余額。這樣報表程序需要查詢的數(shù)據(jù)量明顯減少,當(dāng)然性能上要好一些。
最后,在計算期初期末余額的時候,要去BSIM表里抓取到非貨物移動導(dǎo)致的庫存價值變化的數(shù)據(jù)。筆者總結(jié)了,需要去BSIM表里抓取憑證類型為ML/PR/RE等的財務(wù)憑證里的金額,按借方和貸方匯總,計入指定查詢?nèi)掌诜秶鷥?nèi)非貨物移動的庫存差異金額欄位,這個欄位參與計算期末余額。同時筆者上網(wǎng)查詢資料得知,一些項目的進銷存報表里,常常因為沒有考慮到這BSIM表里這三種類型的財務(wù)憑證里的金額,導(dǎo)致進銷存報表余額與科目余額表數(shù)據(jù)不一致,看來這是SAP項目實踐中常見問題之一。
在這幾個大的思路的指引下,開發(fā)出來的新的進銷存報表,性能快到讓業(yè)務(wù)人員喜出望外,與財務(wù)科目余額表的數(shù)據(jù)一致也讓財務(wù)業(yè)務(wù)人員不再為進銷存報表而痛心疾首了。