解析ERP系統重新打開訂單的后臺限制

　　在分析某個業務的時候，最重要的就是要了解業務的背景。如果忽略了業務背景，那么設計出來的模型就好像是海市蜃樓，虛無縹緲。為此筆者建議，作為系統分析師，在分析業務需求的時候，一定要講需求回歸到背景中去。或者我們可以把它叫做案例分析題。用戶給出的可能是一個知識點，我們要將其組成一個現實的案例。

　　一般訂單的處理包括兩個階段，分別為訂單的輸入與訂單審核。業務員接到客戶的訂單之后，需要將訂單數據輸入到系統中。然后再由其主管進行審核。當主管在系統中做了審核的操作之后，訂單的數據就不能夠再進行更改。但是在實際過程中，由于各種各樣的原因，仍然需要對已經審核過的訂單進行修改。如業務員在輸入數據的時候，將訂單的數量輸錯了，而主管在審核的時候又沒有發現這個錯誤。或者說，后來由于客戶的原因，更改了訂單的數量或者交起，此時用戶就可能需要更改銷售訂單。在遇到這個情況之后，用戶就會提出需要，要重新打開銷售訂單進行更改。

　　二、重新打開訂單業務的后臺限制解析

　　系統分析師現在需要考慮的就是，是否允許用戶打開已經審核的銷售訂單呢?此時不能夠簡單的回答允許還是不允許。而是要根據實際情況來分析。

　　如在ERP系統中，一般采購需要根據銷售訂單來生成采購訂單。或者說物料計劃部門需要根據銷售訂單來生成物料需求計劃。也就是說，其他部門需要用到銷售訂單中的數據，銷售訂單是系統流程的起源。如果現在其他部門已經根據銷售訂單生成了相關的采購訂單或者物料計劃，在這種情況下，允許業務員對銷售訂單數據的直接更改嗎?答案是否定的。因為在這種情況下，如果還允許更改的話，那么源數據跟后面的紀錄就會對不上。后續在追蹤分析的時候就難以找到責任人。總之，就是某個單據已經生成了后續單據的時候，這個原始單據就不允許重新打開進行更新。

　　但是如果這個銷售訂單剛下，其他部門根據還沒有處理。或者說其他部門在處理之前的審核過程中發現了問題，告知了業務員。在這種情況下是否允許用戶打開訂單來更改呢?一般在這種情況下是允許的。因為沒有關聯紀錄，此時更改源數據不會對其他部門產生連鎖反應。而如果采用其他單據來更改這個訂單信息的話(如通過訂單變更單來更改)，雖然從技術上說是可行的，但是一般沒有這個必要。畢竟在這種情況下，還沒有給企業帶來實質性的損失。而如果通過訂單變更單來更改的話，反而會造成比較多的垃圾數據。所以在這種情況下，才真正的需要重新打開訂單的作業。

　　三、在技術上如何將這種限制落實到實處

　　業務背景了解了，具體的限制也心中有數了，接下去的工作就是需要設計，如何將這種限制落實到實處。雖然說條條道路通羅馬，但是我們在具體實現的過程中，還是需要兼顧成本、效益、安全等原則。

　　以這個“重新打開訂單”的業務來說，從技術上看可以按照如下這個思路進行限制。

　　第一步：可以在訂單級別，設置幾個字段，用來關聯后續的單據。如可以在銷售訂單單頭的數據表中，設置一個“生產計劃”的字段。如果這個字段有相關的內容，則表示這個訂單已經生成了生產計劃。在執行“重新打開訂單”這個業務的時候，就需要先去判斷這個字段的值。如果非空的話，那么就不允許重新打開訂單。相反，如果為空的話，表示沒有后續關聯的單據，則允許用戶打開訂單。如果銷售訂單關聯采購訂單或者關聯出貨單，都可以進行類似的設置。

　　第二步：其他相關聯單據生成的時候，注意需要會寫相關的字段。如現在用戶根據銷售訂單來生成采購計劃。當采購計劃正常生成之后，需要將生成采購計劃的序列號回寫道對應的銷售訂單字段中。只有如此，銷售訂單中這些控制性字段的信息才能夠得到及時更新。“重新打開訂單”作業才能夠根據這些字段來進行作業的控制。

　　第三步：刪除作業時的處理。在實際工作中，還可能會遇到這種情況。如某個銷售訂單中有100個產品。而由于客戶的原因，需要更改其中50個產品的數量。此時對于采購計劃與采購訂單的影響就會比較大。遇到這種情況時，用戶可能寧愿刪掉采購計劃，讓銷售員重新打開銷售訂單更改數量。然后用戶再重新生成采購計劃。遇到這種情況該如何處理呢?這也就是說，當刪除采購計劃的時候，也需要同時清空對應銷售訂單中“采購計劃”這個字段中的值。當這個值變為空之后，“重新打開銷售訂單作業”就可以重新打開銷售訂單，讓用戶進行修改。

　　以上這個步驟，從開發語言上來看，主要就是用來IF判斷語句與Update更新語句。在應用程序開發上，沒有多大的困難。而主要的問題就是，作為系統分析師，要將這些內容一一考慮到。其實系統分析師就好像是一幢大樓的設計人員。而程序開發人員就好像是造房子的人，他們只需要根據設計人員的圖紙來建造即可。系統分析師需要對最后的運行結果負責，開發人員只需要保證在代碼的編寫上不要出現錯誤即可。為此系統分析師在這里起到的作用是非常之大的。

　　其實這個需求還有其他的處理方式。如在執行“重新打開訂單”作業的時候，可以去采購計劃那邊查詢，看看有沒有目標定單的相關信息。從技術上講，這是可行的。但是筆者不建議這么設計。在文章一開頭，筆者談到過系統分析師在分析業務邏輯的時候，需要成本、效益、安全等兼顧。根據上面這種方法，雖然最終可以達到用戶所需要的目標。但是不符合安全、效益的原則。如如果采用第一種方法，即在訂單單頭表中放入控制字段的話，那么就可以從銷售訂單中直接關聯到采購計劃，也就是說可以直接從銷售訂單關聯查詢到采購計劃。而如果采用第二種方式的話，就只能夠實現控制，而不能夠實現關聯查詢的功能。此時在選擇方法的時候，就需要考慮效益原則，而不能夠光考慮目標。簡單的說，就是選擇具體的實現方式時，如果能夠給用戶帶來額外的附帶價值，那是最好的。

服務器租用/服務器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質保障！--億恩科技[ENKJ.COM]