8. パスルーティング

バイヤーとサプライヤの複雑な関係においては、ドキュメントが目的の受信者に届くまでに、いくつかの仲介システムを介してルーティングされる場合があります。パスルーティングを使用すると、マーケットプレイスなどの仲介システムやネットワークハブにドキュメントをルーティングして、コピーできます。

8.1 パスルーティングの概要
8.2 ノード

8.2.1 Path 要素
8.2.2 ルーターノード
8.2.2.1 OriginalDocument
8.2.2.2 DocumentReference
8.2.3 コピーノード

8.3 PunchOutOrderMessage へのノードの追加

8.3.1 Path 要素
8.3.2 認証情報

8.4 OrderRequest の作成

8.4.1 Path 要素
8.4.2 認証情報

8.5 その他のルーティング可能なドキュメント

8.5.1 PunchOutSetupRequest
8.5.2 ConfirmationRequest と ShipNoticeRequest

8.6 CopyRequest

8.1 パスルーティングの概要

直接的なマーケットプレイスでも間接的なマーケットプレイスでも、パスルーティングは非常に役に立ちます。直接的なマーケットプレイスでは、サプライヤはバイヤーに直接請求します。間接的なマーケットプレイスでは、サプライヤはマーケットプレイスホストに請求し、そこから支払いを受けます。そして次に、マーケットプレイスホストは、メンバーのバイヤーに請求し、支払いを受けます。

パンチアウトでのパスルーティング

直接的なマーケットプレイスはパンチアウトサイトになることができ、そこではバイヤーが外部からサプライヤのパンチアウトカタログにアクセスできます。マーケットプレイスは、そこから発生したトランザクションすべてをトラッキングするために、サプライヤにルーティングするすべての注文書のコピーを受け取る必要があります。ルーティングするすべての注文書のコピーを受け取るために、マーケットプレイスは外部バイヤーに送信するすべての PunchOutOrderMessage ドキュメントの Path 要素にマーケットプレイス自身をコピーノードとして追加します。この結果、Path 要素を調べることでショッピングカート内のどの品目が外部のマーケットプレイスからのものであるかを識別できるため、購買アプリケーションからの edit/inspect パンチアウトをマーケットプレイスがサポートできるようになります。間接的なマーケットプレイスは OrderRequest ドキュメントを受信、変更、分割でき、さらにそれをサプライヤにルーティングできます。間接的なマーケットプレイスは、新規バージョンの作成および OrderRequest ドキュメントのサプライヤへのルーティングを行うルーターノードです。

パンチアウトでパスルーティングを行うためには、次の手順を実行します。

  1. サプライヤから購買アプリケーションに送信する PunchOutOrderMessage ドキュメントの Path 要素に、各システムが自身をノードとして追加します。
  2. 購買アプリケーションは、PunchOutOrderMessage ドキュメントの各 ItemIn 要素の Path と SupplierID に基づいてオーダーを分割し、OrderRequest ドキュメントを生成します。購買アプリケーションは、このOrderRequest ドキュメントそれぞれの cXML ヘッダーレベルに、Path 要素を指定します。
  3. OrderRequest、PunchOutSetupRequest、ConfirmationRequest、および ShipNoticeRequest などの後続ドキュメントが、ヘッダーレベルで Path 要素を使用してルーティングおよびコピーされます。

品目またはヘッダーレベルに Path 要素を追加することで、cXML ドキュメントをマーケットプレイスやネットワークハブにコピーしたり、ルーティングしたりできるようになります。Path 要素には、バイヤーとサプライヤ間のパスが記録され、ドキュメントが後でサプライヤに戻されるときに、そのパスが使用されます。

多段階サプライチェーンでのパスルーティング

最終製品の配達に複数の取引先が関係する他段階サプライチェーンでは、エンドツーエンドの表示およびコラボレーションが重要です。したがって、バイヤーとサプライヤは、ほかの段階的サプライヤに、オーダー、オーダー確認、および出荷通知のコピーを送信する必要があります。このために、PunchOutRequestMessage 内で OrderRequest からパスルーティングを直接開始できます。Path 要素にルートノードが含まれていない場合は、オーダー、オーダー確認、および出荷通知のコピーのみが処理されて、サプライヤに送信されます。請求書はルーティングされません。各コピーノードに対してコピー申請が作成されます。コピー申請によって、コピー申請のソースドキュメントのペイロード IDを含む OriginalDocument が追加されます。

