IDocの編集および再処理の権限

Question

既存のIDocの編集および再処理にアクセスすることで、不正な取引のリスクを検討しています。以下のシナリオで

は、次の特性が適用されます。

• ユーザYは、財務部門に所属し、SAPの金融 取引へのアクセス権を持っています。
• ユーザYが（金融取引に関連して）IDOCを登録しました。
• ユーザーXはHR部門に属し、SAPの財務会計へのアクセス権はありません。
• ユーザーXには、IDOCSの変更に対するTコードレベルのアクセス権があります。

私の質問は、これらのシナリオのどれが正しいか、その背後にある技術的な理由は何ですか？

1. IDOC /システム（この場合は：ユーザーY）IDOC作成者の許可をチェックするため、ユーザXは、既存のIDOCを編集し、それが成功し再処理することができます。
2. ユーザーXは既存のIDOCを編集し、を成功裏にに再処理することができます。これは、IDOCがキューにあり、追加の承認を確認しないためです。
3. ユーザXは、既存のIDOCを編集することができますが、IDOC /システムが（このケースでは：ユーザX）のIDOCチェンジャーの許可を検査しているためは、それを再処理することはできません。

Answer 1

IDOCメッセージタイプの権限オブジェクトを登録することができます。したがって、ユーザーは権限のないメッセージタイプを編集または送信することはできません。そうでなければ、ユーザは、1,2または3詳細はこちらですできます。ユーザーXを想定しhttp://sambitsapbasis.blogspot.com.tr/2009/08/special-authorization-object-for-idoc.html

Answer 2

は、Yは、このインバウンドのIDocを受けアウトバウンドのIDocおよびユーザーを作成し、以下の語尾は、あなたのシナリオのための本当のようになります。

あなたが持っている
1. 偽
2. 偽
3. 真

送信者はIDocのプロセッサとはまったく関係がありません。プロセッサの問題。 SAPでもrecommendsを使用して、送信者の権限を最小限に抑え、IDocをバックグラウンドで処理して、追加の権限付与の必要性を排除します。

一般的に、IDocの権限モデルはS_IDOCMONIとS_IDOCCTRLている最も重要なものから、these objectsを中心に実行され、一般的なルールは次のとおりです。

ユーザーが S_IDOCMONIによって制御されたIDocを（DISPLYする権限を持っている場合）、彼はまたそれを送ることができます。

BD87で特定のIDocタイプを表示および処理するように制限する場合は、SAPノート1269516を実装する必要があります。