SAP QM 取消UD方法

2021-07-06 00:07:55 字數 2277 閱讀 5834

一、業務場景

1、  適用業務

通常檢驗批作完檢驗結果錄入後,最後一步就是做ud判斷,這一步的內容主要包括兩方面:選定ud**,表示檢驗將作如何的判定,如a表示接受,r表示拒絕,a1表示讓步接受…;另外就是做庫存轉移,就是將檢驗狀態的庫存移為非限制狀態的庫存(有的企業稱為判良品)或者轉為凍結庫存,甚至如果是破壞性檢驗還要做樣品消耗過賬,當然有的企業還可以做物料降級使用(即309移動)。實質上qm真正和後勤其他模組整合的也就是庫存轉移這一步。既然有整合,往往也就很能會出現錯誤,比如在kee專案上生產完工的入庫檢驗(04),當完工報工確認(co11n),系統自動入庫,即產生相應的檢驗批(此時庫存先入為檢驗狀態),品管部再作檢驗,做後續的判定。那麼此時很有可能會發生生產誤報工,而到導致品管也跟著誤操作,事後發現時,只能採用反沖銷的方法解決。問題來了,大家都知道sap的事務通常都有反沖銷的作業,如報工取消co13,物料憑證取消mbst…恰恰ud判定的沒有提供。仔細想想,也是,ud判定本來就如包公判案一樣,潑出去的水且能收回…當然無能如何,人總會有犯錯的時候,估計包公也有辦錯案反悔的時候吧:)。

也許有人會想到直接mbst或作諸如322移動的過賬,這種方法不可行,因為一旦qm質量檢驗啟用,不可以手工作321或322的過賬,會有如下圖錯誤訊息。要想這樣做只能取消啟用qm檢視(不過如果有其他質檢庫存時,還不能取消啟用)。彙總以上方案如下,

1)直接mbst時會有如下錯誤,不可行

2) 也可以不通過mbst而通過mb01、mb31或migo直接沖銷,記得庫存型別的x刪掉,但如果是生產自動完工入庫的則沒法使用,因為需使用co13取消報工和過賬.

3)直接mb1b作322時會有如下錯誤,

4)有一種複雜的方法,就是要先啟用08的檢驗型別,再用344(非限制到凍結)再349(凍結到檢驗),不過這種方法太複雜;

綜上所述,無論哪種方案雖能解決問題,但都有缺陷,不是最完美的解決方案。到sap notes一查,其實sap也提供了相應的解決方案,下面就談談該解決方案是如何取消ud的。

2、  業務流程

流程倒是比較簡單:檢驗結果錄入→ud判定→取消ud判定

3、  舉例

比如在kee專案上生產完工的入庫檢驗(04),當完工報工確認(co11n),系統自動入庫,即產生相應的檢驗批(此時庫存先入為檢驗狀態),品管部再作檢驗,做後續的判定。那麼此時很有可能會發生生產誤報工,而到導致品管也跟著誤操作,事後發現時,只能採用反沖銷的方法解決。

二、操作說明

根據sap notes 74638 和175842的說明,步驟如下,

1、  notes 74638裡的程式zqevac40匯入系統,並啟用,執行如下,

分析一下這個程式,實際上就是取消ud **,並給檢驗批設定取消狀態。

2、  notes 175842的程式rqevac50匯入系統,並啟用,執行如下,

該程式實際上就是做反沖銷憑證的操作,也許有人會有疑問,不是直接mbst不可以嗎,而這支程式就可以?沒錯sap在程式裡做了手腳,主要是下面這段程式,

sap 在過賬前將qm 檢驗型別啟用的變數清空,過賬後又加上,原來在這兒…注:這不會修改質量檢視的資料!!

理論上有了上面兩支程式就足以解決問題,但唯一的缺點是兩支程式是分別執行的,顯得不太友好和專業。需要增強一下。

3、  運用增強qeva0008,在ud介面裡增加取消ud的按鈕,並呼叫上面兩支程式,如下圖,

至此,所有的功能已加好,下面我們來測試一下這個功能的效果,找一筆已經作了ud的檢驗批,ud取消前的狀態如下,

ud取消後的狀態,注意狀態變化,表明是成功執行了,如下圖:

取消performSelector 方法

使用performselector 方法 self performselector selector didrunincurrmodel withobject nil afterdelay 3.0f 取消 nsobject cancelpreviousperformrequestswithtarge...

sql中取消主鍵方法

declare name sysname declare tb name sysname set tb name rmsorganization 填寫表名 select top 1 name name from sys.objects with nolock where type desc prim...

gulp babel 取消嚴格模式方法

最近專案決定用es6語法重構,於是引入了gulp babel去編譯es6。問題來了,babel編譯es6會自動新增 use strict 在js檔案的最前面,這就導致之前的專案檔案很多都報錯。因為之前的 都編寫的比較隨意,比如var忘了加,還有一些嚴格模式中不准使用的語法,比如arguments.c...