您首先要了解的是发布代码实际上是什么。 基本上，这是打开门的钥匙。

想象一下现在是一栋公寓楼，每间公寓通常都有自己的个人钥匙，即发布代码。

看守服务有一个通用钥匙，一个钥匙可以打开任何门。

现在的问题是，您想给租户什么样的钥匙？

如果每个租户都应该有自己的个人密钥-那么这意味着对于每个发布码1角色

如果所有租户都可以确定每个租户都具有通用密钥-那么您只能创建1个角色并将所有发布代码添加到该角色。

如果没人告诉他们，房客实际上甚至不会意识到这一点。 释放代码是释放事务中的必填字段，不可搜索。 因此，批准者基本上知道告诉他的代码。 如果所有工作都得到批准工作流的支持，并且批准者无需进行常规交易，那就更好了。

实际上，构建角色的团队实际上并不是完全基于购买发布策略的设置而处于主导地位。 如果需要"所有人的通用密钥"，那么可以完全不同地完成整个发行策略的设置。 当然，最好的是，MM顾问对角色创建和他们的公司特定概念有所了解，但是授权团队也可以向MM专家咨询，如果他们了解发布策略的工作原理。 不幸的是，购买发布策略是MM顾问的至高纪律，因此，即使不是MM顾问也很难理解，但是也许它可以帮助您阅读我的博客 https://blogs.sap .com/2015/01/04/purchsing-release-strategy-an-expanded-explanation-and-a-gps-through-scn-and-sap-notes /，以迈入这一步。 p>

你好

请建议您的组织/客户是否为发布采购订单安全性实施了其他措施。

1。 这是唯一的最佳管理方法-通过为每个发布代码和发布组组合创建单个角色吗？

我很想了解它在其他组织中是如何处理的。您在系统中为同一组织有多少个角色。

授权对象M_EINK_FRG

发布代码

发布组

我们不能采用主角色和派生角色的概念，还是可能基于授权组的概念来限制用户，只是想知道吗？

• 感谢Jurgen分享您博客的链接。

这是一个非常庞大且非常详细的博客。我必须阅读不止一次，这样我才能了解它在幕后的工作方式。

我现在已经有了一些了解，并与生产支持团队召开了一次会议，讨论发布策略。我将尝试了解组织中正在遵循的当前策略以及他们是否要更改/优化它。

在目前的一点理解下，我似乎似乎不想触摸/更改它：-）

授权组概念，想知道吗？ 我的意思是通过批评性的授权对象S_TABU_DIS和S_TABU_NAM在授权组级别上限制表。

你好Rizwan，

发布代码和组不是组织字段。 我们可以将它们更改为org字段，但不会减少角色计数。

我们仍然必须为发布代码和发布组的新组合创建一个新角色。

您能解释一下在这种情况下我们如何利用授权组的概念吗？