5. パンチアウトトランザクション

パンチアウトを使用すると、購買アプリケーションのユーザーは、サプライヤの Web サイト上の製品またはサービスに対するサプライヤ契約にアクセスできます。これにより、サプライヤはバイヤー企業にカタログ全体を送信する必要がなくなります。その代わりにサプライヤは、扱う分野、製品カテゴリ、または製品を示す短いインデックスファイルのみを送信します。

5.1 パンチアウトの必要条件

5.1.1 バイヤー企業
5.1.1.1 ビジネス上の問題
5.1.1.2 技術上の問題
5.1.2 サプライヤ
5.1.2.1 ビジネス上の問題
5.1.2.2 技術上の問題
5.1.2.3 作業見積り
5.1.2.4 XML の理解

5.2 パンチアウトイベントの流れ

5.2.1 手順 1 および 2: パンチアウト要求
5.2.2 手順 3: 製品の選択
5.2.3 手順 4: チェックアウト
5.2.4 手順 5: 注文書の送信

5.3 パンチアウトドキュメント

5.3.1 パンチアウトインデックスカタログ
5.3.1.1 インデックスカタログの作成と公開
5.3.1.2 パンチアウト品目の詳細度
5.3.2 PunchOutSetupRequest
5.3.2.1 create、edit、inspect および source operation
5.3.2.2 ネットワークハブによる認証
5.3.2.3 SupplierSetup URL および SelectedItem
5.3.2.4 ユーザー識別のための Contact データおよび Extrinsic データ
5.3.3 PunchOutSetupResponse
5.3.4 PunchOutOrderMessage

5.4 サプライヤの Web ページに対する変更

5.4.1 初期ページ
5.4.2 開始ページ
5.4.3 送信者ページ
5.4.3.1 HTTP フォームのエンコード
5.4.3.2 パンチアウトのキャンセル
5.4.4 オーダー受信ページ

5.5 パンチアウト Web サイトに関する提案

5.5.1 導入のガイドライン
5.5.2 バイヤークッキーとサプライヤクッキー
5.5.3 個別化

5.6 パンチアウトトランザクション

5.6.1 ソーシング
5.6.2 PunchOutSetupRequest
5.6.2.1 ヘッダー
5.6.2.2 PunchOutSetupRequest
5.6.2.3 BuyerCookie
5.6.2.4 BrowserFormPost
5.6.2.5 Extrinsic
5.6.2.6 SelectedItem
5.6.2.7 SupplierSetup
5.6.2.8 ShipTo
5.6.3 PunchOutSetupResponse
5.6.3.1 StartPage
5.6.4 PunchOutOrderMessage
5.6.4.1 BuyerCookie
5.6.4.2 PunchOutOrderMessageHeader
5.6.4.3 空のショッピングカート
5.6.4.4 ItemIn

5.7 ダイレクトパンチアウト

5.7.1 認証方法
5.7.2 ProfileResponse

5.1 パンチアウトの必要条件

パンチアウトのためにバイヤー企業が購買アプリケーションを設定する前に、またはサプライヤがパンチアウト Web サイトを導入する前に、両者はパンチアウトの利点と必要条件について審査する必要があります。

5.1.1 バイヤー企業

パンチアウト可能なサプライヤが cXML 互換の購買アプリケーションを設定およびテストするには、1 日もかかりません。したがって、その規模や技術レベルにかかわらず、バイヤー企業にとってパンチアウトは優れたソリューションです。パンチアウトの使用については、商慣行と購入する商品の種類に基づいて判断する必要があります。

5.1.1.1 ビジネス上の問題

バイヤー企業は、Index や Contract ドキュメントなどの静的なカタログコンテンツを使用するか、あるいはパンチアウトを使用するかを決定する際に、次の質問を検討する必要があります。

  • 購入申請者と承認者は、インターネットにアクセスできるか。できない場合、インターネットへの管理されたアクセスならば許可されるか。
  • バイヤー企業は、サプライヤにカタログコンテンツ (価格設定を含む) の作成および保守を望むか。
  • 購入申請者は、現在インターネットで商品の購買を行っているか。行っている場合、これらの商品にはサプライヤ側の設定ツールが必要か。または、これらの商品には静的なコンテンツモデルに適合できない固有の属性があるか。
  • バイヤー企業は、カタログ用のコンテンツアグリゲータ (たとえば、Aspect、TPN Register、または Harbinger) を使用するか。
  • バイヤー企業は、現在インターネットでサービス (たとえば、コンサルタント、派遣社員サービス、または保守) の購買を行っているか。
  • バイヤー企業は、現在オンラインソーシングを行っているか。

上記の問いのいずれかの答えに「はい」があれば、バイヤー企業にとってパンチアウトは適切であるといえます。

5.1.1.2 技術上の問題

バイヤー企業は、以下の技術的な必要条件を満たす必要があります。

  • インターネットへの直接アクセス – バイヤー企業内のユーザーは、インターネットに直接アクセスできる必要があります。ユーザーが動的なサプライヤ Web サイトと対話する場合、パンチアウトは標準の Web ブラウザセッションに依存します。この通信は、通常のイントラネット/インターネットインフラストラクチャで実現するものであり、購買アプリケーションで実現するものではありません。
  • 信頼性の高いインターネット常時接続 – インターネットへのアクセスは常時使用可能で、信頼性の高いものである必要があります。インターネット接続の切断が原因でユーザーが製品を調達できなければ、購買に問題が生じることになります。
  • パンチアウトサプライヤとの契約 – 購買担当者は、パンチアウトが可能なサプライヤと事前に契約を結んでいる必要があります。パンチアウト Web サイトには、既知の認証済みバイヤー企業のみがアクセスできます。

5.1.2 サプライヤ

パンチアウトにおけるサプライヤという用語の定義は、この用語の従来の定義よりも包括的な意味を持ちます。パンチアウトプロトコルは、あらゆるサプライヤ、販売代理店、アグリゲータ (アグリゲータ = サプライヤ集合体)、または製造メーカーから提供される、事実上のあらゆる製品またはサービスに関するデータの転送が可能な、柔軟性のあるフレームワークとして設計されました。製品およびサービスの例には、次のものがあります。

  • 製造メーカーまたはリセラーから直接提供されるコンピュータ
  • アグリゲータから提供される化学薬品および試薬
  • 販売代理店から提供される事務用品
  • 派遣会社から提供される契約サービス

サプライヤは、すでにコンテンツを公開し、注文書を受信できるトランザクション可能な Web サイトを運営している場合があります。サプライヤはこうした機能を前提とした上で、商慣行および技術リソースの両方を検討してパンチアウトの導入を決定する必要があります。

5.1.2.1 ビジネス上の問題

サプライヤは、次の質問について検討する必要があります。

  • サプライヤは、現在、自社の製品またはサービスをインターネットを通じて販売しているか。販売している場合、Webサイトを通じて顧客に固有のコンテンツ (個別契約価格) を提供しているか。
  • サプライヤの提供する製品およびサービスは、パンチアウトカテゴリの 1 つに該当するか。
    • 高度に設定可能な製品 (コンピュータなど)
    • 膨大な取り扱い品目数 (書籍など)
    • 固有の製品属性 (化学薬品など)
    • 規格化されたデータ (MRO 供給品など)
    • 頻繁に変更または増加が発生する品目 (一時的なサービスや書籍など)
  • サプライヤは、受注および (または) 支払いを Web サイト上で行いたいと考えているか。

上記の質問のいずれかの答えに「はい」があれば、サプライヤ組織にとってパンチアウトは適切であるといえます。

5.1.2.2 技術上の問題

サプライヤは、以下の技術的な必要条件を満たす必要があります。

  • 信頼性の高いインターネット常時接続 – Web サーバーのインフラストラクチャとインターネット接続は、きわめて信頼性の高いものである必要があります。リモートのコンテンツにアクセスできない場合、ユーザーは別のサプライヤにアクセスすることになります。
  • 有能な Web サイト管理者 – パンチアウト Web サイトおよびサポートするアプリケーションには、定期的な保守と更新が必要になります。ユーザー側のニーズとサプライヤ側が提供する製品は変化するため、サプライヤのパンチアウトのインフラストラクチャを更新するための要員がサプライヤ側に必要です。
  • 基本的なトランザクションのサポート – パンチアウト Web サイトではすべての cXML 機能をサポートする必要はありませんが、次に示す必須のトランザクションはサポートしなければなりません。
    • プロファイルトランザクション
    • PunchOutSetupRequest
    • PunchOutSetupResponse
    • PunchOutOrderMessage
5.1.2.3 作業見積り

次の表に、サプライヤの見積りに基づく、cXML パンチアウトの統合に必要な作業見積りを表示します。

既存のインフラストラクチャのレベル完了までの見積り時間
cXML の実装とネットワークハブとの連携社内 IT スタッフで 1 ~ 2 週間
コントラクタで 2 ~ 3 週間
XML インフラストラクチャを実装したトランザクション可能なサイト社内 IT スタッフで 3 週間
コントラクタで 3 ~ 4 週間
XML インフラストラクチャを実装していないトランザクション可能なサイト社内 IT スタッフで 4 週間
コントラクタで 4 ~ 5 週間
5.1.2.4 XML の理解

