此文章有點長，但是案例非常經典，作者對需求的思考很深入，非常值得一讀。

一. 需求分析

需求前置：每個供應商對應采購訂單都由專屬的采購相關用戶進行。

采購訂單價格來源必須全部來源價目表。

采購訂單的價格修改只能由對應的采購相關用戶才能修改。

部分指定用戶無權修改任何供應商的采購訂單價格。

部分指定用戶有權修改任何供應商的采購訂單價格。

二. 需求實現

2.1. 通過權限控制進行實現

采購訂單價格來源必須全部來源價目表：通過系統參數設置實現，如下圖所示： 

根據每個用戶創建1個用戶角色，對價格修改的供應商進行過濾，將創建很多用戶角色，對每個用戶進行賦權。

創建一個用戶角色禁用修改所有采購訂單價格權限，并對相關人員賦權。

創建一個用戶角色允許修改所有采購訂單價格權限，并對相關人員賦權。

此方案分析：此實現方案需要建立大量的用戶角色，并且后期維護量巨大，不建議。

2.2. 通過權限+實體服務規則進行實現

創建一個用戶角色禁用修改所有采購訂單價格權限，并對相關人員賦權。

創建一個用戶角色允許修改所有采購訂單價格權限，并對相關人員賦權。

實體服務規則實現采購訂單的價格修改只能由對應的采購相關用戶才能修改。

在供應商列表中創建一個字段【維護人#】，用以維護供應商與采購用戶的對應關系。

在采購訂單表頭【供應商】字段增加實體服務規則，供應商維護人與創建人不一致、并且過濾掉可以維護所有價格的用戶，則鎖定價格字段，由于實體服務規則取不到當前單據的操作人，這里只能使用創建人去滿足條件，實體服務規則如下即可實現。

此方案分析：

此方案可以較好的滿足用戶的需求，但是對業務需求的擴展性滿足不足，假如，如果一個供應商后期可以有多個用戶維護，這種需求根本無法滿足，供應商與用戶的對應關系頻繁變化，所有供應商可以維護價格的用戶頻繁變化，則需要從用戶角色、實體服務規則、供應商基礎數據幾個維度去進行修改，維護也是非常不方便。此方案只能滿足當前業務需求，不能滿足業務未來的拓展性，還是不建議。

2.3. 通過二開權限控制基礎表單+二次開發插件實現

權限控制基礎表單設計

表單邏輯：

1.此表單實現了需求中對三種權限的維護。

2.用戶與供應商的對應關系、用戶擁有所有權限、用戶拒絕所有權限三者只能維護其一。

二開插件實現權限控制

在采購訂單上開發插件，實現對采購訂單價格權限的控制，控制邏輯取權限控制基礎表單的邏輯即可。

此方案分析：

此方案通過一個權限控制表單去維護相關的用戶與供應商之家的采購訂單維護價格的關系，然后通過插件開發調用這個權限控制表單的邏輯去實現控制。一是很好的滿足了后期需求的拓展性和維護性，只需要對權限控制表單數據進行更新和維護即可實現業務的變化，是不是這個方案很不錯呢，但是我還是不建議做。

三. 需求深層次分析

大道至簡，道家思講一陰一陽謂之道，對任何事情的思考都要從陰陽兩方面去思考，要從更深層次去進行分析。

3.1. 陽面分析

以上內容根據用戶需求給出了三種解決方案，而且方案三也很完美實現了用戶的需求，滿足了提用戶的人。

3.2. 陰面分析

以上解決方案看似解決了用戶的需求，但是實現用戶的需求之后，又會給其他用戶，甚至業務的流轉帶來什么問題呢？

流程效率下降

專屬采購員綁定供應商的機制可能導致跨部門協作受阻。若專屬采購員請假或離職，訂單處理將因權限真空而停滯，緊急采購可能因審批冗余延誤3-5個工作日，影響供應鏈響應速度。

價格策略僵化

強制依賴價目表會削弱市場議價能力。如遇大宗采購或供應商臨時折扣，采購員無法突破系統價格限制，可能導致企業錯失10%-15%的議價空間，變相推高采購成本。

權限管理復雜度激增

多層級權限配置需持續維護N+供應商與采購員的動態映射關系。IT部門每月需處理N+次權限變更請求，人員轉崗時易出現超權限訪問漏洞，審計顯示錯誤配置率增加，增加合規風險。

四. 總結

此需求是一個很經典的業務通過系統強控的需求，針對用戶提出的此類系統控制性比較強的需求，我們不僅要從戰術層面去思考需求的解決方案，而且要從戰略層面去思考需求相關的業務流程的影響性。