關於銷售訂單的狀態

2021-07-13 04:15:01 字數 2063 閱讀 8305

眾所周知,在sd的流程中,很多處理是跟訂單的狀態息息相關的,比如參照一張銷售訂單來做發貨單的時候,系統需要檢查銷售訂單裡面的交貨狀態是否是a(沒有處理)或者b(部分處理),如果是空白(不相關)或者已經是c(完全處理)了,那麼系統會報錯來通知使用者這張銷售訂單的明細已經不能用來做發貨了。那麼在這篇日誌中,我們就主要討論一下狀態管理中的常見問題。

如果覺得一張銷售訂單的狀態不正確,如何來證實呢?

在標準系統裡有乙個報表叫做sdvbuk00,這個報表是用來修正銷售訂單的錯誤資訊的,在它的執行介面上有乙個專案叫「測試執行未更新」,如果選擇上這個專案,就只會顯示重新計算的狀態,而不會修正。也就是說,我們可以用這個報表來驗證我們的猜想,如果執行結果跟我們的判斷一致,那就可以把專案「測試執行未更新」留空,正式執行這個報表來修正銷售訂單的狀態。還有乙個方法可以重新觸發狀態的再次計算,就是va02修改乙個訂單的時候,選擇專案,轉到-〉專案-〉狀態,然後儲存這張訂單。

需要注意的是sdvbuk00是用來修正某乙個特定的有錯誤的銷售訂單的,這個報表不應該被作為每天執行的報表。

note 67742是關於sdvbuk00的說明文件,如果是出具發票計畫相關的訂單請看note88633,如果是表頭狀態相關的問題,請看一下note84272,如果是不完全狀態,請參照note 88511.

那麼如果sdvbuk00顯示這張訂單的狀態沒有問題,那麼就證明當前的狀態是正確的,就要進一步分析為何系統會計算出這樣的狀態。

debug是分析狀態決定的最好的方式,下面是相關的表和程式:

表vbup 專案狀態

vbuk 表頭狀態

function module:

rv_xvbup_maintain 決定專案狀態

rv_xvbuk_maintain 決定表頭狀態

我們更關注rv_xvbup_maintain,因為表頭的狀態都是各個專案狀態的彙總。

那麼每乙個狀態都有決定它的subroutine,命名規則是

vbup-***xx_ermitteln 是決定專案狀態***xx的subroutine

vbuk-***xx_ermitteln 是決定表頭狀態***xx的subroutine

此篇日誌我們來說一下使用者常見的一些狀態相關的問題以及分析方法。

問題一,為什麼一張銷售訂單專案已經全數發貨,但是發貨狀態(vbup-lfsta)還是未處理?

回答:請開啟銷售訂單,轉到->專案->裝運->

檢查」部分交貨/專案」是否被設定成了」d」. 如果是的話,那麼這個現象就是正常的。

除非設定「拒絕原因」,不然這個專案永遠都不會變成「已完成」。

問題二,我在t-code vov7中更改了專案類別的」出具發票相關」的值,但是舊的銷售憑證還是保留了原來的值,怎麼辦?

回答:在建立訂單的時候,vov7中的值會被拷貝到vbap-fkrel當中並且儲存在資料庫表上。也就是說客戶化的改動是不會影響已經建立的訂單的。

如果先跟更新舊訂單當中的值,請參照note 127514來建立並執行報表zzfkrel0。

請在執行此報表之後執行sdvbuk00以確保訂單中的狀態得到更新。

問題三,當給訂單專案設定拒絕原因以後,我發現不同的訂單的整體狀態和專案狀態有所不同,我希望知道標準系統正常的現象是怎樣的?

回答:「出具發票相關」的值會影響設定拒絕原因以後專案以及訂單的狀態。拒絕原因的定義(t-code ovag)中」blc」的設定也會影響最終結果。

具體請參照note 203182  和 210885。

問題四,我系統裡存在一些銷售訂單,明明後續的交貨和開票都進行完了,整個訂單的狀態還是處理中,為什麼?

回答:最有可能的原因就是使用者錯誤的給訂單中的專案類別設定了「完成規則」。請檢查t-code vov7。

「完成規則」只是為契約型別的訂單,例如**單,數量合同之類的訂單型別設計的,請把銷售訂單中用到的專案型別的「完成規則」設定成空,這樣新建的銷售訂單就不會有問題了。對於舊訂單,請參照note 323048進行修正。

關於銷售訂單的狀態

眾所周知,在sd的流程中,很多處理是跟訂單的狀態息息相關的,比如參照一張銷售訂單來做發貨單的時候,系統需要檢查銷售訂單裡面的交貨狀態是否是a 沒有處理 或者b 部分處理 如果是空白 不相關 或者已經是c 完全處理 了,那麼系統會報錯來通知使用者這張銷售訂單的明細已經不能用來做發貨了。那麼在這篇日誌中...

ecshop訂單 》 訂單狀態

已確認,已發貨,已付款 語言包 訂單狀態 lang os os unconfirmed 未確認 lang os os confirmed 已確認 確認是有效訂單 lang os os splited 已確認 確認收貨 lang os os spliting part 已確認 lang os os c...

詭異的銷售訂單輔助數量

現象 使用者反映說在處理物料搬運單的一筆記錄後,發運事務處理變成了兩筆,如下 搬運單 發運事務處理記錄 物料 請求數量 主單位 輔助請求數量 輔助單位 所以在發運確認時候,無法成功發運確認。提示請求數量0.經過與使用者溝通,並且診斷該筆銷售訂單,重複虛擬操作各種情況,終於重現出該問題。首先物料a設定...