パンチアウトを実装するための第一歩は、XML を理解することです。サプライヤは、パンチアウト Web サイトを導入するために、XML データの作成、構文解析、クエリ、受信、およびリモートソースへの送信方法について基本的に理解している必要があります。XML ドキュメントを処理する基本的なツールは XML パーサーです。これらのパーサーは、Microsoft およびほかの会社から入手できます (たとえば、XML パーサーは Microsoft Internet Explorer 5 に標準で装備されています)。

5.2 パンチアウトイベントの流れ

パンチアウトセッションは、異なるいくつかの手順で構成されます。

5.2.1 手順 1 および 2: パンチアウト要求

ユーザーは、購買アプリケーションにログインして新しい購入申請を開きます。ユーザーは、商品、サプライヤ、または製品説明などでローカルのカタログを検索して、必要な品目を見つけます。ユーザーがパンチアウト品目を選択すると、購買アプリケーションで新しいウィンドウが開き、サプライヤの Web サイトにあるユーザーアカウントにログインします。次の図は、パンチアウト要求手順を示しています。

fig.

図 9: パンチアウト要求手順

動作の仕組み: ユーザーがパンチアウト品目をクリックすると、購買アプリケーションは cXML PunchOutSetupRequest ドキュメントをネットワークハブに送信します。ネットワークハブは信頼のおけるサードパーティとして機能しているため、Request を受け取り、バイヤー企業を認証し、その Request をサプライヤのパンチアウト Webサイトに渡します。

注記
インターネットを経由して送信されるすべての cXML ドキュメントは、SSL (Secure Socket Layer) 3.0 により暗号化された HTTPS 接続で転送されます。

この要求の目的は、サプライヤの Web サイトにバイヤーの識別情報を通知して、実行すべき動作を伝達することです。サポートされる operation には、次のようなものがあります。

  • create – 新しいパンチアウトセッションを開始する
  • edit – パンチアウトセッションを再び開いて編集する
  • inspect – パンチアウトセッションを再び開いて検査する (データの変更は不可)
  • source – ソーシングアプリケーション上の見積依頼 (RFQ) の create/edit セッションのために、パンチアウトセッションを開始する

Request を受け取った後、サプライヤの Web サイトは URL を含む PunchOutSetupResponse を返送します。この URL は、サプライヤの Web サイト上でセッションを開始する先を購買アプリケーションに示すためのものです。購買アプリケーションは、新しいウィンドウを開き、サプライヤの Web サイト上のアカウントにログインしたセッションを表示します。このアカウントは、地域、会社、部門、またはユーザーに固有のものです。ダイレクトパンチアウトはパンチアウトセッションを開始するもう 1 つの方法です。ここではパンチアウト要求がネットワークハブではなくパンチアウトサイトで認証されます。

5.2.2 手順 3: 製品の選択

ユーザーは、サプライヤの Web サイトで提供されるすべての機能とサービスを使用して、商品リストから品目を選択します。

fig.

図 10: パンチアウト製品の選択

製品または顧客により、これらの機能に以下のものを含むことがあります。

  • カスタマイズされた製品 (たとえば、コンピュータ、有機化合物、または個別製品) を構築するための設定用ツール
  • 膨大な数の商品カタログの中から希望の製品を見つけるための検索エンジン
  • 価格、機能、または購入可能情報といった、製品 (たとえば、MRO 製品) を比較するための規格化されたデータ表示
  • 特定の商品 (たとえば、印刷物、化学薬品と試薬、またはサービス) に固有な属性の表示
  • 価格、在庫、および購入可能情報に関するリアルタイムでのチェック
  • 品目の出荷先、サイズ、または数量に基づく税金と送料の自動計算 (パンチアウトセッション中に計算する必要はありません)

動作の仕組み: いったん、購買アプリケーションからサプライヤの Web サイトにアクセスした後は、ユーザーは直接サプライヤの Web サイトにログインしているかのようにショッピングを体験できます。したがって、上記の機能とサービスは何も変更する必要はありません。

5.2.3 手順 4: チェックアウト

サプライヤの Web サイトでは、ユーザーの選択に基づくコスト合計を、税金、送料、および顧客固有の割引などを含めて計算します。次に、ユーザーはサプライヤの Web サイトで [チェックアウト] ボタンをクリックして、ショッピングカートのコンテンツを購買アプリケーション内の購入申請に送信します。次の図は、チェックアウト手順を示しています。

fig.

図 11: チェックアウト手順

動作の仕組み: ユーザーがサプライヤの [チェックアウト] ボタンをクリックすると、自分の購買アプリケーションに HTML フォームが送信されます。1 つのフォームフィールドは、製品の詳細と価格を含む cXML PunchOutOrderMessage で構成されます。さらにサプライヤは、サプライヤクッキーを送信して、後で品目を特定のショッピングセッションと関連付けることができます。これによりサプライヤは要求された品目の見積りを提出したことになりますが、注文書を受信するまではオーダーとして処理することはできません。購入申請の品目を後で編集する必要が生じた場合、ユーザーや承認者によるサプライヤの Web サイトへの再パンチアウトを、サプライヤは許可できます。購買アプリケーションは元のショッピングカートの内容をサプライヤの Web サイトに返送し、ユーザーはそこで更新作業を行うことができます。チェックアウトすると、サプライヤの Web サイトは購入申請に対して更新された品目を返します。サプライヤの Web サイトが、すべてのパンチアウト品目の情報の元となります。数量を変更したり新しい品目を購入申請に追加したりすると、税金または送料が変わることがあります。このような場合、サプライヤの Web サイトで再計算する必要があります。このように、元の品目に対する変更はすべて、購買アプリケーションではなくサプライヤの Web サイトで行わなければならないため、再パンチアウトする必要があります。再パンチアウトは、operation に「edit」が設定された PunchOutSetupRequest になります。

5.2.4 手順 5: 注文書の送信

ショッピングカートの内容がサプライヤの Web サイトからユーザーの購入申請に渡され、続いて購買アプリケーションで承認処理が行われます。承認された購入申請は、購買アプリケーションで注文書に変換され、サプライヤの Web サイトに履行のために返送されます。オーダーとともに P カードデータを転送できます。または、サプライヤはそのオーダーの請求書を個別に送ることもできます。次の図は、注文書の送信を示しています。

fig.

図 12: オーダーの送信手順

動作の仕組み: 購買アプリケーションからネットワークハブに、すべての注文書が cXML フォーマットで送信されます。次に、サプライヤが指定したオーダー通信手段により、それらの注文書がハブからサプライヤに送信されます。サプライヤが注文書の受け取りを確認したときに、オーダーが予約されたことになります。以下の理由により、パンチアウトを実装したサプライヤの最も適したオーダー通信手段は、cXML になります。

  • cXML 注文書により、組み込み型サプライヤクッキー情報がサプライヤに返送されるようになります。サプライヤクッキーのデータ型は「any」であるため、FAX、電子メール、または EDI などのほかのオーダー通信手段では容易にマッピングすることができません。
  • パンチアウトを実装したサプライヤは cXML に熟達しているため、cXML 注文書の受け入れにはそれほど負担がか
    かりません。

5.3 パンチアウトドキュメント

cXML ドキュメントには 4 つの種類があります。

  • パンチアウトインデックスカタログ
  • PunchOutSetupRequest
  • PunchOutSetupResponse
  • PunchOutOrderMessage

パンチアウトインデックスカタログ以外のすべてのドキュメントは、パンチアウトセッション中にサプライヤのパンチアウトサイトとバイヤーの間でデータを送信するときに使用されるため、パンチアウトセッションドキュメントとみなされます。

5.3.1 パンチアウトインデックスカタログ

パンチアウトインデックスカタログは、パンチアウト品目を一覧表示し、サプライヤのパンチアウト Web サイトを示すファイルです。パンチアウトインデックスカタログの例を次に示します。

SupplierID により、サプライヤ組織が識別されます。サプライヤはいずれの ID ドメインでも使用できますが、DUNS (Dun & Bradstreet Universal Naming System) と NetworkID を推奨します。DUNS ナンバーの情報は、 www.dnb.co.jp を参照してください。 punchoutLevel は、サプライヤが購買アプリケーションでパンチアウト品目をどのようにユーザーに提示するかを指定できる任意設定の属性です。この属性には、値 store、aisle、shelf、または product を設定できます。購買アプリケーションでは、サプライヤによるタグ付けに応じてパンチアウト品目の表示方法を変えることができます。たとえば、店舗レベルの品目と製品レベルの品目をそれぞれ異なる方法で表示することができます。Description では、購買アプリケーションで表示する製品カタログのテキストが指定されます。サプライヤは複数の言語で説明を記述でき、購買アプリケーションにはユーザーの地域情報に応じて適切な言語が表示されます。Classification では、バイヤーに品目の商品グループが指定されます。すべてのサプライヤの製品とサービスは、UNSPSC スキーマにマッピングされ標準化されていなければなりません。パンチアウトインデックスカタログでは、ユーザーに表示されるカタログ内のパンチアウト品目の所在地は ClDssificDtion によって指定されます。UNSPSC コードの一覧については、www.unspsc.org を参照してください。

