您好Trupti

请按如下所示使用用户出口（LV69AFZZ）。 这是我的有效代码-因为我们隐藏了某些用户的定价条件。

您可以修改此代码以使其符合您的要求。

 FORM userexit_field_modification  。
 如果xkomv-kschl ='您的条件类型'。
     从zsdt_exceptions中选择单个*到wa_exceptions中，其中ernam = sy-uname。
     如果sy-subrc NE 0 AND（屏幕名称='RV61A-SELKZ'
                         或屏幕名称='KOMV-KAWRT'
                         或屏幕名称='RV61A-AWEIN'
                         或屏幕名称='KOMV-KBETR'
                         或屏幕名称='RV61A-KOEIN'
                         或屏幕名称='KOMV-KPEIN'
                         或屏幕名称='KOMV-KMEIN'
                         或屏幕名称='KOMV-KWERT'
                         或屏幕名称='KOMV-KWERT_K'
                         或屏幕名称='KOMV-KUMZA'
                         或屏幕名称='RV61A-MEINS'
                         或屏幕名称='KOMV-KUMNE'
                         或屏幕名称='RV61A-KMEI1'）。
       屏幕激活= 0。
     万一。
 万一。
 ENDFORM。

关于

Venkat

这是否意味着您的问题已通过Venkat发布的代码解决了？

如果是，怎么了？

我 问，因为您将问题设为已回答（这意味着您不 不再需要帮助），但您还说过您正在考虑将SHD0用于

实际上，我认为使用TVARVC来存储授权也不是一个好习惯。

通过TVARVC进行更改的可追溯性受到限制，并且

在我看来，更好的方法是使用自定义授权对象和检查以及PFCG角色-该方法可以使负责授予授权和检查遵从性的同事的工作更具挑战性。

流程更加简单明了，您具有角色有效性，当人们更换职位或承担新职责时，更容易复制设置。 在某些公司中，授予角色是通过工作流程的批准。

对于其余参数，我可能考虑使用SM30视图的自定义表（主要是因为职能顾问应该比 对于特定条件类型，需要将字段设置为只读或可修改的开发人员，因为在整个系统中具有相同的设置是一个好主意），但这实际上取决于业务流程。 到目前为止，十多年来，我只遇到一个案例，即从定价结果中隐藏某些（技术）条件（这就是我认为代码示例所做的事情）具有商业意义。

对用户ID进行硬编码不是最佳实践。 而是在TVARVC中维护所需的变量，并使用用户出口，系统应验证此表并相应地进行操作。 这样，可以避免频繁更改用户ID（如果不为null的话）到最小程度

非常感谢Venkat的回复。

Lakshmipathi-感谢您的建议/看法。

谢谢大家的宝贵意见。

我们已经完成了编码，并且按预期工作。 但是我观察到的是，在项目级别，PR00仍然是可编辑的，并且我们还没有退出，因此它是不可编辑的。

因此，我们正在考虑通过SHD0进行操作并将其分配给用户ID。 这是正确的方法吗？

此致

Trrupti

"我们已经完成了编码，并且按预期工作。但是我观察到的是，在项目级别，PR00仍然是可编辑的，而我们没有 还不能退出，则无法编辑。"

这可能意味着您需要调整代码。 请您的开发人员进行调试，看看为什么PR00的字段仍可编辑。

我希望您也已经从 105621-条件屏幕的授权检查。 如果不是-也许他们可以帮助您找出完全无法正常工作的问题。

对于SHD0-我自己不是开发人员，但是我认为您不能仅设置带有预定义的特定行 条件类型通过屏幕变量为只读，条件屏幕就像一个控件（对于未使用正确的SAP术语表示歉意），我看不到如何通过SHD0添加条件逻辑。

我建议您请主持人在您的问题中添加标签ABAP Development。 毕竟，主要主题是关于自定义代码。 ：）