8.2 ノード

ノードは、ヘッダーセクションか、ItemIn 要素および ItemOut のいずれかの Path 要素で使用されます。Path 要素内の各ノードは、ルーターノードまたはコピーノードのいずれかにすることができます。ノードが “copy” タイプの場合は、転送される各ドキュメントのコピーが要求されるだけです。ノードが “route” タイプの場合は、転送される各ドキュメントが変更され、再ルーティングされます。パス上の各システムは、自身がどちらのノードであるかを指定する必要があります。

8.2.1 Path 要素

Path 要素には、type=”copy” または type=”route” のいずれかのノードが含まれます。たとえば、次の例には、コピーノードとルーターノードの両方のノードが含まれています。

8.2.2 ルーターノード

ルーターノードは、受信したドキュメントの新規バージョンを作成し、それをパス上の次のノードにルーティングします。ルーティングされるドキュメントは通常、単価、請求先、または出荷先住所の情報が変更されます。

8.2.2.1 OriginalDocument

新しいドキュメントは、元のドキュメントの payloadID を指定するヘッダーレベルに OriginalDocument 要素がまだ提供されていない場合は、この要素を追加することで自身が修正しているドキュメントを参照する必要があります。これにより、ネットワークハブは Path の各経路をトラッキングし、必要な組織にドキュメントのどのバージョンを表示するかを判断できるようになります。

8.2.2.2 DocumentReference

各ノードは、自身が生成した新規ドキュメントのどの DocumentReference 要素に対しても、更新する責任があります。たとえば、update タイプまたは delete タイプの OrderRequest が中間ノードにルーティングされる場合、このノードは、正しい payloadID を参照するように、更新した OrderRequest の新規バージョンの DocumentReference を変更する必要があります。これを次の図に示します。

Fig. to e placed

図 14: 新規ドキュメントでの DocumentReference 要素の更新

8.2.3 コピーノード

コピーノードが、ドキュメントのコピーを申請するシステムとなります。たとえば、以下の抜粋は cXML ヘッダーのいくつかのコピーノードを示しています。これは、多段階サプライチェーンで複数のサプライヤに送信されるコピーとなります。

8.3 PunchOutOrderMessage へのノードの追加

パンチアウトセッションによって生成された PunchOutOrderMessage ドキュメントは、中間サイトを経由してバイヤーに戻ります。各中間サイトは、PunchOutOrderMessage の関連する ItemIn 要素の Path 要素に、自分自身をノードとして追加する必要があります。ノードの順番は元のバイヤーが一番上で、送信順に上から下の順になります。最終サプライヤに最も近い中間ノードは、サプライヤがまだパスを作成していない場合には、記録されたサプライヤもパスに追加する必要があります。購買アプリケーションは、自分自身をパス上の最初のルーターノードとして含める必要があります。これにより、ConfirmationRequest や ShipmentNoticeRequest ドキュメントなどのほかのドキュメントをルーティングして、元のバイヤーに戻すことができます。

8.3.1 Path 要素

Path 要素には、type=”copy” または type=”route” のいずれかのノードが含まれます。Path 要素は、PunchOutOrderMessage の各 ItemIn に含まれます。PunchOutOrderMessage が経由する各システムは、それぞれが管理する各 ItemIn 要素の Path 要素に、自身をノードとして追加する必要があります。次の PunchOutOrderMessage では、Path 要素に 2 つのノードが含まれます。

8.3.2 認証情報

ルーティングされたドキュメントの cXML ヘッダーの From 要素と To 要素は、記録されたバイヤーとサプライヤを参照します。この 2 つの組織を認識するのは 1 つのルーターノードだけであるため、どちらもパスに表示する必要はありません。

8.4 OrderRequest の作成