5.3.1.1 インデックスカタログの作成と公開

サプライヤはインデックスカタログを作成し、ネットワークハブ上で顧客に公開します。バイヤー企業内のカタログマネージャは、そのインデックスカタログをダウンロードして、購買アプリケーションで使用できるように、保存します。

ユーザーは、サプライヤのパンチアウトインデックスカタログのコンテンツを、通常の静的なカタログ品目とともに参照できます。

5.3.1.2 パンチアウト品目の詳細度

サプライヤは、店舗レベル、製品群レベル、または製品レベルのカタログを作成できます。

  • 店舗レベルのカタログには、パンチアウト品目 1 つでサプライヤのすべての製品およびサービスを記載することになります。そのためユーザーはサプライヤのサイト内を検索して、目的の品目を見つける必要があります。
  • 製品群レベルのカタログには、関連する製品とサービスに対応した複数のパンチアウト品目を記載することになります。
  • 製品レベルのカタログには、1 つの製品またはサービスのみを記載することになります。そのためユーザーは検索の必要がありません。

パンチアウト品目の対象範囲を決定するには、サプライヤのビジネスモデル、提供する製品およびサービスの構成、およびパンチアウト Web サイトの構造について検討します。サプライヤが自社の Web サイトで提供する検索ツールと設定ツールの数が多ければ多いほど、インデックスカタログの中で定義するパンチアウト品目の対象をより広範なものにできます。

5.3.2 PunchOutSetupRequest

パンチアウトセッションを開始するために、ユーザーはサプライヤのパンチアウト品目を選択します。購買アプリケーションは、PunchOutSetupRequest ドキュメントを生成してそれをネットワークハブに送信します。ハブはそのドキュメントをサプライヤのパンチアウト Web サイトに転送します。 PunchOutSetupRequest ドキュメントの例を以下に示します。

先頭部分にある payloadID と timestamp の属性は、cXML クライアントでドキュメントのトラッキングと重複ドキュメントの検出を行う際に使用されます。 From、To、および Sender の要素によって、受信システムは相手を識別して権限を付与できます。ドキュメント内の From および To 要素は変更されません。ただし、ドキュメントがその宛先に転送されると、中間ノード (Ariba Network など) によって Sender 要素が変更されます。サプライヤがより確実にバイヤー企業を識別できるようにするために、ネットワークハブは From 要素および To 要素内の認証情報ドメインを変更する場合があります。たとえば、From 内で指定される認証情報ドメインが CustomDomain から DUNS に変更される可能性があります。

5.3.2.1 create、edit、inspect および source operation

operation 属性では、バイヤーが開始するセッションの種類が指定します。create、edit、inspect, 、または source を指定できます。

  • create セッションでは、新しい購入申請に対応した新しいショッピングカートが作成されます。
  • edit セッションでは、すでに作成されたショッピングカートまたは見積依頼書 (RFQ) が変更用に再開されます。購買アプリケーションは、明細データを PunchOutSetupRequest の一部として送信します。パンチアウト Web サイトは、このデータに基づいて、元のセッション中に作成されたショッピングカートを再構築します。
  • inspect セッションでは、すでに作成されたショッピングカートまたは見積依頼書 (RFQ) が表示のみの用途で再開されます。edit 操作の場合と同様に、購買アプリケーションは明細データを PunchOutSetupRequest の一部として送信します。ただし、ショッピングカートを再構築した後は、パンチアウト Web サイトはその内容の変更を許可しません。
  • source セッションでは、ソーシングアプリケーション用の見積依頼書 (RFQ) が生成されます。

edit セッションの開始要求の例を以下に示します。

ユーザーがカタログ品目を選択して edit セッションを開始した場合、PunchOutSetupRequest には create セッショ
ンと同様に SelectedItem 要素が含まれます。

5.3.2.2 ネットワークハブによる認証

PunchOutSetupRequest ドキュメントは、認証とサプライヤのパンチアウト Web サイトの URL 参照を行うため、ネットワークハブを経由してルーティングされます。手順は次のとおりです。

  1. ハブがユーザーから PunchOutSetupRequest ドキュメントを受信します。
  2. ハブがバイヤー ID (From および Shared Secret) をそのバイヤーの電子商取引アカウントに基づいて検証します。ハブは要求されたサプライヤ (To) も識別します。
  3. ハブがサプライヤのアカウントから共有シークレットを参照して、その共有シークレット (Shared Secret) を Sender 要素に挿入します。
  4. ハブがサプライヤのアカウントにあるパンチアウト Web サイトの URL を参照して、そこに PunchOutSetupRequest ドキュメントを送信します。
  5. サプライヤの Web サイトが cXML ドキュメントを受信します。サプライヤは、その cXML ドキュメントにサプライヤ自身の共有シークレットが含まれているため、認証されていることが確認できます。
  6. サプライヤの Web サイトが From 要素内の情報に基づいて、要求者を会社レベルで識別します (たとえば、acme.com)。
  7. 要求の本文にある Contact と Extrinsic データを基にして、サプライヤはユーザーを一意に識別できます (たとえば、acme.com における財務部門の John Smith)。

PunchOutSetupRequest ドキュメントと PunchOutSetupResponse ドキュメントは、認証を受けるためにネットワークハブを介します。PunchOutOrderMessage ドキュメント (ショッピングカートの内容を購買アプリケーションに返信します) は、標準の HTML フォームを使用して、サプライヤの Web サイトと購買アプリケーションとの間で直接転送されます。ダイレクトパンチアウトはパンチアウトセッションを開始するもう 1 つの方法です。ここではパンチアウト要求がネットワークハブではなくパンチアウトサイトで認証されます。

5.3.2.3 SupplierSetup URL および SelectedItem

以前の cXML のリリースでは、SupplierSetup 要素が、サプライヤのパンチアウト Web サイトの URL を指定する唯一の方法でした。cXML 1.1 以降、ネットワークハブが、サプライヤのパンチアウト Web サイトの URL に関する情報を保持するようになりました。さらに、cXML 1.1 以降では、購買アプリケーションが SelectedItem 要素を使用して、店舗レベル、製品群レベル、または製品レベルのパンチアウトを指定できるようになりました。現在 SupplierSetup 要素は推奨されていません。しかし、すべてのパンチアウト Web サイトと購買アプリケーションが推奨されない方法を認識し、推奨される方法で SelectedItem 要素を送信するようになるまで、サプライヤのパンチアウト Web サイトは、この 2 つの方法を処理できる必要があります。

5.3.2.4 ユーザー識別のための Contact データおよび Extrinsicデータ

PunchoutSetupRequest ドキュメントの Contact 要素には、サプライヤの Web サイトでユーザーの認証やユーザーへの指示を行うために使用できる、次のような詳細なユーザー情報を含めることができます。

  • ユーザー名とロール
  • 電子メールアドレス

さらに、PunchOutSetupRequest には、サプライヤがユーザーをさらに詳細に特定するために使用できる、次のような Extrinsic データが含まれる場合もあります。

  • ユーザーのコストセンタと勘定下位科目
  • 地域
  • 直属の上司
  • 通常の通貨

バイヤー企業は、購買アプリケーションを設定して、contact と Extrinsic データを挿入します。サプライヤが受信できるデータについては、サプライヤの顧客に問い合わせてください。

5.3.3 PunchOutSetupResponse

PunchOutSetupRequest の受信後、サプライヤの Web サイトは PunchOutSetupResponse を送信します。 PunchOutSetupResponse ドキュメントには、次の 2 つの機能があります。

  • PunchOutSetupRequest の要求が成功したことを示します。
  • 購買アプリケーションに対し、サプライヤの開始ページへリダイレクトする URL を提供します。

これには、対話式ブラウザセッションを行うために、ユーザーの Web ブラウザに通知する開始ページの URL を示す URL要素が含まれます。この URL には、要求者の識別情報や BuyerCookie 要素の内容など、サプライヤの Web サイト上のセッションの状況に関する十分な情報が含まれている必要があります。多くのアプリケーションでは URL の長さに制限を設けているため、この URL に情報をすべて含めるのではなく、状況情報の参照にとどめてください。 PunchOutSetupResponse ドキュメントの例を次に示します。

5.3.4 PunchOutOrderMessage

ユーザーがサプライヤの Web サイト上で品目を選択し、それらの品目を設定してから [チェックアウト] ボタンをクリックすると、サプライヤの Web サイトは PunchOutOrderMessage ドキュメントをバイヤーの購買アプリケーションに送信して、ショッピングカートの内容を通知します。このドキュメントは、どのようなショッピングカートの内容でも完全に表示できるようにするため、ほかのドキュメントよりもかなり多くのデータを持つことがあります。このドキュメントは、Request/Response の仕組みに厳密には従っていません。このことに関しては、後で詳しく説明します。 PunchOutOrderMessage の例を次に示します。

