使用する
以前のリリースでは、IDocタイプを定義するためにさまざまなメソッドが使用されていました。特に拡張機能に関しては、大きな違いがあり、処理時にこれらを考慮する必要があります。
-
リリース2.1/2.2
これらのリリースには、基本タイプの拡張機能がありませんでした。つまり、各IDocタイプ(当時は中間構造と呼ばれていました)も基本タイプであり、DOCTYPフィールドによって識別されました。
-
リリース3.0/3.1
これらのリリースでは、初めて拡張機能(当時は拡張機能タイプと呼ばれていました)が使用されていました。これらの拡張機能は、基本タイプ(当時は基本IDocタイプと呼ばれていました)と組み合わされて、新しいIDocタイプを形成しました。IDOCTYP(基本タイプ)、CIMTYP(拡張)、およびDOCTYP(IDocタイプ)フィールドが識別に使用されました。
-
R/2システム
R / 2システムは、SAPリリース3.0 / 3.1の制御レコードを処理できます。つまり、システムはフィールドIDOCTYP、CIMTYP、およびDOCTYPを認識します。ただし、R / 2システムは拡張機能をサポートしておらず、DOCTYP項目のみを介してIDocタイプを識別します。
リリース4.0以降、IDocタイプはIDOCTYPフィールドとCIMTYPフィールドで識別され、DOCTYPフィールドでは識別されなくなりました。したがって、古いリリースとの通信に新しい拡張機能を使用できるように、異なる識別フィールドを相互に割り当てる必要があります。
特徴
アウトバウンド処理
アウトバウンド処理モジュールは、変換テーブルのIDOCTYPおよびCIMTYPからDOCTYPフィールドを取得します。基本タイプが1つだけ使用されている場合、DOCTYPとIDOCTYPの値は同じです。
パートナープロファイルで指定されたポートによって、IDocの送信先のリリースが決まります(ポート定義のバージョンを介して)。特定のIDocタイプの(リリース固有の)形式(または「レコードタイプ」)は、これらのエントリから派生します。
DOCTYPフィールドが不明な場合、エラー(後続の例外処理を伴う)が発生します。
-
リリース2.1/2.2(ポートバージョン1)およびR / 2システム(ポートタイプ “CPI-C”)
基本タイプが前のIDocタイプ(中間構造)に対応していない場合、処理はエラーで中断されます。基本タイプと拡張機能の組み合わせは、以前のIDocタイプに正確に対応することはできません。ただし、この場合、エラーが返されないように、この割り当てを変換テーブルで定義する必要があります。
-
リリース3.0/3.1またはR/2システム(ポートバージョン2)
基本タイプと拡張子が定義されているが、前のIDocタイプに対応していない場合、処理はエラーで中断されます。
アウトバウンド処理における項目の割当
インバウンド処理
フィールド値が存在しない場合、システムは、DOCTYPからフィールドIDOCTYP、および必要に応じてCIMTYPの値を決定しようとします。これは次のように実行できます。
-
変換テーブルにエントリが存在する場合、そのエントリはIDOCTYP、および必要に応じてCIMTYPを決定するために使用されます。
-
エントリが存在しない場合、IDOCTYPはDOCTYPと同じ値に設定されます。これは、特に、リリース2.1/2.2のSAPシステムからIDocを受信した場合に当てはまります。
使用される基本タイプ(IDOCTYPフィールドから識別される)が定義されていない場合、常にエラーが発生します。拡張機能(CIMTYPフィールド)を基本タイプと組み合わせることができない場合にも、エラーが発生する可能性があります。
活動
次の場合、IDOCTYPおよびCIMTYPをDOCTYPに変換する必要があります。
-
リリース3.0/3.1のSAPシステムと通信しています。
-
あなたまたはあなたのビジネスパートナは、古いリリースステータスのEDIサブシステムを使用しています。
-
リリース2.1/2.2のSAPシステム、または拡張IDocタイプを(以前の中間構造として)定義したR/2システムと通信しています。このケースは非常にまれです。
)を定義したIDocタイプエディタ(トランザクションWE30)で項目を変換することができます。