注文書の生成時に、購買アプリケーションはそれぞれの ItemIn 要素の Path および SupplierID に基づいて購入申請を分割します。

8.4.1 Path 要素

購買アプリケーションは、各オーダーの cXML ヘッダーレベルに Path 要素を挿入します。購買アプリケーションは、 OrderRequest 内のいずれの ItemOut 要素にも、同じ Path 要素を含めることはできません。購買アプリケーションは、パンチアウト品目を含む OrderRequest ドキュメントに、元のバイヤーおよび記録されているサプライヤの両方のノードを含める必要があります。

8.4.2 認証情報

OrderRequest ドキュメントをパス内の次のノードにルーティングするのはネットワークハブであるため、次のノードによる受信時の Sender 認証情報は常にネットワークハブの認証情報になります。直前のノード (最新の発信者) は、From Credential 一覧、またはルーターノードが From 要素を変更していない場合は最新のルーターノードのパスにより、いつでも確認できます。また、type=”marketplace” 認証情報は、パス上のルーターノードの 1 つにする必要があります。From 認証情報一覧に type=”marketplace” 認証情報がない場合は、そのノードが元の購買アプリケーションで
あることを意味します。
次の例は、購買アプリケーションから送信された OrderRequest のヘッダーです。From 認証情報には type=
“marketplace” がないため、この OrderRequest を送信するノードは購買アプリケーションになります。パス上の最
初のノードは、マーケットプレイスルーターノードです。

次の例は、マーケットプレイスルーターノードからの OrderRequest です。

8.5 その他のルーティング可能なドキュメント

PunchOutSetupRequest、ConfirmationRequest、および ShipNoticeRequest などのフォローアップドキュメントも、Path 要素を使用してドキュメントのルーティングおよびコピーを行います。

8.5.1 PunchOutSetupRequest

購買アプリケーションでは、後続の edit または inspect パンチアウトセッションのために ItemOut 要素に同じパス情報を含める必要があります。購買アプリケーションでは、パンチアウトセッション中に Path 要素に基づいて品目をグループ化することはできません。

8.5.2 ConfirmDtionRequest と ShipNoticeRequest

OrderRequest の cXML ヘッダーにある Path 要素を使用して、ConfirmationRequest ドキュメントおよびShipNoticeRequest ドキュメントをルーティングします。ConfirmationRequest や ShipNoticeRequest を元のアプリケーションにルーティングするためには、このパスを逆方向にたどる必要があります。

8.6 CopyRequest

注文書の主要受信者でなくても、注文書のコピーの受信を希望する組織のことをコピー組織と呼びます。これらの組織は、ネットワークハブによって送信された CopyRequest 添付ファイル内の cXML ドキュメントとして注文書のコピーを受信します。コピー組織は CopyRequest トランザクションを自らの cXML プロファイルに追加する必要があります。ネットワークハブは、パスルーティングコピー情報が含まれた注文書を受信すると、まずコピー組織の cXML プロファイルにあるCopyRequest URL を参照します。その後、添付されたドキュメントをコピー組織に送信します。CopyRequest には次の任意設定の属性があります。

属性説明
processingModecXML ドキュメントの処理モードを示します。使用可能な値は次のとおりです。
● info – ドキュメントは情報提供のみです。
● process – ドキュメントの受信者がドキュメントを処理する必要があります。
● copy – ドキュメントは、ソースドキュメントのコピーノード (type=”copy”) を含む
Path 要素の結果としてのコピーです。

CopyRequest 添付ファイルの使用方法が以前の CopyRequest の実装とは異なることに注意してください。以前は cXML ドキュメントは、CopyRequest/cXML 内の内部要素として含まれていました。cXML 1.2.011 では、cXML 要素をcopyRequest の子要素として使用することは推奨されません。代わりに、別の cXML ドキュメントを添付する cXMLAttachment 要素を使用します。この場合、添付ファイル自体が含まれるかどうかは関係ありません。

次の例は、それ自身は添付ファイルを含まない cXML ドキュメントを転送する CopyRequest 要素を示します。