BuyerCookie によって、購買アプリケーションは受信した PunchOutOrderMessage とその発信元 PunchOutSetupRequest を関連付けることができます。したがって、サプライヤの Web サイトは、この要素が含まれる場合は必ず返信してください。BuyerCookie は、create、inspect、および edit のセッションごとに変更されるため、パンチアウトセッションのトラッキングには使用しないでください。SupplierPartAuxiliaryID は、サプライヤクッキーとして機能します。このフィールドを使用して、サプライヤは見積番号または別の cXML ドキュメントなどの追加データを転送できます。購買アプリケーションは、後に続くパンチアウトの edit セッションまたは inspect セッション、および cXML 注文書でサプライヤクッキーをサプライヤに返送します。サプライヤはそのサプライヤクッキーを基にして、購入申請の品目と Web サイトのショッピングカートにある対応する品目を関連付けることができます。

注記
購買アプリケーションでは、SupplierPartAuxiliaryID が品目の一意の識別子の一部として使用される可能性があります。そのため、パンチアウトサイトでは、パンチアウトの edit セッションまたは inspect セッション中にこの値を変更しないでください。

UnitOfMeasure には、製品を梱包して出荷する方法を記述します。

Classification には、選択した品目ごとに UNSPSC (United Nations Standard Products and Services Code) 商品分類コードが一覧表示されます。これらのコードは、バイヤー企業およびサプライヤ組織内で、経理やレポート作成のためにバックエンドシステムで使用されます。UNSPSC コードの一覧については、www.unspsc.org を参照してください。

5.4 サプライヤの Web ページに対する変更

PunchOutSetupRequest、PunchOutSetupResponse、および PunchOutOrderMessage という 3 種類の cXML パンチアウトセッションドキュメントを送受信するために、サプライヤは Web サイト上で、次の 4 つのページを変更または作成する必要があります。

  • 初期ページ
  • 開始ページ
  • 送信者ページ
  • オーダー受信ページ

サプライヤでこれらのページを実装するために、この項では簡単な Active Server Page (ASP) コードと Microsoft Internet Explorer 5 XML パーサーを使用した実例を紹介します。これらのページの実装は、サプライヤの開発環境 (たとえば、CGI、JavaScript、または WebObjects) によって異なります。

5.4.1 初期ページ

初期ページは、すべての認証済み PunchOutSetupRequest ドキュメントをネットワークハブから受信します。初期ページは、ハブから送信される HTTP ストリームを読み取り、そのストリームに埋め込まれた cXML 要求を cXML DTD と対照して検証します (ASP の場合、Internet Explorer 5 XML パーサーを呼び出す方法を使用します)。検証後、サプライヤの初期ページは以下の目的でドキュメントから必要な要素を抽出します。

  1. ユーザーを識別して、そのユーザーをリダイレクトする宛先を決定する。
  2. PunchOutSetupResponse ドキュメントを作成して、それを送信者に返信する。

サプライヤの初期ページは、サプライヤの開始ページで使用できるよう、次のデータを保持する必要があります。

  • 要求者 (Sender) の ID。
  • ユーザーの言語の ID (xml:lang)。これによりサプライヤは、地域情報に適したコンテンツを提供できます。
  • 要求のタイプ (create、edit、または inspect)。
  • ユーザーとユーザーの所在地をより詳細に特定するすべての Extrinsic データ。

初期ページの例を以下に示します。このコードは、XML ツールを使用して PunchOutSetupResponse を動的に生成するのではなく、明細データがあらかじめ埋め込まれた静的な XML テンプレートを使用します。このコードは単に説明用のものです。

(サンプルコード省略)

サプライヤの初期ページは、パンチアウトセッションごとに固有の StartPage URL を返信する必要があります。また、この URL は限られた時間内のみ有効にしておきます。この URL を無効にすることで、権限を持たないユーザーがサプライヤの開始ページにアクセスできないようにします。後に続く edit セッションおよび inspect セッションに必要な機能を、忘れずに実装してください。ユーザーは、購買アプリケーション内で、パンチアウト品目のオーダーの詳細 (数量など) を変更することができません。ユーザーは、edit セッションで再パンチアウトする必要があります。ユーザーの便宜を図るために、サプライヤがオーダーを受信した後に発生する inspect セッションではオーダー状況を表示する必要があります。

5.4.2 開始ページ

要求者は、サプライヤの開始ページを使用してサプライヤの Web サイトのアカウントにログインします。サプライヤの開始ページから、ユーザーはショッピングを開始します。開始ページがすでに存在しているサプライヤの Web サイトでは、 PunchOutSetupRequest ドキュメントからユーザー名とパスワード情報を照会できるように修正します。認証済みユーザーのみが、サプライヤの開始ページに入れるようにします。サプライヤがユーザー認証をチェックアウトの段階まで行わないでいると、価格や条件といった極秘情報を保護できなくなります。サプライヤが HTTP ブラウザクッキーを使用してユーザー設定とセッションをトラッキングする場合、 PunchOutOrderMessage をバイヤーに送信した後は、その HTTP ブラウザクッキーを破棄するようにしてください。クッキーを破棄することで、認証を受けていないユーザーに権限を付与してしまう可能性をなくすことができます。

5.4.3 送信者ページ

送信者ページによって、ユーザーのショッピングカートの内容はユーザーに送信されます。すでに説明したように、ユーザーはショッピングカートに商品を入れた後に、サプライヤの [チェックアウト] ボタンをクリックします。この機能を実現する簡単な ASP の実装を以下に示します。このコードは、XML ツールを使用して PunchOutOrderMessage を動的に生成するのではなく、明細データがあらかじめ埋め込まれた静的な XML テンプレートを使用します。このコードは単に説明用のものです。

これは、サプライヤ Web サイトの製品ページの一部です。

(サンプルコード省略)

AddBuyButton 関数は、PunchOutOrderMessage をユーザーに返送します。次の例は、前の例で参照しているインクルードファイル (punchoutitem.inc) です。

(サンプルコード省略)

AddBuyButton 関数には、URL でエンコードされた PunchOutOrderMessage をユーザーに返す FORM POST が含まれます。

5.4.3.1 HTTP フォームのエンコード

PunchOutOrderMessage を送信するには、サプライヤは HTML フォームのエンコードを行います。これは、従来の HTTP Request/Response モデルとは異なる転送モデルです。この転送によって、サプライヤの Web サイトと購買アプリケーションとの間の統合が、より容易に実現します。さらに、バイヤー企業は、ファイアウォール経由で Web サーバーを使用することなく XML データを受信できるようになります。 PunchOutOrderMessage を購買アプリケーションに直接送信するのではなく、それをサプライヤの Web サイトで HTML フォームの隠しフィールドとしてエンコードし、ユーザーのブラウザから PunchOutSetupRequest の BrowserFormPost 要素で指定された URL に送信します。HTML フォームの隠しフィールドには、cxmlurlencoded または cxml-base64, のいずれかの名前を指定する必要があります (これらの名前は大文字/小文字を区別しません)。上記の例から抜粋した次のコードは、cxml-urlencoded という名前の隠しフォームフィールドを挿入します。このフィールドには POST される PunchOutOrderMessage ドキュメントが含まれます。

このエンコードによってサプライヤは、cXML ドキュメントを隠しフィールドに含むチェックアウト Web ページの設計が可能になります。ユーザーがサプライヤの [チェックアウト] ボタンをクリックすると、ユーザーには見えませんが、サプライヤの Web サイトは HTML フォーム送信によって購買アプリケーションへデータを送信します。

5.4.3.2 パンチアウトのキャンセル

サプライヤは Web ページに [キャンセル] ボタンを追加して、ユーザーがパンチアウトセッションをキャンセルできるように作成できます。[キャンセル] ボタンによって、空の PunchOutOrderMessage が送信されます。この送信によって、品目が返されないことと、購入申請から既存のパンチアウト品目を削除することが購買アプリケーションに指示されます。さらに、サプライヤは [キャンセル] ボタンがクリックされると、ショッピングカートをクリアしたりユーザーセッションを終了したりといった、サプライヤの Web サイトに必要なユーザーセッション管理処理を実行するようにできます。

5.4.4 オーダー受信ページ

オーダー受信ページは、バイヤー企業が送信する cXML 注文書を受け付けます。オーダー受信ページは、前述の初期ページと類似しています。注文書の受信の詳細については、「注文書 [104 ページ]」を参照してください。

5.5 パンチアウト Web サイトに関する提案

この項では、パンチアウト Web サイトの導入を計画する際に検討すべき情報および提案について説明します。

5.5.1 導入のガイドライン

