此文章有点长，但是案例非常经典，作者对需求的思考很深入，非常值得一读。

一. 需求分析

需求前置：每个供应商对应采购订单都由专属的采购相关用户进行。

采购订单价格来源必须全部来源价目表。

采购订单的价格修改只能由对应的采购相关用户才能修改。

部分指定用户无权修改任何供应商的采购订单价格。

部分指定用户有权修改任何供应商的采购订单价格。

二. 需求实现

2.1. 通过权限控制进行实现

采购订单价格来源必须全部来源价目表：通过系统参数设置实现，如下图所示： 

根据每个用户创建1个用户角色，对价格修改的供应商进行过滤，将创建很多用户角色，对每个用户进行赋权。

创建一个用户角色禁用修改所有采购订单价格权限，并对相关人员赋权。

创建一个用户角色允许修改所有采购订单价格权限，并对相关人员赋权。

此方案分析：此实现方案需要建立大量的用户角色，并且后期维护量巨大，不建议。

2.2. 通过权限+实体服务规则进行实现

创建一个用户角色禁用修改所有采购订单价格权限，并对相关人员赋权。

创建一个用户角色允许修改所有采购订单价格权限，并对相关人员赋权。

实体服务规则实现采购订单的价格修改只能由对应的采购相关用户才能修改。

在供应商列表中创建一个字段【维护人#】，用以维护供应商与采购用户的对应关系。

在采购订单表头【供应商】字段增加实体服务规则，供应商维护人与创建人不一致、并且过滤掉可以维护所有价格的用户，则锁定价格字段，由于实体服务规则取不到当前单据的操作人，这里只能使用创建人去满足条件，实体服务规则如下即可实现。

此方案分析：

此方案可以较好的满足用户的需求，但是对业务需求的扩展性满足不足，假如，如果一个供应商后期可以有多个用户维护，这种需求根本无法满足，供应商与用户的对应关系频繁变化，所有供应商可以维护价格的用户频繁变化，则需要从用户角色、实体服务规则、供应商基础数据几个维度去进行修改，维护也是非常不方便。此方案只能满足当前业务需求，不能满足业务未来的拓展性，还是不建议。

2.3. 通过二开权限控制基础表单+二次开发插件实现

权限控制基础表单设计

表单逻辑：

1.此表单实现了需求中对三种权限的维护。

2.用户与供应商的对应关系、用户拥有所有权限、用户拒绝所有权限三者只能维护其一。

二开插件实现权限控制

在采购订单上开发插件，实现对采购订单价格权限的控制，控制逻辑取权限控制基础表单的逻辑即可。

此方案分析：

此方案通过一个权限控制表单去维护相关的用户与供应商之家的采购订单维护价格的关系，然后通过插件开发调用这个权限控制表单的逻辑去实现控制。一是很好的满足了后期需求的拓展性和维护性，只需要对权限控制表单数据进行更新和维护即可实现业务的变化，是不是这个方案很不错呢，但是我还是不建议做。

三. 需求深层次分析

大道至简，道家思讲一阴一阳谓之道，对任何事情的思考都要从阴阳两方面去思考，要从更深层次去进行分析。

3.1. 阳面分析

以上内容根据用户需求给出了三种解决方案，而且方案三也很完美实现了用户的需求，满足了提用户的人。

3.2. 阴面分析

以上解决方案看似解决了用户的需求，但是实现用户的需求之后，又会给其他用户，甚至业务的流转带来什么问题呢？

流程效率下降

专属采购员绑定供应商的机制可能导致跨部门协作受阻。若专属采购员请假或离职，订单处理将因权限真空而停滞，紧急采购可能因审批冗余延误3-5个工作日，影响供应链响应速度。

价格策略僵化

强制依赖价目表会削弱市场议价能力。如遇大宗采购或供应商临时折扣，采购员无法突破系统价格限制，可能导致企业错失10%-15%的议价空间，变相推高采购成本。

权限管理复杂度激增

多层级权限配置需持续维护N+供应商与采购员的动态映射关系。IT部门每月需处理N+次权限变更请求，人员转岗时易出现超权限访问漏洞，审计显示错误配置率增加，增加合规风险。

四. 总结

此需求是一个很经典的业务通过系统强控的需求，针对用户提出的此类系统控制性比较强的需求，我们不仅要从战术层面去思考需求的解决方案，而且要从战略层面去思考需求相关的业务流程的影响性。