サプライヤがパンチアウト Web サイトを開発する際には、以下のガイドラインに従ってください。

  • 『cXML ユーザーズガイド』 (本ドキュメント) をお読みください。
  • XML パーサーを使用して、ドキュメントが cXML DTD に従っているかを検証します。
  • xml:lang= プロパティを参照してユーザーの言語を識別し、サプライヤが地域情報に合うコンテンツを提供できるようにします。
  • From 認証情報を参照してバイヤー企業を識別します。
  • リダイレクトのセッションに対して、一意で一時的な URL を送信します。
  • ブラウザクッキーに固執しないようにします。
  • Extrinsic データの必要条件によって、顧客に過大な負担をかけないようにします。
  • 各明細に関しては、UNUOM (United Nations Units of Measure) と UNSPSC (United Nations Standard Products and Services Code) を使用します。
  • サプライヤの顧客に、実質的な値を提供します。製品の供給可能性、オーダー状況、および特別な販売促進を表示します。
  • チェックアウトは容易かつ直観的でなければなりません。理想的には、ユーザーは 3 つのボタンをクリックするだけで購入できなければなりません。
  • その後に発生する edit (編集) および inspect (検査) セッションのためにコードを記述します。ユーザーは、購買アプリケーション内で、パンチアウト品目のオーダーの詳細 (数量など) を変更することができません。ユーザーは、edit セッションで再パンチアウトする必要があります。
  • ユーザーの便宜を図るために、inspect セッションではオーダー状況を表示します。
  • サプライヤのパンチアウト Web サイトをテストします。顧客の購買アプリケーションでテストする時間も確保します。
  • パンチアウトトランザクションは、注文書でなく見積りを生成します。cXML の注文書受信ページを実装して、オーダーを受け付けます。

5.5.2 バイヤークッキーとサプライヤクッキー

バイヤークッキーとサプライヤクッキーによって、バイヤーとサプライヤの両者は、各々のバックエンドシステムに対して明細データを再構築できます。

  • サプライヤは、受信した BuyerCookie 要素を返す必要があります。この要素は変更できません。
  • サプライヤクッキー(SupplierPartAuxiliaryID) を利用します。

バイヤークッキーは、購入申請番号に相当します。バイヤークッキーは、バイヤー企業のシステムが購入申請とサプライヤ Web サイトのショッピングカートの関係を保持するための状況情報を伝達します。同様にサプライヤクッキーは、見積番号に相当します。サプライヤクッキーは、サプライヤのシステムがショッピングカートとバイヤーの購入申請および注文書間の関係を保持するための状況情報を伝達します。購買アプリケーションは、後に続くパンチアウトの edit セッションまたは inspect セッション、および注文書でサプライヤクッキーをサプライヤに返送します。サプライヤクッキーを利用することで、サプライヤの Web サイトは、目に見える形でサプライヤ固有のデータをバイヤーに返信する必要がなくなります。

5.5.3 個別化

PunchOutSetupRequest のヘッダーは常にバイヤー企業を識別しますが、その要求に Contact や Extrinsic データ (ユーザーのコストセンタ、ユーザーの所在地、または製品カテゴリなど) が含まれることがあります。サプライヤはこれらのデータを使用して、ユーザーに提供する動的な URL を決定できます。すべてのバイヤー企業がこの Extrinsic データを送信するわけではありませんが、このデータを使用すれば、サプライヤは Web サイトを高度にカスタマイズできます。たとえばサプライヤは、バイヤー企業内のコストセンタごとに (または、製品カテゴリごと、もしくはユーザーごとに)、個別の Web サイトを作成できます。さらにサプライヤは、ユーザーの前回の見積りを保持しておいて表示できます。ユーザーによる見積りの再利用、オーダー状況のチェック、および過去の活動に関するレポートの作成が可能になります。セキュリティを確保するために、見積履歴は個別のユーザーレベルでのみ保持します。計画中に検討すべき重要な事項の 1 つは、動的にカスタマイズされた高度なパンチアウト Web サイトの導入に必要な工数です。サプライヤは、カスタマイズと複雑さとの間でバランスをとる必要があります。複雑な Web サイトは導入と保守に時間がかかりますが、それだけ高い価値をユーザーに提供できます。サプライヤは簡単なパンチアウト Web サイトから開始して、時間の経過とともにその機能を拡張していくことをお奨めします。

5.6 パンチアウトトランザクション

パンチアウトメッセージの定義は、Request 要素および Response 要素内の Request/Response メッセージです。以下のパンチアウトメッセージのすべては、パンチアウトをサポートするために実装されなければなりません。 PunchOutSetupRequest と PunchOutSetupResponse は、リモートシステムへのパンチアウトセッションを確立するために使用される Request/Response のペアです。クライアントはこれらを使用して、購買アプリケーションを特定し、設定情報を送信すると、リモート Web サイトで HTML ブラウズセッションを開始する場所を定義した Response を受信します。パンチアウトトランザクションで、やり取りされる cXML メッセージフローの順序は、次の図のとおりです。

fig.

図 13: パンチアウトトランザクションの cXML メッセージフロー

5.6.1 ソーシング

パンチアウトはソーシングにも使用できます。ユーザーは購買アプリケーションからソーシングアプリケーションにパンチアウトして、見積依頼書 (RFQ) セッションを開始します。ソーシングアプリケーションは、ソーシングアプリケーションの開始ページ URL を含む PunchOutSetupResponse を返します。URL を基に、エンドユーザーはソーシングアプリケーションに移動して、見積依頼書 (RFQ) に対してさらに詳細な設定情報を定義することができます。各ユーザーセッションの終了時に、ソーシングアプリケーションは PunchOutOrderMessage を購買アプリケーションに送信します。そこには、新規の RFQ、既存の RFQ に対する更新情報、または終了した RFQ のいずれかの情報が定義されています。

5.6.2 PunchOutSetupRequest

PunchOutSetupRequest ドキュメントには、Header 要素と PunchOutSetupRequest 要素が含まれます。

5.6.2.1 ヘッダー

Header 要素は、アドレス指定と認証情報で構成されます。PunchOutSetupRequest ドキュメントの Header 要素の例を次に示します。

From

PunchOutSetupRequest の発信元であるバイヤー企業です。

To

PunchOutSetupRequest の宛先となるサプライヤです。

Sender

バイヤー企業の認証の詳細です。これには、Identity、SharedSecret (パスワード)、および AribaNetworkId(Credential domain で指定) などがあります。SharedSecret はサプライヤのパスワードまたはパンチアウトサイトへのログインです。

UserAgent

PunchOutSetupRequest を送信するアプリケーションの一意の識別子です。ソフトウェア会社名、製品名、およびバージョンで構成されます。バージョンの詳細は、カッコ内に表記する場合があります。

5.6.2.2 PunchOutSetupRequest

PunchOutSetupRequest 要素は、Request 要素内に含まれます。次の例は、cXML.dtd の PunchOutSetupRequest の要素宣言を示しています。

PunchOutSetupRequest の例を次に示します。

PunchOutSetupRequest には次の属性があります。

属性説明
operationPunchOutSetupRequest の種類 (「create」、「inspect」、「edit」、または「source」) を指定します。

この要素には、BuyerCookie、Extrinsic、BrowserFormPost、Contact、ShipTo、SelectedItem、SupplierSetup の各要素と ItemOut リスト要素も含まれます。BuyerCookie 要素のみが必須です。Extrinsic要素、Contact, 要素、および ShipTo 要素の構造については、「OrderRequestHeader 要素 [108 ページ]」でより詳細に説明されています。ItemOut 要素については、「ItemOut [133 ページ]」で説明されています。このコンテキスト(OrderRequest 外) では、Distribution 要素と Comments 要素、および ItemOut の lineNumber 属性、 requisitionID 属性、requestedDeliveryDate 属性は値をほとんど追加しないか、まったく追加しないため、含めないようにする必要があります。パンチアウトセッションはオーダーの前に発生するため、この情報は PunchOutSetupRequest 内では関連性がありません。ItemOut リストには、既存のショッピングカートの内容 (以前のパンチアウトセッションの品目) が記述されます。 inspect 操作では、(クライアントとサーバーの両方で実施される) 読み取り専用パンチアウトセッションが開始され、記述されている品目の詳細が表示されます。edit 操作も (ItemOut リストを使用して記述される) 以前のショッピングカートから開始されますが、変更を行うことができます。edit 操作がサポートされることは、inspect もサポートされることを示します (「PunchOutOrderMessageHeader [86 ページ]」および「空のショッピングカート [87 ページ]」を参照)。このリストには、ソーシングされた品目も記述されます。詳細については、「Sourcing [79 ページ]」を参照してください。サプライヤの Credential は、サプライヤがパンチアウト Web サイトの URL を保持できるネットワークハブからパンチアウトの所在地を取得するために使用されます。ネットワークハブは、PunchOutSetupRequest ドキュメントを受信して、サプライヤ ID を読み取り、サプライヤのアカウント情報からパンチアウト Web サイトの URL を検索して、PunchOutSetupRequest ドキュメントをその URL に送信します。パンチアウト Web サイトの URL は、購買アプリケーション内でなくネットワークハブ内で指定するため柔軟性が向上します。PunchOutSetupRequest の SupplierSetup 要素で指定された URL は推奨されません。将来、cXML サーバーはこの要素を無視するようになります。

5.6.2.3 BuyerCookie

この要素は、リモートの Web サイトには不透明な情報を転送しますが、その後に続くすべてのパンチアウト操作のために発信者に返信されなければなりません。この要素によって、購買アプリケーションは未処理の複数のパンチアウト要求を整合させます。BuyerCookie はパンチアウトセッションごとに固有です。

5.6.2.4 BrowserFormPost

この要素は、PunchOutOrderMessage データの送信先です。これには、URL 要素が含まれます。URL 要素の使用に関しては、PunchOutOrderMessage 定義の中でさらに詳しく説明します。URL フォームエンコード方式を使用しない場合、この要素を含める必要はありません。

5.6.2.5 Extrinsic

この任意設定の要素には、要求者が外部の Web サイトに渡す追加データが含まれます。cXML 仕様では、Extrinsic 要素の内容が定義されません。内容については、それぞれの要求者とリモート Web サイトが合意して、実装する必要があります。Extrinsic 要素は、機械が判読できる追加情報を提供するように設計されています。この要素は cXML プロトコルを拡張し、すべての実装にとって必ずしも必要とはならないような機能をサポートします。次のコンテキストでは、新しいデータはパンチアウト要求を開始するユーザーの詳細を表します。

次の例では、パンチアウトを開始するユーザーおよび部門を渡します。

cXML 1.1 以降の Contact 要素では、「CostCenter」および「User」の Extrinsic を使用していません。 Extrinsic 要素は、OrderRequestHeader、ItemDetail、SpendDetail、LaborDetail、および ContractItem 要素に表示される可能性もあります。これらのコンテキストについては、本ドキュメントのほかの箇所でさらに詳しく説明します。

5.6.2.6 SelectedItem

任意設定の SelectedItem 要素を使用して、サプライヤはパンチアウトが店舗全体に対してなのか、一部の提供製品に対してなのかを指定できます。サプライヤは、SelectedItem で店舗レベル、製品群レベル、または製品レベルのパンチアウトか判断できるようにカタログを作成できます。購買アプリケーションでは、PunchOutSetupRequest ドキュメントに SelectedItem 要素を含めることができます。また、パンチアウトサイトでは、この要素を使用してユーザーに表示する製品を特定できます。カタログ内の品目を特定化するほど、サプライヤの Web サイトで検索するユーザーの負担は少なくてすみます。SelectedItem がない場合、サプライヤは提供製品の全体 (店舗レベル) を提示する必要があります。たとえば、SelectedItem に以下のように ItemID が含まれます。

購買アプリケーションは、SelectedItem 要素の内容をパンチアウトインデックスカタログの ItemID (SupplierPartID および SupplierPartAuxiliaryID) から参照します。カタログを変更する必要はありません。購買アプリケーションは、最初に新しい SelectedItem 要素と PunchOutSetupRequest にある古いパンチアウト URL の両方を送信する必要があります。電子商取引ネットワークハブは、パンチアウト URL の宛先をまだ保持していないサプライヤに対してのみ、古い URL を参照します。通常、この要素は create 操作で使用されます。ユーザーがサプライヤのリストから直接パンチアウトできるような購買アプリケーションの場合、SelectedItem を除外しておく必要があります。 edit 操作および inspect 操作の場合、既存の購入申請の品目ではなく、ローカルカタログにある新情報を参照しているときに、ユーザーがサプライヤの Web サイトに戻ることを選択した場合にのみ SelectedItem が表示される必要があります。いずれの場合でも、既存のショッピングカートは ItemOut リスト内に表示される必要があります。 SelectedItem は、source 操作では使用しないでください。

5.6.2.7 SupplierSetup

この任意設定の要素は、PunchOutSetupRequest の送信先 URL を指定します。ネットワークハブがサプライヤのパンチアウト URL を把握している場合は、この要素は必要ありません。

5.6.2.8 ShipTo

この任意設定の要素で、品目の出荷先住所を指定します。サプライヤは配達時間または価格見積りを計算するために、この情報を使用する可能性があります。IDReference 現在は ShipTo の子要素でもある既存の要素です。

5.6.3 PunchOutSetupResponse

リモート Web サイトは PunchOutSetupRequest を受信すると、以下に示すように PunchOutSetupResponse を使用して応答します。

5.6.3.1 StartPage

この要素には URL 要素が含まれます。そこで指定される URL はブラウザに渡され、PunchOutSetupRequest によって要求されるパンチアウトセッションを開始します。この URL には、要求者 ID 情報や適切な BuyerCookie 要素など、リモート Web サイトのセッション状況に関する十分な情報が含まれていなければなりません。ここで、PunchOutSetupRequest を開始したユーザーは、外部の Web サイトを参照して品目を選択します。選択された品目は PunchOutOrderMessage によって購買アプリケーションに返送されます。

5.6.4 PunchOutOrderMessage

この要素は、リモートショッピングカートの内容、またはソーシング見積依頼書 (RFQ) を PunchOutSetupRequest の発信者に送ります。この要素は、外部 Web サイトのショッピングカートの内容がどのようなものでも完全に定義する必要があるため、ほかのメッセージよりもはるかに多くのデータを含めることができるようになっています。このメッセージは、Request/Response モデルに厳密に従っているわけではありません。リモート Web サイトは、ユーザーがチェックアウトしたときに PunchOutOrderMessage を生成します。このメッセージによって、リモートショッピングカートの内容が購買アプリケーションに通知されます。たとえば、次のようになります。

空の PunchOutOrderMessage ドキュメントも可能で、これを利用するとユーザーは品目を選択することなく、パンチアウトショッピングを終了できるようになります。サプライヤは、[キャンセル] ボタンを実装して空の PunchOutOrderMessage ドキュメントを生成できるようにします。これによりパンチアウトサイトと購買アプリケーションの両者は、ユーザーがショッピングセッションをキャンセルしたことを認識し、ショッピングカートを削除して、購入申請から品目を削除するとともに、ほかのユーザーセッション管理処理を実行します。

5.6.4.1 BuyerCookie

この要素の内容は、元の PunchOutSetupRequest 要素で渡された内容と同一です。この要素を返して、購買アプリケーションが PunchOutOrderMessage と元の PunchOutSetupRequest を一致させることができるようにする必要があります。

5.6.4.2 PunchOutOrderMessageHeader

この要素には、転送されるショッピングカートのすべての内容に関する情報が含まれます。必須の要素は、購入申請に追加されている品目の合計コスト (税金と送料を除く) を指定する Total のみです。追加可能な要素は、リモート Web サイトで計算されるすべての送料または税金の合計金額と説明である Shipping と Tax です。ShipTo も任意設定で、ユーザーがリモートサイト上で選択したか、元の PunchOutSetupRequest 内で渡された宛先住所情報が指定されます。すべての通貨情報は、通貨は標準化されたフォーマットで指定される Money 要素内に記述されます。SourcingStatus 要素は任意設定で、ソーシング済みの見積依頼書 (RFQ) に関する更新情報を転送します。この要素の内容には、更新に関するテキスト記述を入れることができます。例えば、実際にユーザーに表示される、状況更新を記述した文字列などを入れることができます。 PunchOutOrderMessageHeader には次の属性があります。

属性説明
operationAllowed後続の PunchOutOrderRequests で許可される操作 (“create”、”inspect”、または “edit”) を指定します。
quoteStatus任意設定の属性で、オーダーが “pending” であるか “final” であるかが指定されます。quoteStatus が “final” であれば、トランザクションは完了します。

operationAllowed 属性によって、この PunchOutOrderMessage で定義されたデータに対してパンチアウトセッションを、ユーザーが後で再開できるかどうかが制御されます。

  • operationAllowed=”create”: これらの品目で後に続くパンチアウトセッションが許可されません。ユーザーはこれらの品目の検査または編集ができません。
  • operationAllowed=”inspect”: これらの品目を検査する際にのみ、後に続くパンチアウトセッションが許可されます。これらの品目の変更はできません。
  • operationAllowed=”edit”: これらの品目を検査および変更する際に、後に続くパンチアウトセッションが許可されます。

quoteStatus 属性は、ソーシング済みの見積依頼書 (RFQ) やその他の処理時間が長い操作を行う際に使用されます。PunchOutOrderMessage には、ソーシングアプリケーションにおけるエンドユーザーセッションの作業結果と見積依頼書 (RFQ) に関する状況更新の情報 (新規 RFQ、更新した RFQ、または完了した RFQ) が含まれます。

5.6.4.3 空のショッピングカート

PunchOutOrderMessage には、サプライヤ Web サイト上のショッピングカートに対応した品目の一覧を含めることができます。これは常に、対話式パンチアウトセッションが終了したことを示します。PunchOutOrderMessage 内に品目がない場合の例をいくつか以下に示します。PunchOutOrderMessage によって、ユーザーがサプライヤ Web サイトをログアウトした後も、クライアントはすぐに対応することができます。

  • オリジナルの PunchOutSetupRequest の operation が inspect である場合、PunchOutOrderMessage の品目リストは購買アプリケーションによって無視される必要があります。この場合、サプライヤサイトは ItemIn 要素を返信しないでください。
  • PunchOutOrderMessage に ItemIn 要素が含まれず、operation が create であった場合は、サプライヤサイトまたはユーザーがショッピングカートを作成せずにパンチアウトセッションをキャンセルしたため、購入申請に品目は追加されません。
  • operation が edit で、PunchOutOrderMessage に ItemIn 要素が含まれなかった場合は、購買アプリケーションによって、このパンチアウトセッションの既存の品目が購入申請から削除されます。

状況コード「204/No Content」は、ショッピングカートが変更されずにセッションが終了したことを示します。このときも PunchOutOrderMessage (常に BuyerCookie で必須) には ItemIn 要素を含めないでください。operation が edit でない限り、このコードは上記で説明した「空」の場合と同様に処理されます。この場合、ユーザーは何の変更もせずにセッションをキャンセルしているため、購買アプリケーションでは購入申請が一切変更されません。

5.6.4.4 ItemIn

この要素では、ショッピングカートの品目が購買アプリケーションの購入申請に追加されます。さまざまな要素を含めることができますが、必須の要素は ItemID および ItemDetail のみです。ItemIn には次の属性があります。

属性説明
quantity(必須)リモート Web サイトでユーザーによって選択された品目数。サプライヤサイトは部分単位のルールを適用することができるため、プロトコルは分数の数量を取り扱うことができます。負の値は使用できません。
openQuantityサプライヤによるバイヤーへの出荷が処理待ちとなっている数量。例: オーダー数量が 100 で、 40 個が配達された場合、未処理数量は 60 です。この数量は、バイヤーによって未配達として記録されます。
promisedQuantityサプライヤによって約束された数量。約束済み数量 (確認済み数量とも呼ばれます) は、サプライヤのバックエンドシステムで「Available To Promise (ATP)」機能に基づいて計算されます。ATPは、バイヤーのオーダーを利用可能在庫またはサプライヤからの確定に基づいて確認できる機能です。
lineNumberオーダーにおける該当品目の位置。通常、パンチアウトセッションはオーダー前に発生するため、またいずれの場合でもサーバーはオーダー内の品目の配置を制御できないため、この属性は PunchOutOrderMessage 内では関連性がありません。
parentLineNumber対応する親明細の明細番号。この属性は、itemType=”item” が設定された明細にのみ適
用できます。
itemType品目の種類を指定します。使用可能な値は次のとおりです。
● composite – 品目グループを識別します。
● item – 独立した明細を識別します。
● lean – 明細で予定されている子品目がないことを示します。
compositeItemType親品目でグループごとの価格設定が使用されるかどうかを指定します。使用可能な値は”groupLevel” または “itemLevel” です。
itemClassification現在の明細が品目とサービスのどちらであるかを指定します。使用可能な値は次のとおりです。
● material
● service
itemCategory構成品目または商品の購買方法を指定します。使用可能な値は次のとおりです。
● materialUnknown – 品目コードを指定しない商品の購買を示します。
● text – 自由記入形式のテキスト項目の購買を示します。
● stockTransfer – あるプラントから別のプラントへの在庫の転送を示します。
● materialGroup – 値または数量を指定しない商品の購買を示します。
● subcontract – 最終製品を製造する契約製造メーカーに構成品目情報を提供して品目
を購買します。
● consignment – バイヤーによって品目またはサービスが消費されるまでサプライヤへの
支払いが保留される特別なプロセスを使用して品目を管理します。
● thirdParty – サードパーティベンダから品目を購買します。
● limit – この品目の対象である計画外サービスまたは品目に想定上の限度があることを
示します。

ItemIn には以下の要素が含まれます。

要素説明
ItemID
(必須)
品目の一意の ID が指定されます。「ItemID [90 ページ]」を参照してください。
Pathパンチアウト連鎖シナリオでユーザーが移動するパスを記録するノードのリストです。「Path 要素 [192 ページ]」を参照してください。
ItemDetail
(必須)
購買アプリケーションでユーザーに提示される品目に関する記述的な情報が含まれます。「ItemDetail [91 ページ]」を参照してください。
SupplierID | SupplierListソーシングプロセスに関与できるサプライヤのリストが指定されます。
● SupplierID はサプライヤの ID です。
● SupplierList には、各サプライヤの Name および SupplierID のリストが
含まれます。
「SupplierID または SupplierList [96 ページ]」を参照してください。
ShipTo品目の出荷先住所です。ShipTo には、4 つの要素(AddressaCarrierIdentifier、TransportInformation、および IdReference) が含まれます。
ShippingcXML 出荷明細の定義です。ショッピングカートの出荷費用を表します。
Tax税に関する情報。
SpendDetail支出詳細情報が取得されます。「SpendDetail [144 ページ]」を参照してください。
Distributionコストセンタまたは総勘定元帳カテゴリなど、バイヤー企業により生成される会計情報です。
Contactサプライヤの連絡先情報です。複数の Contact 要素を指定できます。
Commentsこのオブジェクトに関連するコメントが含まれます。
ScheduleLine明細の配送スケジュールに関する情報が含まれます。
BillTo品目の請求先住所です。
Batchこの明細のバイヤーおよびサプライヤのバッチ情報が記録されます。
Periodサービス明細を実行できる期間です。
DateInfoこの明細に適用できる日付が含まれます。
Extrinsicこの明細に関する追加情報が含まれます。

任意設定の要素は、ShipTo、Shipping、および Tax です。これらの要素は、上記の PunchOutOrderMessage で説明した要素と同じです。さらに、ItemIn には任意設定の SpendDetail, を含めることもできます。この要素には、任意設定の TravelDetail, FeeDetail, LaborDetail, および Extrinsic 要素を含めることができます。TravelDetail では、出張および経費明細に関する詳細な情報が提供され、FeeDetail では、ほかの場所では定義されていない料金に関する情報が提供され、LaborDetail では、臨時社員明細に関する詳細な情報が提供されます。ItemIn と ItemOut 構造は、1 対 1 で対応していますが、Distribution 要素と Comments 要素、およびrequisitionID 属性と requestedDeliveryDate 属性は、ItemOut 要素のみに提供されています。購買アプリケーションでは、inspect 操作または edit 操作を開始するときに、ItemIn リストと ItemOut リストを相互に直接変換できます。サプライヤは edit 操作を実行するときに (ItemOut 要素内で使用されている拡張部分を削除して) 変換できます。購買アプリケーションでは、OrderRequest トランザクションの開始時に直接変換を実行して、出荷先とDistribution 要素の情報およびコメントを追加することができます。ItemIn 要素に含まれる ItemDetail データ(Extrinsic 要素を除く) は、ItemIn から ItemOut に変換されるときに削除されません。ItemIn の例を次に示します。

5.6.4.4.1 ItemID

ItemID 要素により、品目が一意に識別されます。たとえば、この要素でリモート Web サイトへの品目が一意に識別されます。これは、後のパンチアウトセッションで品目を再識別するためにリモート Web サイトに返す必要がある唯一の要素です。ItemID には以下の要素が含まれます。

要素説明
SupplierPartID
(必須)
SupplierPartID は、サプライヤが品目を識別するために使用する ID です。
SupplierPartAuxiliaryIDSupplierPartID で品目が一意に識別されない場合、サプライヤはSupplierPartAuxiliaryID を使用して「補助」キーを指定する必要があります。補助キーを SupplierID および SupplierPartID と組み合わせることで、品目が一意に識別されます。たとえば、サプライヤは、単位が「EA」(個) であるか「BOX」(箱) であるかによって価格が異なる品目に対して、同じ SupplierPartID を使用する場合があります。この場合、この 2 つを識別する適切な SupplierPartAuxiliaryID は「EA」と「BOX」です。SupplierPartAuxiliaryID はサプライヤクッキーとしても使用でき、サプライヤは複雑な設定または品目データを参照できます。この要素には、該当する品目をコンピュータシステム (サプライヤのみに理解できる、ショッピングカートまたはクッキーのデータ)に再構築するために、サプライヤに必要なすべてのデータを含めることができます。「バイヤークッキーとサプライヤクッキー [78 ページ]」を参照してください。 SupplierPartAuxiliaryID は、リモート Web サイトに品目が返信されたときに、品目の複雑な設定または商品の請求情報を再識別する際に役立ちます。SupplierPartAuxiliaryID に特殊文字が含まれる場合 (たとえば、cXML プロトコルで定義されていない特別な XML 要素が含まれる場合)、適切にエスケープする必要があります。アプリケーションを使用して SupplierPartAuxiliaryID 情報をサプライヤに返送する必要があるため、この要素にサプライヤ内部で使用する追加の XML 要素を定義することは不適切です。
BuyerPartIDバイヤーシステム内の品目を表します。この識別子は、バイヤーによって指定されます。
IdReferenceID 参照を定義します。アプリケーションのコンテキスト (バイヤーとサプライヤの特定のペアなど) 内では、(識別子とドメインの) ペアが一意である必要があります。
5.6.4.4.2 ItemDetail

この要素には、購買アプリケーションがユーザーに提示する品目に関する記述的な情報が含まれます。ItemDetail 要素の内容は非常に複雑になる可能性がありますが、最低限の必要条件は簡潔で、UnitPrice、Description、UnitOfMeasure、および Classification のみです。任意設定の要素には、ManufacturerPartID、ManufacturerName、URL、LeadTime、PriceBasisQuantity、Dimension 要素が各 1 つずつと、任意の数のExtrinsic 要素があります。ItemIn 要素のコンテキストでは、ItemDetail 内に含まれる Extrinsic 要素は、インデックス (特に、IndexItemAdd) 内で見つかる要素とまったく同様に機能します。IndexItemAdd 要素では、重複する LeadTime 情報が ItemDetail (任意設定) と IndexItemDetail (必須) の両方から取得される場合があります。LeadTime 要素が両方で定義される場合は、その値を一致させる必要があります。

ItemDetail には以下の要素が含まれます。

要素説明
UnitPrice
(必須)
品目の単位あたりの価格。
Description
(必須)
品目がテキスト形式で記述されます。このテキストは、明細テーブルの制限 (または、その他の制約条件付きユーザーインターフェイス) を超えてしまう場合があり、そのためにランダムな切り捨てが発生する可能性があるため、Description 要素には任意設定の ShortName 要素が含まれます。Description 要素には属性として type 属性が含まれます。type 属性は、消費者またはサプライヤ単位を指定して製品の説明とともに表示されるコードに反映される Description 要素に追加されます。ShortName は、ユーザーに示す製品リストに合わせて、品目を簡単に表現した (推奨 30 文字、最大 50 文字) 名前です。この要素が指定されている場合、クライアントには、フィールドの制限で切り捨てられる可能性がある Description テキストの代わりに ShortName が表示されます。ShortName が指定されていない場合は、クライアントには引き続き切り捨てられる可能性がある Description テキストが表示されます。

例:

ShortName は、スペースが限られている場合は「Big Computer」と表示され、長いテキストを表示するスペースがある場合は「Big Computer: This wonder … lying around.」と表示されます (または、2 つに分割された完全なフィールドで表示されます)。カタログ作成者は、ShortName に Description と同じ情報を指定しないでください。代わりに、ShortName には製品の名称を示し、Description には製品の詳細を記述するようにしてください。CIF 3.0 カタログフォーマットでも、ShortName がサポートされます。CIF のフィールド名は Short Name です。

OverallLimitこの品目の対象であるすべての計画外サービスの合計 (または品目の金額) の上限となる最大値が含まれます。この制限は計画外サービスの予算を表しており、超過してはいけません。この制限は、サービス明細および包括注文書の品目で使用できます。サービス概略レベル (最上位サービス明細) では、このフィールドは、すべての計画外サービスの合計 (または品目の金額) に対する制限を表します。サービス品目レベルでは、下位の制限 (その品目の予算) を表します。

例:

ExpectedLimitこの品目の対象である計画外サービス (または品目) の想定上の上限値が含まれます。このフィールドは、計画値または期待値を表し、主に分析の目的および品目の合計金額の決定時に使用されます。バイヤーは、ExpectedLimit が最終的な支払金額であるとみなします。ExpectedLimit は、最上位サービス品目にのみ指定されます。

例:

UnitOfMeasure
(必須)
製品を梱包または出荷する方法が記述されます。数量単位の共通コードである UN/CEFACT 単位に準拠している必要があります。参照資料 www.unece.org/cefact/codesfortrade/codes_index.html を参照してください。PriceBasisQuantity 明細の数量ベースの価格設定が記述されます。要素として UnitOfMeasure および Description 、属性として quantity および conversionFactor が含まれます。. 「PriceBasisQuantity [356 ページ]」を参照してください。
Classification
(必須)
品目が類似するカテゴリにグループ化されます。通常は、選択した品目ごとに UNSPSC(United Nations Standard Products and Services Code) 商品分類コードが一覧表示されます。これらのコードは、バイヤー企業およびサプライヤ組織内で、経理やレポート作成のためにバックエンドシステムで使用されます。UNSPSC コードの一覧については、www.unspsc.org を参照してください。Classification@domain を使用して、バックエンドシステムで使用される製品階層および商品分類情報を指定することもできます。たとえば、SAP ERP では以下のdomain 値がサポートされています。

● MaterialGroup
● LineOfBusiness
● ProductFamily
● ProductSubFamily
● InternalProgramCode
● ExternalProgramCode
● PartCategory
● PartType

Classification には、指定されたコードで商品分類を識別する任意設定の code属性があります。

ManufacturerPartID品目の製造メーカーが品目を識別する ID です。
URLパンチアウト Web サイトの URL (Uniform Resource Locator) が指定されます。
LeadTimeバイヤーが製品を受け取るまでに必要な日数が指定されます。
例:

Dimension品目の次元が指定されます。「Dimension [182 ページ]」を参照してください。
ItemDetailIndustry業種固有の詳細情報が含まれます。「ItemDetailIndustry [141 ページ]」を参照してください。
AttachmentReferenceリモート添付ファイルへの参照が含まれます。「AttachmentReference [95 ページ]」を参照してください。
PlannedAcceptanceDaysバイヤーがスケジュールした、商品を受け取ってから検査を行うまでの日数が指定されます。
Extrinsicこのオブジェクトに関連するすべての追加情報が含まれます。「Extrinsic [83 ページ]」を参照してください。
5.6.4.4.2.1 AttachmentReference

AttachmentReference には、リモート添付ファイルへの参照が含まれます。この要素には、次の属性があります。

属性説明
length添付ファイルの長さ (バイト) が含まれます。
version外部ソースのバージョンが指定されます。例: “1.0”、”2.4.10″、”Beta”、”V-2″。

AttachmentReference には以下の要素が含まれます。

Name添付ファイルの名前です。
Description添付ファイルの説明です。
InternalID添付ファイルの内部 ID です。現在、InternalID のドメイン属性は任意設定です。循環参照を防ぐために、送信元アプリケーションはドメインの「local」に事前定義された値を使用して、要求された添付ファイルがほかのアプリケーションにはローカルであることを示すことができます。
URLバイヤーのシステム上にある参照されるソースへのリンクです。URL スキームは RFC 1738 (Uniform Resource Locator) に準拠している必要があります。https と http の両方の送信プロトコルがサポートされていますが、最新の TLS が設定された https が推奨されています。
TableTable

次の例は、URL を参照する AttachmentReference を示しています。

5.6.4.4.3 SupplierID または SupplierList

ソーシング済みの見積依頼書 (RFQ) PunchOutOrderMessage では、ItemOut 要素および ItemIn 要素でソーシングプロセスに関与できるサプライヤのリストを指定できます。SupplierID はサプライヤの ID です。SupplierList には、各サプライヤの Name および SupplierID のリストが含まれます。次の ItemOut の例は、2 つのサプライヤの SupplierList を示します。

5.7 ダイレクトパンチアウト

ダイレクトパンチアウトは、サプライヤのパンチアウトサイトの最初のページをユーザーにより早く表示するための cXMLの機能です。PunchOutSetupRequest ドキュメントをクライアントからパンチアウトサイトに直接送信して認証できるようにすることで、パンチアウトセッションが通常のパンチアウトより速く開始されます。認証および転送のためにネットワークハブを経由する必要はありません。サプライヤがダイレクトパンチアウトをサポートしていることを (cXML プロファイルを介して) 示す場合、クライアントはパンチアウト要求を直接サプライヤに送信します。クライアントは、信頼できるサードパーティによって生成されたメッセージ認証コード (MAC) を含めるか、またはデジタル証明書によるクライアント認証を利用可能にすることによって、パンチアウトサイトでこれらの要求を認証できるようにします。

5.7.1 認証方法

ダイレクトパンチアウトを有効にする認証方法は 2 つあります。

  • MAC 認証 [561 ページ] – サーバーは PunchOutSetupRequest ドキュメントにある Sender 認証情報のメッセージ認証コード (MAC) を解読して認証します。
  • Auth トランザクション [565 ページ] – サーバーは、ネットワークハブに対してデジタル証明書によるクライアント認証を要求して認証します。ハブから受け取った認証結果は、後で発生するパンチアウト要求のためにキャッシュします。

サーバーは、cXML プロファイルを介してサポートする認証方法を示します。

5.7.2 ProfileResponse

ProfileResponse ドキュメントに次の任意設定を含むことで、パンチアウトサイトがダイレクトパンチアウトをサポートすること、およびサポートする PunchOutSetupRequest の認証方法を示します。