cXML Reference guide



← cXML リファレンスガイド 目次へ戻る

 この項では、cXML バージョン 1.2.048 以降でで導入された機能について各バージョンごとに説明します。


cXML バージョン 1.2.054

要素/属性 変更内容
ProductActivityHeader processType 属性に値 StockInventory が追加されました。メッセージ:ProductActivityMessage
ReceiptRequestHeader 属性 activityStepType が追加されました。メッセージ:ReceiptRequest
ShipNoticeHeader 属性 activityStepType が追加されました。メッセージ:ShipNoticeRequest

cXML バージョン 1.2.052

要素/属性 変更内容
DTD の変更はありません。

cXML バージョン 1.2.048

要素/属性 変更内容
BlanketItemDetail 次の要素が追加されました。OverallLimit および ExpectedLimit。
メッセージ: OrderRequest
BusinessPartner これは、新しい要素です。これには、品目のビジネスパートナーに関する情報が含まれます。
メッセージ: OrderRequest
ItemIn 次の属性が更新されました。itemCategory。
メッセージ: ConfirmationRequestContractRequest
ItemOut 次の属性が追加または更新されました。itemCategory、stoDelivery、および stoOrderCombination。
メッセージ: OrderRequest
OrderRequestHeader orderType 属性が更新され、新しい値 stockTransportRelease が追加されました。
次の属性が追加されました。isSTPOutbound
次の要素が追加されました。BusinessPartn
メッセージ: OrderRequest



← cXML リファレンスガイド 目次へ戻る

 この項では、cXML バージョン 1.2.048 で導入された機能について説明します。このセクションでは、電子商取引トランザクションで使用する cXML (commerce eXtensible Markup Language) について紹介します。

2.1 XML を実装した cXML

XML (eXtensible Markup Language) はメタマークアップ言語で、文書やデータの構造を記述します。また、XML はアプリケーション間でデータの受け渡しをする際の標準言語で、特にインターネットを経由した通信に使用します。
XML ドキュメントでは、タグと値が対になった形式のデータを記述します。次に例を示します。

<DeliverTo>Joe Smith</DeliverTo>

XML の構造は HTML (HyperText Markup Language) の構造と類似しています。HTML は SGML で定義されたもので、SGML は XML のベースとなったメタ言語です。しかし、XML ドキュメントではすべてのデータがその意味に基づいてタグ付けされているため、HTML ドキュメントと比較して、アプリケーションによるデータの使用と抽出が容易に行えます。XML にはデータ情報しか含まれていませんが、HTML にはデータ情報と表示方法に関する情報の両方が含まれています。各 cXML ドキュメントは、XML DTD (文書型定義) に基づいて作成されます。DTD は、テンプレートとして機能することにより、要素 (element) の正しい順序や入れ子などといった、cXML ドキュメントの内容モデルと属性のデータ型を定義します。cXML 対応の DTD ファイルは、www.cXML.org Web サイトで入手できます。

2.2 cXML DTD

cXML は XML 言語の 1 つであるため、文書型定義 (DTD) によって完全に定義されます。これらの DTD は、cXML 要素の構文と順序を明確に記述したテキストファイルです。アプリケーションは DTD を使用することにより、読み出したり書き込んだりする cXML データを検証できます。各 cXML ドキュメントのヘッダーには、そのドキュメントを定義している DTD の URL が含まれます。cXML アプリケーションはその DTD を入手し、それを使用してドキュメントを検証することができます。トランザクションを最も確実なものにするためには、受信したすべての cXML ドキュメントを検証します。エラーが検出された場合、適切なエラーコードを発行して、送信者が再送信できるようにします。cXML アプリケーションで、受信したすべての cXML ドキュメントを検証しなければいけないわけではありませんが、検証することを推奨します。しかし、すべての cXML ドキュメントは正しく、かつ以下で説明する cXML DTD に準拠している必要があります。

cXML DTD の入手方法

あらゆるバージョンの cXML に対応した DTD は、cXML.org から入手できます。さまざまな種類の cXML ドキュメントが複数の DTD で定義されています。これは、一部のパーサーで高速な検証を可能にするために、サイズを縮小した DTD を使用しているためです。

ここで、version は cXML の完全なバージョン番号です。cXML アプリケーションでは、これらの DTD を使用して、送受信するすべてのドキュメントが検証できます。

DTD のキャッシュ

最高のパフォーマンスを得るためには、cXML アプリケーションは DTD をローカルにキャッシュする必要があります。
cXML の DTD ファイルは公開後に変更されることはないため、期限を設定せずにキャッシュしておくことができます。(DTD は、更新されると新しい URL が割り当てられます。)cXML アプリケーションは、cXML ドキュメントの解析時にドキュメントヘッダーの SYSTEM 識別子を調べ、DTD がまだローカルに格納されていない場合は、その DTD を取得するようにします。ローカルに DTD をキャッシュしておくと、ドキュメントの検証をより高速に行うことができ、cXML.org サイトへのアクセスも減少するという利点があります。環境によっては、cXML アプリケーションが新しいドキュメントを受信する際に、自動的に DTD を取得することが許可されていない場合があります。これらの環境では、DTD を手動で取得してローカルに保存し、cXML.org ではなくローカルの DTD を参照するよう、アプリケーションを設定する必要があります。ただし、cXML ドキュメントを生成する場合は、ローカルの DTD ではなく cXML.org の DTD を参照するようにしておく必要があります。

2.3 対象者および前提条件

本マニュアルは、cXML を使用してアプリケーションを設計するアプリケーション開発者を対象に作成されています。cXML は汎用性のあるオープンスタンダードな言語で、以下のトランザクションで使用します。

  • 電子商取引ネットワークハブ
  • 電子製品カタログ
  • パンチアウトカタログ
  • 購買アプリケーション
  • バイヤー
  • サプライヤ
  • 電子商取引サービスプロバイダ

読者は電子商取引の概念、HTTP インターネット通信規格、および XML 形式に関する実践的な知識が必要です。本マニュアルでは、特定の購買アプリケーションまたはネットワークハブの使用方法については説明しません。

2.4 本マニュアルの文字スタイル

cXML 要素 (element) および cXML 属性は、モノタイプのフォントで表記します。これらの名前には大文字と小文字の区別があります。どちらの名前にも大文字と小文字が混在していますが、要素名は大文字で始まり、属性名は小文字で始まります。たとえば、MyElement は cXML 要素で、myAttribute は cXML 属性です。次の表に、本マニュアルで使用している表記規則を示します。

書体または記号 意味
AaBbCc123 ユーザーが置換しなければならないテキストは等幅のイタリックで表記します。 http://server:port/inspector
AaBbCc123 ユーザーインターフェイスとして表示されるコントロール名、メニュー名、およびメニュー項目名 [ファイル] メニューから [編集] を選択します。
AaBbCc123 ファイル名、ディレクトリ名、パラメータ、CSV ファイルのフィールド、コマンド行、およびコード例 ProfileRequest ドキュメントは、バイヤーからネットワークハブに送信されます。
AaBbCc123 マニュアルのタイトル 詳細については、『Acme 設定の概要』を参照してください。



← cXML リファレンスガイド 目次へ戻る

 この項では、cXML バージョン 1.2.048 で導入された機能について説明します。このセクションでは、cXML の基本プロトコルとデータフォーマットについて説明します。この章には、すべてのトランザクションの実装に必要な情報が記載されています。

3.1 プロトコルの仕様

 cXML トランザクションには、Request/Response モデルと One-Way モデルの 2 つの通信モデルがあります。これら 2つのモデルは操作が厳密に定義されているため、実装は容易に行えます。状況によっては 1 つのモデルで対応できない場合があるため、両方のモデルが必要となります。

3.1.1 Request/Response モデル

 Request/Response トランザクションは、HTTP または HTTPS 接続でのみ実行できます。以下の図は、組織 A と B の間における Request/Response トランザクションの対話の手順を示しています。

図 1: Request/Response トランザクション

このトランザクションは、以下の手順で処理されます。

  1. サイト A は、サイト B のアドレスとして指定されている URL を参照して、サイト B との HTTP/1.x 接続を開始します。
  2. サイト A は、POST 操作を行い、cXML ドキュメントを HTTP 接続経由で送信します。その後サイト A は、Response 待ちとなります。
  3. サイト B の HTTP/1.x 準拠のサーバーは、手順 1 で参照された URL が示すリソースに HTTP Request を送信します。このリソースは、CGI プログラムや ASP ページなどで、サイト B の HTTP サーバーが認識できる有効なネットワーク所在地に存在する必要があります。
  4. 手順 3 で識別されたサイト B のリソースは、cXML ドキュメントの内容を読み取り、その Request を適切なハンドラにマッピングします。
  5. cXML Request に対応するサイト B のハンドラは、その Request に従って処理を行い、cXML Response ドキュメントを生成します。
  6. サイト B は、手順 1 で確立した HTTP 接続により、cXML Response をサイト A に送信します。
  7. サイト A は、cXML Response を読み取り、Request を発信したプロセスにその Request を返します。
  8. サイト A は、手順 1 で確立した HTTP 接続を切断します。

さらに Request/Response サイクルを続行する場合は、このプロセスが繰り返されます。上記手順の作業を単純化するために、cXML ドキュメントは次の 2 つの部分に分割されます。

  • Header – アドレス指定と認証情報で構成されます。
  • Request または Response データ – 特定の要求または応答、およびやり取りされる情報が含まれます。

これらの要素 (element) の両方とも、親エンベロープ要素に入れて転送されます。次の例は、cXML Request ドキュメントの構造を示しています。

<cXML>
 <Header>
 Header information
 </Header>
 <Request>
 Request information
 </Request>
</cXML>

次の例は、cXML Response ドキュメントの構造を示しています。

<cXML>
 <Response>
 Response information
 </Response>
</cXML>

Response 構造では、Header 要素が使用されません。Response は常に Request と同じ HTTP 接続で送信されるため、これは必要ありません。

3.1.2 cXML 変換

cXML では、要素を使用して、従来のビジネスドキュメントでのプロパティに当たる個々の項目を記述します。たとえば、住所が子要素である番地、市区町村、国で構成されるような場合、要素は、子要素が必要な情報やそれらの子要素間の関係も記述できます。また、cXML は属性を使用して、要素の変更や内容の提供を行います。要素や属性の名前では大文字と小文字が区別され、名前の中では大文字を使用して語句を区切り、ハイフンは使用しません。要素名は大文字で始まり、属性名は小文字で始まります。たとえば、次のようになります。

要素: Sender, Credential, Payment, ItemDetail
属性: payloadID, lineNumber, domain

必須ではない要素の内容が空の場合 (null の場合)、要素全体を削除します。これは、空の要素や空白文字の要素が一部のパーサーに影響を及ぼす恐れがあるためです。DTD ファイルおよび cXML ドキュメントでは、トランザクション内で出現する要素の回数を示す記号が使用されます。「+」は、その要素が 1 回以上出現することを表し、「?」はその要素が 0 回または 1 回出現することを表し、「*」はその要素が 0 回以上出現することを表します。

3.1.3 cXML ドキュメント

cXML 要素は cXML ドキュメントのボディです。以下に、ドキュメントの先頭部分の例を示します。

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE cXML SYSTEM "http://xml.cxml.org/schemas/cXML/1.2.014/cXML.dtd">
<cXML xml:lang="en-US" payloadID=”1234567.4567.5678@buyer.com" timestamp="2002-01-09T01:36:05-08:00">

cXML ドキュメントの最初の文字は、

<?

または

<!

でなければなりません。ドキュメントを空白文字やタブで始めることはできません。たとえば、HTML フォームの PunchOutOrderMessage ドキュメントでは、始めの引用符と左山カッコの間に文字を挿入することはできません。cXML ドキュメントの 2 行目には、DOCTYPE 文書型宣言を入れる必要があります。これは、cXML ドキュメントで設定する唯一の外部エンティティです。この行は cXML の DTD を参照します。cXML ドキュメントには、最上位レベルの要素である cXML、Supplier、Contract、および Index。cXML 要素は、「トランザクション的」なデータの場合に使用します。その他の 3 つの要素では、静的なコンテンツを記述します。

3.1.4 ラッピングレイヤ

cXML ドキュメントは、通常は HTTP ヘッダーを持ち、HTTP を使用して転送されます。この HTTP ヘッダーでは、text/xml という MIME (Multipurpose Internet Mail Extensions) メディアタイプを指定し、さらに cXML ドキュメントのエンコード方式を示す charset パラメータを指定します。HTTP は 8 ビットクリーンであるため、受信パーサーによってサポートされる任意の文字エンコードが、base64 やquoted-printable などの content-transfer encoding を必要とせずに使用できます。すべての XML パーサーは、USASCIIを含むすべての Unicode 文字が入っている UTF-8 (Universal Transformation Format) へのエンコードをサポートしています。そのため、cXML ドキュメントを転送する場合、アプリケーションでは UTF-8 を使用してください。

cXML ドキュメントの HTTP 送信には、次の MIME と HTTP ヘッダーが含まれます。

POST /cXML HTTP/1.0
Content-type: text/xml; charset=&quot;UTF-8&quot;
Content-length: 1862
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
User-Agent: Java1.1
Host: localhost:8080
Connection: Keep-Alive
&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;
…

3.1.5 添付ファイル

cXML プロトコルでは、任意のタイプの外部ファイルを cXML ドキュメントに添付することができます。たとえば、バイヤーが注文書の内容を明確にするために、補足メモ、図面、または FAX を添付する場合があります。別の例として、カタログファイルを添付する CatalogUploadRequest ドキュメントがあります。cXML ドキュメントで参照されるファイルは、受信者がアクセス可能なサーバー上に置くか、または cXML ドキュメント自身も含むエンベロープに入れることができます。cXML ドキュメントに外部ファイルを添付して 1 つのエンベロープにするには、MIME (Multipurpose Internet Mail Extensions) を使用します。cXML ドキュメントには、マルチパート MIME エンベロープで送信される外部パートへの参照が含まれます。添付ファイルを含めるこのエンベロープに対する cXML の必要条件 (IETF RFC 2046 の「Multipurpose Internet Mail Extensions Part Two: Media Types」で規定) として、Content-ID ヘッダーが添付ファイルごとに必要です。cXML で指定する URL は、cid: で開始する必要があります。これはより大規模な送信で添付ファイルを参照するための識別子です。cid: 識別子は、送信されるドキュメントを含む MIME 送信の 1 パート (1 つのみ) の Content-ID ヘッダーと一致していなければなりません。

次の例は、JPEG 画像を添付する場合の cXML ドキュメントに必要なスケルトンを示します (ただし上述の HTTP ヘッダーは含んでいません)。

POST /cXML HTTP/1.0
Content-type: multipart/mixed; boundary=something unique
--something unique
Content-type: text/xml; charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
…
 <Attachment>
 <URL>cid:uniqueCID@sender.com</URL>
 </Attachment>
--something unique
Content-type: image/jpeg
Content-ID: <uniqueCID@sender.com>
…
--something unique--

さらに、このスケルトンには、受信 MIME パーサーで処理する必要があるすべてのものが含まれています。RFC 2387 の『The MIME Multipart/Related Content-type』で規定されているメディアタイプを使用するアプリケーションは、このスケルトンの内容を拡張することによって、より多くの情報を取得できます。

POST /cXML HTTP/1.0
Content-type: multipart/related; boundary=something unique;
 type="text/xml"; start=<uniqueMainCID@sender.com>
--something unique
Content-type: text/xml; charset="UTF-8"
Content-ID: <uniqueMainCID@sender.com>
<?xml version="1.0" encoding="UTF-8"?>
…
 <Attachment>
 <URL>cid:uniqueAttachmentCID@sender.com</URL>
 </Attachment>
…
--something unique
Content-type: image/jpeg
Content-ID: <uniqueAttachmentCID@sender.com>
…
--something unique--

multipart/related メディアタイプを解読できない受信 MIME パーサーは、上記の 2 つの例を同様に処理する必要があります。MIME 転送の各パートに Content-transfer-encoding を追加して、そのエンコードを使用することもできます。HTTP 転送には、この追加は必要ありません。cXML プロトコルでは、Content-description ヘッダーと Contentdisposition ヘッダの設定は任意ですが、これらのヘッダーを使用すると文書の利用価値を高めることができます。

Attachment の例

次の例は、カタログを添付する CatalogUploadRequest を示します。

POST /cXML HTTP/1.0
Content-type: multipart/related; boundary=kdflkajfdksadjfk; type="text/xml"; start="<part1.PCO28.975@saturn.workchairs.com>"
<--! begin first MIME body part header -->
--kdflkajfdksadjfk
Content-type: text/xml; charset=UTF-8
Content-ID: <part1.PCO28.975@saturn.workchairs.com>
<--! end first MIME body part header -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cXML SYSTEM "http://xml.cxml.org/schemas/cXML/1.2.014/cXML.dtd">
<cXML timestamp="2000-12-28T16:56:03-08:00" payloadID="12345666@10.10.83.39">
 <Header>
 <From>
 <Credential domain="DUNS">
 <Identity>123456789</Identity>
 </Credential>
 </From>
 <To>
 <Credential domain="NetworkID">
 <Identity>AN01000000001</Identity>
 </Credential>
 </To>
 <Sender>
 <Credential domain="DUNS">
 <Identity>123456789</Identity>
 <SharedSecret>abracadabra</SharedSecret>
 </Credential>
 </Sender>
 </Header>
 <Request>
 <CatalogUploadRequest operation="new">
 <CatalogName xml:lang="en">Winter Prices</CatalogName>
 <Description xml:lang="en">premiere-level prices</Description>
 <Attachment>
 <!-- ID of MIME attachment follows -->
 <URL>cid:part2.PCO28.975@saturn.workchairs.com</URL>
 </Attachment>
 </CatalogUploadRequest>
 </Request>
</cXML>
<--! begin second MIME body part header -->
--kdflkajfdksadjfk
Content-type: text/plain; charset=US-ASCII
Content-Disposition: attachment; filename=PremiereCatalog.cif
Content-ID: <part2.PCO28.975@saturn.workchairs.com>
Content-length: 364
<--! end second MIME body part header -->
CIF_I_V3.0
LOADMODE: F
CODEFORMAT: UNSPSC
CURRENCY: USD
SUPPLIERID_DOMAIN: DUNS
ITEMCOUNT: 3
TIMESTAMP: 2001-01-15 15:25:04
DATA
942888710,34A11,C11,"Eames Chair",11116767,400.00,EA,3,"Fast MFG",,,400.00
942888710,56A12,C12,"Eames Ottoman",11116767,100.00,EA,3,"Fast MFG",,,100.00
942888710,78A13,C13,"Folding Chair",11116767,25.95,EA,3,"Fast MFG",,,25.95
ENDOFDATA
<!-- MIME trailer follows -->
--kdflkajfdksadjfk--

Content-ID または Content-Type ヘッダー内の ID は山カッコ (< >) で囲みます。ただし、URL 要素内で ID を参照する場合は、これらのカッコを省略します。また、URL 要素内でメッセージ ID の前に cid: を付加します。ただし、MIMEヘッダー内では付加しません。cid: URL の特殊文字は、16 進コード (%hh フォーマット) にする必要があります。テキストファイル、PDF、画像などを cXML ドキュメントに添付する場合は、Attachment 要素を使用します。ほかのcXML ドキュメントを添付する場合は、cXMLAttachment を使用します。その cXML ドキュメントにさらに添付ファイルが含まれるかどうかは関係ありません。cXMLAttachment 要素は、添付ファイルを処理するために追加の cXML 処理が必要であることを受信システムに通知します。

次の例は、cXMLAttachment を使用してファイルを添付した cXML ドキュメントを転送する CopyRequest を示します。

Content-Type: Multipart/Related; boundary=outer-boundary
[Other headers]
--outer-boundary
Content-Type: text/xml; charset=UTF-8
Content-ID: <111@sendercompany.com>
[Other headers]
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cXML SYSTEM "http://xml.cxml.org/schemas/cXML/1.2.014/cXML.dtd">
<cXML payloadID="123@sendercompany.com" timestamp="2003-11-20T23:59:45-07:00">
 <Header>
 <From>
 <!-- Sender -->
 <Credential domain="AribaNetworkUserId">
 <Identity>sender@sendercompany.com</Identity>
 </Credential>
 </From>
 <To>
 <!-- Recipient -->
 <Credential domain="AribaNetworkUserId">
 <Identity>recipient@recipientcompany.com</Identity>
 </Credential>
 </To>
 <Sender>
 <!-- Sender -->
 <Credential domain="AribaNetworkUserId">
 <Identity>sender@sendercompany.com</Identity>
 <SharedSecret>abracadabra</SharedSecret>
 </Credential>
 <UserAgent>Sender Application 1.0</UserAgent>
 </Sender>
 </Header>
 <Request deploymentMode="production">
 <CopyRequest>
 <cXMLAttachment>
 <Attachment>
 <URL>cid:222@sendercompany.com</URL>
 </Attachment>
 </cXMLAttachment>
 </CopyRequest>
 </Request>
</cXML>
--outer-boundary
Content-Type: Multipart/Related; boundary=inner-boundary
Content-ID: <222@sendercompany.com>
[Other headers]
--inner-boundary
Content-Type: text/xml; charset=UTF-8
Content-ID: <333@sendercompany.com>
[Other headers]
[Forwarded cXML]
--inner-boundary
[Attachment 1 of the forwarded cXML]
--inner-boundary
[Attachment 2 of the forwarded cXML]
--inner-boundary--
--outer-boundary--
MIME の詳細情報

MIME 規格の詳細については、次の Web サイトを参照してください。

● www.hunnysoft.com/mime
● www.ietf.org/rfc1341.txt
● www.ietf.org/rfc/rfc2046.txt
● www.ietf.org/rfc/rfc2387.txt

3.1.6 cXML エンベロープ

cXML 要素は cXML ドキュメントのルート要素で、その他のすべての要素はこの中で定義します。cXML 要素は、すべての cXML トランザクションで定義されます。次に、cXML 要素の有効な例を示します。

<cXML xml:lang="en-US" payloadID=1234567.4567.5678@buyer.com timestamp="1999-03-31T18:39:09-08:00">

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

属性 説明
version
(非推奨)
この属性は、cXML 1.2.007 以降のバージョンでは推奨されていません。新規の cXML ドキュメントでは使用しないでください。cXML プロトコルのバージョンを指定します。検証を行う XML パーサーも、参照元の DTD からバージョン属性を確認できます。このバージョン番号は cXML ドキュメントの SYSTEM 識別子にも表示されるため、この属性は使用しないでください。
xml:lang この地域情報は、このドキュメントで送信されるすべてのフリーテキストで使用されます。受信者は同一、または類似の地域情報で応答や表示を行ってください。たとえば、Request の中でxml:lang=“en-UK” を指定したクライアントは、Response として “en” データを受信します。最も明確で特定化できる地域情報を指定してください。
payloadID
(必須)
消失した、または問題が発生したドキュメントを特定するためにロギング目的で使用される、スペースと時間に関する一意の数字。この値を変更して再試行しないでください。次のような実装を推奨します。
datetime.process id.random number@hostname
timestamp
(必須)
メッセージが送信された日付と時刻。ISO 8601 フォーマットで記述されます。この値を変更して再試行しないでください。フォーマットは、YYYY-MM-DDThh:mm:ss-hh:mm となります (2015-07-14T19:20:30+01:00 など)。
signatureVersion 存在する場合には、ドキュメントが電子署名付きであることを示します。このドキュメントには、Request、Response、または Message 要素の直後に有効な ds:Signature が 1 つ以上定義されています。この属性の有効な値は 1.0 のみです。その他の値は将来の使用に備えて予約されています。
3.1.6.1 xml:lang で指定する地域情報

xml:lang 属性は、ほとんどのフリーテキスト要素 (Description や Comments など) で指定できます。XML 仕様では、ある要素に地域情報が指定されていない場合、親要素に指定された地域情報がその要素の通常の地域情報となりますが、このようにしてドキュメントツリーの検索を行って通常の値を決定すると効率が低下します。cXML では、地域情報識別子をそれに関連する文字列とともに保持するようにします。最も明確で特定化できる既知の地域情報を、この属性に指定してください。cXML プロトコルのさまざまな要素で指定できる xml:lang 属性は、番号、日付および時刻などのフォーマット済みデータには影響を与えません。次項の timestamp 属性で説明するように、timestamp 属性に関しては、それぞれの値はデータタイプに従ってフォーマットされます。マシン処理に配慮していない長い文字列 (および参照される Web ページ) には、近くにある xml:lang 属性に一致する地域固有の数値または日付フォーマットが使用される場合があります。

3.1.6.2 日付、時刻およびその他のデータタイプ

timestamp 属性と、cXML 内にあるその他すべての日付と時刻は、ISO 8601 で制限されたサブセットでフォーマットされなければなりません。この情報は、『Word Wide Web Consortium (W3C) Note』の「Date and Time Format」に記述されており、www.w3.org/TR/NOTE-datetime-970915.html で入手できます。timestamp には、少なくとも完全な形式の日付および時、分、秒が含まれている必要があります。秒の小数部の設定は任意です。このプロトコルでは、UTC (協定世界時、グリニッジ標準時としても知られます) を基準とした時間帯で現地時間を表す必要があります。「Z」時間帯識別子は使用できません。たとえば、2015-04-14T13:36:00-08:00 は、米国太平洋標準時の西暦 2015 年 4 月 14 日午後 1 時 36 分に相当します。

注記
timestamp 属性は cXML DTD で必要ですが、値のフォーマットの検証はアプリケーションに依存します。

cXML で使用する日付、時刻、およびその他のデータタイプのフォーマットに関する詳細情報は、次のサイトで参照できます。

● Microsoft 社の XML Data Types Reference: msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk/html/b24aafc2-bf1b-4702-bf1c-b7ae3597eb0c.asp
● W3C (Word Wide Web Consortium) に対する XML データ提案の原書: www.w3c.org/TR/1998/NOTE-XMLdata-0105

3.1.6.3 特殊文字

cXML では XML と同様に、すべての文字がキーボードから入力できるわけではありません。たとえば登録商標記号 (R)などがこれに該当します。また、たとえば < や & は、XML では特別な意味を持ちます。これらの文字は、文字エンティティを使用してエンコードする必要があります。XML では、次の組み込み文字エンティティが定義されています。

エンティティ 文字
&lt; <
&gt; >
&amp; &
&quot; "
&apos; '

使用するエンコード以外の文字に関しては、シャープ記号 (#) に続けてその文字の Unicode 番号 (10 進数または 16 進数) を使用します。たとえば、 &#xAE; および &#174; は、登録商標記号 ((R)) を表します。次に例を示します。

<Description xml:lang="en-US">The best prices for software®</Description>

これは、次のようにエンコードします。

<Description xml:lang="en-US">The best prices for software &amp;#174;</Description>

一重引用符 (‘) または二重引用符 (“) が属性値の中で使用されており、その属性値がこれらの引用符で囲まれている場合、属性値の中で使用されている引用符は、エスケープする必要があります。属性値の中に引用符が含まれる場合、属性は一重引用符のみを使用して囲むことを推奨します。

3.1.6.3.1 ドキュメントにおける特殊文字の処理
  1. 属性の区切り文字として一重引用符のみを使用しているテンプレートを使用します。
  2. 次のいずれか 1 つを実行して、そのテンプレートに値を追加します。
    • ドキュメントが、cxml-urlencoded 隠しフィールドによって転送された PunchOutOrderMessage である場合、US-ASCII エンコードを使用してテンプレートに値を入力します。このエンコードでは、エンコードできないすべての文字に対して、XML 文字エンティティを使用します。たとえば、登録商標記号 (®) は、US-ASCII ではサポートされていないため、&#174; と入力します。
    • それ以外の場合は、UTF-8 エンコードを使用してドキュメントの値を入力します。HTTP Post により直接送信されたドキュメント、または cXML-base64 隠しフィールドに埋め込まれたドキュメントのすべてで、UTF-8 を使用します。UTF-8 には、US-ASCII コードがすべて含まれています。
  3. cXML ドキュメント作成時に、XML で属性値と要素の内容をエスケープします。エスケープする必要がある文字は、&、’、<、および > です。PunchOutOrderMessage ドキュメントを転送する場合は、次の手順が必要です。
  4. ブラウザが解読するすべての文字について、次のことに注意してください。
    • cxml-urlencoded 隠しフィールドを使用している場合、すべての二重引用符を " に変換します。
    • さらに (cxml-urlencoded フィールドの場合)、HTML で有効なコンテキストで記述されているすべてのアンパサンドを、& に変換してください。安全を期すために、すべてのアンパサンドをエスケープしてもかまいません。たとえば、アンパサンド (&) は & としてエスケープし、アポストロフィ (‘) は &apos; としてエスケープします。登録商標記号 (®) は &#174; としてエスケープします。
    • これ以外の場合で、cxml-base64 隠しフィールドを使用している場合、cXML ドキュメント全体に対して base64 エンコード方式を使用します。
  5. 文字列を二重引用符で囲んで、ドキュメントを HTML フォームに埋め込みます。たとえば、値が ®®””””&<>>”で、属性の値が ®®'”””&<>> の Money 要素を送信する場合、XML ドキュメントは次のようになります。
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE Money SYSTEM 'SpecialChars.dtd'>
<Money alternateAmount='&#174;&#xAE;&apos;"&#34;&quot;&amp;lt;&gt;&gt;'>&#174;&#xAE;&apos;"&#34;&quot;&amp;lt;&amp;gt;&amp;gt;</Money>

これは、次のようにエンコードしてください。

<!-- Recommendation for cXML-urlencoding: Uses double quotes to delimit the -->
<!-- field value and single quotes for the contained attributes. -->
<Input type="Hidden" name="cXML-urlencoded" value="<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE Money SYSTEM 'SpecialChars.dtd'>
<Money alternateAmount='MoneyalternateAmount='&amp;#174;&amp;#xAE;&amp;apos;&#34;&amp;#34;&amp;quot;&amp;amp;&amp;lt;>&amp;gt;'>&amp;#174;&amp;#xAE;'&amp;apos;&#34;&amp;#34;&amp;quot;&amp;amp;&amp;lt;&amp;gt;&amp;gt;'</Money>">
<!-- Best choice: Base64 encode the value. Don't have to worry about what -->
<!-- the browser interprets. -->
<Input type="Hidden" name="cXMLbase64"value="PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0nVVRGLTgnPz4KPCFET0NUWVBFIE1vbmV5IFNZU1RFTSAnU3BlY2lhbENoYXJzLmR0ZCc+CjxNb25leSBhbHRlcm5hdGVBbW91bnQ9JyYjMTc0OyYjeEFFOyZhcG9zOyImIzM0OyZxdW90OyZhbXA7Jmx0Oz4mZ3Q7Jz4KJiMxNzQ7JiN4QUU7JyZhcG9zOyImIzM0OyZxdW90OyZhbXA7Jmx0Oz4mZ3Q7PC9Nb25leT4K">

上記の例は、cXML-urlencoded フィールドをエンコードする別の方法です。ここでは XML が、山カッコなどのいくつかの文字をエスケープしないようにしていますが、これは XML での特別な処理というわけではありません。前記の手順を直接実装すると、次のような HTML フィールドになります。

<Input type="Hidden" name="cXML-urlencoded" value="<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE Money SYSTEM 'SpecialChars.dtd'>
<Money alternateAmount='&#174;&#174;&apos;"""&amp;&lt;&gt;&gt;'>&#174;&#174;''"""&amp;&lt;&gt;&gt;</Money>">

または、次のような XML ドキュメントになります。

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE Money SYSTEM 'SpecialChars.dtd'>
<Money alternateAmount='&#174;&#174;&apos;"""&amp;&lt;&gt;&gt;'>&#174;&#174;''"""&amp;&lt;&gt;&gt;</Money>

3.1.7 Header

Header 要素は、アドレス指定と認証情報で構成されます。cXML メッセージのボディに特定の Request または Response がある場合も、Header 要素は同じです。アプリケーションは申請者の ID 情報が必要ですが、ID 情報の内容が正しいかどうかの検証は行いません。次の例は、Header 要素を示しています。

<Header>
 <From>
 <Credential domain="AribaNetworkUserId">
 <Identity>admin@acme.com</Identity>
 </Credential>
 </From>
 <To>
 <Credential domain="DUNS">
 <Identity>012345678</Identity>
 </Credential>
 </To>
 <Sender>
 <Credential domain="AribaNetworkUserId">
 <Identity>sysadmin@buyer.com</Identity>
 <SharedSecret>abracadabra</SharedSecret>
 </Credential>
 <UserAgent>Network Hub 1.1</UserAgent>
 </Sender>
</Header>

From 要素と To 要素は、SMTP メールメッセージの From と To と同義です。これらは、メッセージの論理的な発信元と宛先です。Sender 要素に定義する情報は、HTTP 接続を開始して cXML ドキュメントを送信する組織または人です。Sender 要素には Credential 要素が含まれており、この要素を使用して、受信者は送信者を認証します。この認証方法は、公開鍵によるデジタル認証のためのインフラストラクチャを必要とせずに、強力な認証を可能にします。送信者は、受信者側が発行したユーザー名とパスワードを使用することで、Requests を実行できます。ドキュメントが最初に送信される時は Sender と From は同一の組織を示していますが、cXML ドキュメントがネットワークハブを経由して転送されると、Sender 要素は変更され、送信した直前の組織を示すようになります。

3.1.7.1 From

この要素は、cXML Request の発信元を識別します。

3.1.7.2 To

この要素は、cXML Request の宛先を識別します。

3.1.7.3 Sender

この要素によって、受信者側は HTTP 接続を開始した相手を識別して認証します。受信者側は作業の要求者を認証する必要があるため、この要素内では、From または To 要素の場合よりも強力な認証機能を持つ Credential 要素を使用します。

3.1.7.4 UserAgent

cXML で対話を行う UserAgent を表す、テキスト文字列です。この文字列は、製品ごとに固有にする必要があり、可能であればバージョンごとにも固有にしてください。これは、HTTP の UserAgent に類似しています。

3.1.7.5 Credential

この要素には、識別値と認証値を定義します。Credential には次の属性があります。

属性 説明
domain
(必須)
認証情報のタイプを指定します。この属性を使用して、複数の認証ドメインに対する複数のタイプの認証情報をドキュメントに含めることができます。たとえば、Ariba Network 上で送信されたメッセージについて、domain にAribaNetworkUserId が指定されている場合は電子メールアドレス、DUNS の場合はDUNS ナンバー、NetworkId の場合は割り当て済みの ID を表します。
type マーケットプレイスからの、またはマーケットプレイスへの要求は、マーケットプレイスとメンバー企業の両方を From または To Credential 要素で識別します。この場合、マーケットプレイスに対する認証情報には type 属性を使用し、その属性は「marketplace」という値に設定します。

Credential には、Identity 要素を含め、任意で SharedSecret 要素または CredentialMac 要素を含めます。Identity 要素は Credential の対象である組織について記述し、任意設定の認証要素はその組織の ID 情報を記述します。

SharedSecret

SharedSecret 要素は、申請者が認識するパスワードが Sender に含まれる場合に使用します。

注記
One-Way 転送によって送信されるドキュメントには、認証要素を使用しないでください。One-Way 転送はユーザーのブラウザを介してルーティングされるため、Credential 要素を含むドキュメントのソースをユーザーに参照される可能性があります。

CredentialMac

CredentialMac 要素は、メッセージ認証コード (MAC) による認証で使用されます。この認証方法は、信頼のおけるサードパーティにより共有シークレットを使用して認証されたことを、送信者が受信者に証明する必要がある状況で使用されます。たとえば、ダイレクトパンチアウト要求は、サプライヤによる認証が可能な MAC (ネットワークハブによって生成されたもの) が含まれるため、バイヤーからサプライヤへ、ネットワークハブを介さずに直接送信できます。信頼のおけるサードパーティが MAC を計算し、プロファイルトランザクションを介して送信者へ転送します。送信者はMAC の値しか見ることはできません (安全で逆変換できません)。MAC は、ProfileResponse オブジェクトを使用し、信頼のおけるサードパーティから送信者に送信されます。受信者は、信頼のおけるサードパーティと同じ入力データを使用して MAC を計算し、cXML ドキュメントで受信した MACと比較します。この 2 つの値が一致するとドキュメントは認証されたことになります。MAC 値の計算方法については、メッセージ認証コード (MAC) [561 ページ] を参照してください。CredentialMac には、次の属性があります。

属性 説明
type
(必須)
認証されるデータとその認証用のフォーマット方法を識別します。サポートされる値は”FromSenderCredentials” のみです。
algorithm
(必須)
データで使用された MAC アルゴリズムを識別します。サポートされる値は “HMAC-SHA1-96”のみです。
creationDate
(必須)
MAC が生成された日時を指定します。
expirationDate
(必須)
MAC の有効期限を示す日時を指定します。受信者は expirationDate 後に受け取った MAC を却下する必要があります。受信者は有効期限前の MAC を、任意で却下することもできます。たとえば、受信者は 1 時間以内に有効期限が切れる MAC を却下する場合があります。

次の例は、CredentialMac 要素が使用されている Credential 要素を示します。

<Sender>
 <Credential domain=”NetworkId”>
 <Identity>AN9900000100</Identity>
 <CredentialMac type=”FromSenderCredentials” algorithm=”HMAC-SHA1-96” creationDate=”2003-01-15T08:42:46-0800” expirationDate=”2003-01-15T11:42:46-0800”>
 MnXkusp8Jj0lw3mf
 </CredentialMac>
 <UserAgent>Procurement Application 8.1</UserAgent>
 </Credential>
</Sender>
複数の認証情報

From 要素、To 要素、および Sender 要素には、それぞれに複数の Credential 要素を任意で設定できます。複数の認証情報を提供する目的は、さまざまなドメインを使用している 1 つの組織を識別することです。たとえば、DUNS ナンバーおよび NetworkId ナンバーの両方を含めることで、組織が識別される場合があります。

受信者は、受け取ったドメインのすべての認証情報を検証する必要があります。使用されたドメインの認証情報が、認識している組織と一致しない場合、そのドキュメントを却下してください。同じ From、To、または Sender セクションの 2 つの認証情報が別々のエンティティを参照している場合にも、ドキュメントは却下されます。異なる値が使用されているものの、同じドメインが使用されている To、From、または Sender セクションに複数の認証情報が存在する場合には、ドキュメントは却下されます。

3.1.7.6 Correspondent

From および To 要素には、任意設定の Correspondent 要素をそれぞれ含めることができます。Correspondent 要素は、発信側または受信側の組織が、もう一方の組織または接続ハブにとって未知である場合に使用されます。送信者、受信者、または接続ハブは、Correspondent 要素内の情報を使用して未知の組織を識別できます。Correspondent には次の属性があります。

属性 説明
preferredLanguage 組織の優先言語 (わかっている場合)未知の組織は Contact 要素で識別します。

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

要素 説明
Contact(必須) オーダーをフォローアップするための連絡先情報が含まれます。「連絡先 [45 ページ]」を参照してください。
Routing 対応するルーティング宛先を定義します。「Routing [31 ページ]」を参照してください。
Extrinsic この組織に関連する追加情報が含まれます。
3.1.7.6.1 Routing

外部ビジネスパートナーの対応するルーティング宛先を定義します。Routing には次の属性があります。

属性 説明
destination(必須) ルーティング宛先の名前。使用可能な値は次のとおりです。
● peppol
● fieldglass

以下の例は、外部ビジネスパートナーの Routing 要素を示します。

<Header>
 <From>
 <Credential domain="BusinessPartnerId">
 <Identity>
 <IdReference domain="iso6523" identifier="9925:BE12345678"/>
 </Identity>
 </Credential>
 </From>
 <To>
 <Credential domain="BusinessPartnerId">
 <Identity>
 <IdReference domain="iso6523" identifier="9925:BE3456789" />
 </Identity>
 </Credential>
 <Correspondent preferredLanguage="de">
 <Contact role="correspondent">
 <Name xml:lang="en-US">SupplierTradingName Ltd.</Name>
 <PostalAddress>
 <Street>Street</Street>
 <City>City</City>
 <State>State</State>
 <PostalCode>04726010</PostalCode>
 <Country isoCountryCode="BE" />
 </PostalAddress>
 <Phone name="work">
 <TelephoneNumber>
 <CountryCode isoCountryCode="BE" />
 <AreaOrCityCode />
 <Number>1151869655</Number>
 </TelephoneNumber>
 </Phone>
 </Contact>
 <Routing destination="peppol" />
 </Correspondent>
 </To>
 <Sender>
 <Credential domain="NetworkID">
 <Identity>AN01000000001</Identity>
 </Credential>
 <UserAgent>Ariba Network</UserAgent>
 </Sender>
</Header>

3.1.8 Request

クライアントは、Request ドキュメントを送信して特定の操作を要求します。cXML ドキュメントの読み取り処理を分割する必要がないよう、各 cXML エンベロープ要素で使用できる Request 要素は 1 つだけです。このため、サーバーの実装は単純になります。Request 要素には、事実上すべてのタイプの XML データを含めることができます。一般的な Request 要素として次のものがあります。

● OrderRequest
● ProfileRequest
● PunchOutSetupRequest
● StatusUpdateRequest
● GetPendingRequest
● ConfirmationRequest
● ShipNoticeRequest
● ProviderSetupRequest
● PaymentRemittanceRequest

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

属性 説明
deploymentMode Request がテストモードであるか本稼動モードであるかを示します。値は、「production」(通常) または「test」です。
Id この属性は要素およびそのすべての子要素を電子署名の対象として呼び出すために使用します。

3.1.9 Response

サーバーはクライアントに Response を送信して、操作結果を通知します。一部の Request の結果にはデータがない場合があるため、Response 要素は、任意で Status 要素のみで構成することもできます。さらに、Response 要素にはどのようなアプリケーションレベルのデータも含めることができます。たとえば PunchOut セッションでは、そのアプリケーションレベルのデータが PunchOutSetupResponse 要素に含まれています。一般的な Response 要素として次のものがあります。

● ProfileResponse
● PunchOutSetupResponse
● GetPendingResponse

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

属性 説明
Id この属性は要素およびそのすべての子要素を電子署名の対象として呼び出すために使用します。
3.1.9.1 Status

この要素は要求された操作が成功したか、一時エラーか、または永久エラーかを通知します。
Status には次の属性があります。

属性 説明
code
(必須)
要求の状況コード。たとえば、200 は要求が成功したことを示します。下記のコード表を参照してください。
text
(必須)
状況のテキスト。このテキストは、英語で記述された標準的なエラー表記で、ユーザーが判読できるログです。
xml:lang Status 要素で使用されるデータの言語。cXML 1.0 との互換性を目的としたオプションです。cXML の将来のバージョンで必要となる場合があります。

Status 要素の属性は、要求の結果を表します。以下に例を示します。

<Status xml:lang="en-US" code="200” text="OK"> </Status>

Status 要素の内容には、申請者が必要なあらゆるデータを記述することができますが、エラーに関する情報を記述するようにしてください。200/OK 状況コードには、データが存在しない場合があります。ただし、500/Internal ServerError 状況コードまたはその他の類似するコードには、実際の XML 解析エラーまたはアプリケーションエラーを含めることを強く推奨します。このエラーは、一方向のデバッグや相互運用性のテストをする際に役立ちます。以下に例を示します。

<Status code="406" text="Not Acceptable">cXML did not validate. Big Problem!</Status>

次の表は、cXML 状況コードの範囲を示します。

範囲 意味
2xx 成功
4xx 永久エラー。クライアントは、再試行しないでください。このエラーの場合、申請は承認されていません。
5xx 一時エラー。一般的には転送エラーです。クライアントは、再試行してください。推奨する再試行回数は、1 時間おきに 10 回です。少なくとも 6 回の再試行を推奨します。緊急なオーダーなど、重要度の高い申請に関しては、再試行頻度を上げてもかまいません。

cXML 状況コードが 200 番台 (cXML 200/OK など) でない限り、サーバーには追加の Response 要素(PunchOutSetupResponse 要素など) を含めないでください。ほとんどの場合、cXML は HTTP の上の階層にあるため、多くのエラー (HTTP 404/Not Found など) はトランスポートによって発生しています。すべてのトランスポートエラーは、cXML 500 番台の状況コードを受け取った時と同様に一時エラーとして取り扱い、クライアントは再試行する必要があります。HTTP 404/Not found や HTTP 500/Internal Server Error 状況コードなどの、有効な cXML コンテンツを含まない HTTP Response は、すべて転送エラーであるとみなされます。転送に関するその他の一般的な問題には、タイムアウト、TCP エラー (「connection refused」など)、および DNS エラー (「host unknown」など) があります。Request ドキュメントの構文解析における検証エラーの場合、一般的には 400 番台、多くは 406/Not Acceptable の cXML 永久エラーが発生します。

次の表に、発生し得る cXML 状況コードを示します。

ステータス テキスト 意味
200 OK サーバーは Request を実行しました。または、最終受信者へ結果を送信しました。返された Response には、アプリケーションの注意またはエラーが含まれる可能性があります。cXML Request 自身はエラーも注意も生成しませんでしたが、この状況はその後のアプリケーションで発生し得るいかなるエラーや注意も、反映されません。後の処理でエラーが発生しない限り、この状況の更新情報は受け取りません。
201 Accepted 中間ハブによって転送の Request が受け入れられました。または、その最終の宛先によって受信されましたが、解析はされていません。送信するメカニズムが利用可能であれば、Request に関する状況の更新情報を受け取ります。クライアントはこの後 StatusUpdate トランザクションを受信します。
204 No Content すべての Request 情報は有効で、認識されました。サーバーには、要求されたタイプの Response データがありません。PunchOutOrderMessage において、この状況はパンチアウトセッションがショッピングカート (または、クライアントの購入申請) に対する変更なしに終了したことを示します。
211 OK バイヤーはこの状況コードを使用して、サプライヤが把握する必要があるイベント (休日のスケジュール、生産設備の閉鎖、特定の活動の完了 (たとえば、計画実行完了) など)を通知するために、サプライヤにブロードキャストメッセージを送信することができます。
280 中間ハブにより Request が転送されました。少なくとももう 1 つの状況更新情報を受け取ります。この状況は、Request が別の中間転送者、または、状況 201 で最終受信者に送信されたか、信頼できる非 cXML のトランスポートを経由して転送されたことを意味する場合があります。
281 非確実なトランスポート (電子メールなど) を使用して、中間ハブにより Request が転送されました。状況更新情報を受け取る可能性があります。ただし、状況更新情報を受け取らない場合、必ずしも問題があるというわけではありません。
400 Bad Request 構文解析では問題がありませんが、サーバーが Request を受け入れられませんでした。
401 Unauthorized Request (Sender 要素) の中で指定されている Credential が、サーバーに認識されませんでした。
402 Payment Required Request には、完全な Payment 要素が含まれていなければなりません。
403 Forbidden ユーザーが、Request を実行するための十分な権限を持っていません。
406 Not Acceptable Request はサーバーに受け入れられませんでした。構文解析の失敗によるものと推測されます。
409 Conflict サーバーの現在の状況またはその内部データにより、(更新) 操作要求が中断されました。同様の Request は、別の操作の実行後以外では、今後も正常に実行される可能性はありません。
412 Precondition Failed Request の前提条件 (PunchOutSetupRequest edit に対する適切なパンチアウトセッションなど) が満たされていませんでした。この状況は、一般的には、サーバーからの以前の転送の一部をクライアントが無視したことを意味します
(PunchOutOrderMessageHeader の operationAllowed 属性など)。
417 Expectation Failed Request のリソース条件が満たされなかったことを示します。1 つの例として、サーバーが未知のサプライヤに関する情報を要求する SupplierDataRequest があります。この状況は、クライアントまたはサーバーで消失した情報があることを示します。
450 Not Implemented サーバーは指定の Request を実装していません。たとえば、PunchOutSetupRequest、もしくは要求された操作がサポートされていない可能性があります。一般的に、この状況はクライアントがサーバーのプロファイルを無視した
ことを示します。
475 Signature Required ドキュメントに電子署名がないため、受信者はドキュメントを受け付けようとしません。
476 Signature Verification Failed 転送中にドキュメントが変更、または署名で使用されたアルゴリズムの 1 つまたは複数を受信者がサポートしないなどの原因により、受信者は署名を検証することができません。
477 Signature Unacceptable 署名は技術的に有効ですが、その他の理由により受信者に承認されません。署名規定または証明書規定が承認されないか、使用された証明書の種類が承認されないか、またはその他の問題が存在する可能性があります。
500 Internal Server Error サーバーが Request を完了できませんでした。
550 Unable to reach cXML server 次の処理のための接続が必要なトランザクションは、次の cXML サーバーに到達できず完了できません。サプライヤサイトに到達できないとき、中間ハブがこのコードを返すことがあります。次への接続が完了した場合、中間ハブはエラーをクライアントに直接返さなければなりません。
551 Unable to forward request サプライヤの設定ミスにより、Request を転送できません。たとえば、中間ハブがサプライヤに対し自身の認証に失敗しました。クライアントはこのエラーを修正できませんが、クライアントが再試行する前にこのエラーが解決される場合があります。
560 Temporary server error たとえば、サーバーは保守などで停止することがあります。クライアントは後で再試行してください。

下の表は、CatalogUploadRequest に対する可能な状況コードを一覧にしたものです。

ステータス テキスト 意味
200 Success CatalogUploadRequest は正常に処理されました。
201 Accepted CatalogUploadRequest を処理中です。
461 Bad Commodity Code カタログに割り当てられている商品分類コードが無効です。
462 Notification Error 通知方法 (電子メールまたは URL) が指定されていません。
463 Bad Catalog Format ZIP ファイルが無効です。
464 Bad Catalog カタログが添付されていないか、複数のカタログが添付されています。
465 Duplicate Catalog Name 同じカタログ名が存在します。
466 No Catalog to Update 更新するカタログが存在しません。
467 Publish Not Allowed 以前に公開されていないカタログを公開しようとしました。
468 Catalog Too Large アップロードするファイルのサイズが 4MB の制限を超えています。カタログをアップロードする前に、ZIP 形式で圧縮してください。
469 Bad Catalog Extension カタログのファイル名の拡張子は、.cif、.xml、または.zip でなければなりません。
470 Catalog Has Errors メッセージが、カタログの状況を示しています。(HasErrors)
499 Document Size Error cXML ドキュメントのサイズが大きすぎます。
561 Too Many Catalogs 1 時間当たり一定数以上のカタログをアップロードすることはできません。
562 Publish Disabled 定期保守作業に伴い、カタログの公開を一時停止しています。指定した日時までに復旧する見通しです。
563 Catalog Validating 以前のバージョンのカタログの検証が終了する前に、カタログを更新しようとしました。

認識されないコードを受信したとき、cXML クライアントはコードのクラスに従ってそれらのコードを処理する必要があります。したがって、古いクライアントは、すべての新しい 2xx コードを 200 (成功)、4xx コードを 400 (永久エラー)、および 5xx コードを 500 (一時エラー) として処理する必要があります。この動作は、今後、相互運用性を損なわずに、cXML プロトコルとサーバー固有のコードが拡張されることを考慮しています。

3.1.10 One-Way (非同期式) モデル

Request/Response トランザクションと異なり、One-Way メッセージは HTTP 転送に限定されません。One-Way メッセージは、HTTP チャネル (同期式の Request/Response タイプの操作) で対応できないような場合に使用します。次の図は、Request/Response トランザクションを使用せず A および B がメッセージを通信する方法を示しています。

図 2: One-Way メッセージ (非同期式)

この場合、以下のシナリオが考えられます。

  1. サイト A は、サイト B が認識する転送方法で cXML ドキュメントをフォーマットしてエンコードします。
  2. サイト A は、その転送方法を使用してドキュメントを送信します。サイト A は、サイト B からの Response を待つことはしません (待ち状態になることはできません)。
  3. サイト B は、cXML ドキュメントを受信した後、それを転送ストリームからデコードします。
  4. サイト B はドキュメントを処理します。
    One-Way モデルでは、サイト A とサイト B の間に明示的な Request/Response サイクルは存在しません。たとえば、One-Way メッセージによる通信中に別の相手からメッセージが到着して、そちらの対話が始まる可能性もあります。One-Way トランザクションを完全に明記するには、メッセージの転送方法も記述します。たとえば、One-Way アプローチを使用する cXML トランザクションでは、転送方法とエンコード方式を指定します。One-Way トランザクションを使用する一般的な例は、PunchOutOrderMessage です。

One-Way メッセージの構造は、Request/Response モデルの構造と類似しています。

<cXML>
 <Header>
 Header information here…
 </Header>
 <Message>
 Message information here…
 </Message>
</cXML>

Header 要素は、Request/Response ドキュメントと同様に処理されます。cXML 要素も、cXML エンベロープ [24 ページ] に説明した内容と同じです。One-Way メッセージと Request/Response メッセージとの違いを見分ける最も簡単な方法は、Request または Response 要素の代わりに使用する Message 要素の有無を確認することです。次のセクションでは、Message 要素についてさらに詳しく説明します。One-Way メッセージの Header 要素の送信者認証情報に、共有シークレット情報を含めないでください。認証は、BuyerCookie を使用して行われます。これは、Request/Response の Header とは異なります。

3.1.11 Message

この要素には、cXML メッセージのすべてのボディの情報を定義します。この要素には、任意設定の Status 要素を含めることができます (Response 要素の Status 要素と同じです)。Status 要素は、Request メッセージに対する Responseメッセージ中で使用します。Message には次の属性があります。

属性 説明
deploymentMode Request がテストモードであるか本稼動モードであるかを示します。値は、「production」(通常) または「test」です。
inReplyTo この Message が応答する Message を指定します。inReplyTo 属性の値は、以前に受信した Message の payloadID です。この属性は、多数のメッセージによる双方向の対話を行う場合に使用します。
Id この属性は要素およびそのすべての子要素を電子署名の対象として呼び出すために使用します。

inReplyTo 属性は、以前の Request または Response ドキュメントの payloadID を参照することもできます。Request/Response トランザクションが、複数の One-Way メッセージを介して「対話」を開始するとき、最初のメッセージには、逆方向へ最後に送信された適切な Request または Response の payloadID を含めることができます。たとえば、PunchOutOrderMessage を含む Message には、パンチアウトセッションを開始した PunchOutSetupRequestの payloadID を持つ inReplyTo 属性が指定されている場合があります。パンチアウトドキュメントに含まれるBuyerCookie には、この inReplyTo 属性と同様の機能があります。

3.1.12 転送オプション

One-Way メッセージには、HTTP と URL フォームエンコードの 2 つの一般的に使用される転送があります。現在明確に定義されている転送は、これら 2 つだけです。将来、さらに多くの転送がサポートされる可能性があります。

HTTP

調達アプリケーションは、One-Way HTTP 通信を使用して情報を引き出します。One-Way HTTP 通信を使用するトランザクションの 1 つに、GetPendingRequest があります。セキュリティのため転送データが暗号化されるため、HTTPS が推奨されます。

URL フォームエンコード

URL フォームエンコードを使用することにより、リモート Web サイトと調達アプリケーションの統合が可能になります。さらに、URL フォームエンコードでは、バイヤーシステムの受信サーバーを通す必要がなく、バイヤーシステムにインターネットを経由して直接アクセスできます。PunchOutOrderMessage トランザクションがどのように動作するかの説明は、この転送の仕組みを理解するのに役立ちます。リモート Web サイトは、cXML PunchOutOrderMessage ドキュメントを調達アプリケーションに直接送信するのではなく、このドキュメントを HTML Form の隠しフィールドとしてエンコードし、PunchOutSetupRequest のBrowserFormPost 要素で指定した URL の示す場所にその情報を書き込みます。ユーザーが買物の終了後に Webサイトの [チェックアウト] ボタンをクリックすると、Web サイトはそのデータを HTML Form で調達アプリケーションに送信します。下の図に、その処理を示します。

パッキングとアンパッキングについて以下で説明します。

Form パッキング

リモート Web サイトで、各 PunchOutOrderMessage ドキュメントが cXML-urlencoded または cXML-base64 という Form の隠しフィールドに割り当てられます。また、HTML Form 要素で METHOD に POST を、ACTION に PunchOutSetupRequest の BrowserFormPost 要素の中で示された URL を割り当てます。

例:

<FORM METHOD=POST ACTION="http://workchairs.com:1616/punchoutexit">
 <INPUT TYPE=HIDDEN NAME="cXML-urlencoded" VALUE="Entire URL-Encoded PunchOutOrderMessage document">
 <INPUT TYPE=SUBMIT VALUE="Proceed">
</FORM>

ページ上に追加された HTML タグには、ショッピングカートの内容を詳しく説明するために、上記のフラグメントが含まれることがあります。

注記
Web サーバーが cXML-urlencoded フィールドを送信したときには、URL はまだエンコードされていません。このエンコードは、フォームが Web ブラウザによって送信されるとき (上記の例で、ユーザーが [チェックアウト] をクリックしたとき) にのみ必要です。Web ブラウザ自体はこの必要条件を満たしています。Web サーバーが HTML エンコードの処理をする必要があるのは、フィールド値、エスケープのための引用符、およびその他の特殊文字のみであるため、フォームはユーザーにとって適切な形で表示されます。

名前 cXML-urlencoded and cXML-base64 では、大文字/小文字が区別されます。

cXML-urlencoded

cXML-urlencoded フィールドは、Web サーバーやサプライヤではなく、Web ブラウザによって (HTTP 仕様に従って)エンコードされた URL です。これは、たとえば前の例で、ユーザーが [チェックアウト] をクリックした場合のように、Web ブラウザによってフォームが送信された場合にのみエンコードが必要となるためです。ただし、フォームを適切な形で表示するために、Web サーバーはフィールド値、エスケープのための引用符、およびその他の特殊文字を HTML エンコード処理する必要があります。

注記
サプライヤは、cXML-urlencoded フィールドを URL エンコード処理しないでください。このフィールドは、Web ブラウザによって自動的に URL エンコードされます。

受信パーサーは、cXML-urlencoded データに関して、メディアタイプ text/xml の通常の値を超えた charset パラメータを解釈することができません。送信されたデータの文字エンコード情報は、HTTP POST では保持されません。受信Web サーバーは、隠しフィールドを含む HTML ページのエンコードを解釈できません。したがって、この方法で転送されるcXML ドキュメントでは、us-ascii 文字エンコードを使用する必要があります。XML ソースドキュメントのすべての文字(「%XX」として「URI エンコード処理」されたものを含みます) が、「US-ASCII」文字になっている必要があります。その他の Unicode 記号は、そのソースドキュメント内の文字エンティティを使用してエンコードします。

cXML-Base64

cXML-base64 の隠しフィールドは、多言語のドキュメントをサポートしています。「US-ASCII」以外の記号を含む cXML ドキュメントは、cXML-urlencoded 隠しフィールドではなく、このフィールドを使う必要があります。この方法は意味的にはほぼ同じですが、ブラウザに対する HTML エンコードや受信 Web サーバーに対する URL エンコードを使用せず、転送を通じてドキュメント全体を Base64 エンコードします。Base64 エンコードは、RFC 2045 の『Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies』で説明されています。ブラウザを介したリモート Web サイトからクライアントの受信 Web サーバーまでの Base64 エンコードでは、cXML ドキュメントの元の文字のエンコードを保持します。charset パラメータは通知される情報と一緒には届きませんが、(転送エンコードが削除された後の) デコード済みドキュメントは、メディアタイプ application/xml として処理できます。この処理によって、受信パーサーは、XML 宣言で指定されたすべての encoding 属性を受け付けることができます。このフィールド (すべての application/xml ドキュメント) に対する通常の文字エンコードは、UTF-8 です。これらの隠しフィールド (cXML-urlencoded または cXML-base64) のいずれか一方は、調達アプリケーションに送信されるデータに含まれていなければなりません。最初に検索されるのは cXML-base64 ですが、両方のフィールドを送信する必要はありません。

Form のアンパッキングと処理

事前に適切な URL を通知している調達アプリケーションは、上述の Form データを含む HTML Form POST を受信します。Form POST プロセッサは、最初に cXML-base64 変数を検索し、その値を抽出して、内容を Base64 でデコードします。このフィールドがデータに存在しない場合、Form POST プロセッサは cXML-urlencoded 変数を検索し、URL エンコードによる cXML メッセージを抽出し、それを URL デコードします。デコードされたフィールドの内容は、それが通常のHTTP Request/Response サイクルによって受信されたデータの場合と同様に処理されます。デコード後に、ドキュメントの暗黙のメディアタイプが変化して、異なる文字エンコードが指定されている可能性があります。

● cXML-urlencoded 変数の場合は、メディアタイプ text/xml を意味し、charset 属性はありません。そのため、この文字エンコードは US-ASCII に限定されます。ブラウザがエンコードを変更している可能性があるため、受信パーサーは、cXML ドキュメントの XML 宣言の encoding 属性を無視する必要があります。
● cXML-base64 変数の場合は、メディアタイプ application/xml を意味し、どのような文字エンコードも含まれる可能性があります (XML 宣言に encoding 属性がある場合は、それによって示されています)。application/xml ドキュメントの通常の文字エンコードは UTF-8, です。

このトランザクションと標準の Request/Response トランザクションとの主な相違点は、Response 送信用の HTTP 接続
がないため Response を生成しないことです。

3.1.13 サービス状況応答

このトランザクションは、特定のサービスが現在利用可能かどうかの問い合わせを解決します。HTTP GET がサービスサイトに送られると、サービスは動的に作成された有効な cXML Response ドキュメントで応答します。サービスの HTTP URL は、cXML Request ドキュメントを受信できればどこでも可能です。たとえば、https://service.ariba.com/service/transaction/cxml.asp に送信された HTTP GET は、次のような Response を受け取ります。

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE cXML "http://xml.cXML.org/schemas/cXML/1.2.014/cXML.dtd">
<cXML timestamp="2001-01-08T10:47:01-08:00" payloadID="978979621537--4882920031100014936@206.251.25.169">
 <Response>
 <Status code="200" text="OK">Ping Response Message</Status>
 </Response>
</cXML>

注記
このトランスポート (HTTP) とプロトコル (cXML) レベルの組み合せは、上記の場合に限定してください。

3.2 基本要素

以下のエンティティと要素は、cXML 仕様全体に使用できます。ここで一覧表示している定義のほとんどは、高次元のビジ
ネスドキュメントを記述するための基本的な用語です。ここでは、共通の type エンティティと、低レベルのオブジェクトを表
す共通の要素について定義します。

3.2.1 Type エンティティ

これらの定義の大部分は、W3C (World Wide Web Consortium) に Note として提出された XML-Data で定義されてい
ます。ここで定義されるいくつかの高レベル type エンティティは、XML-Data では定義されていません。

isoLangCode

ISO 639 規格による ISO 言語コードです。

isoStateCode

都道府県/州を識別する ISO 3166-2:2013 国細分コードです。ISO 3166-1 に示されている国コードとともに使用されます。

isoCountryCode

ISO 3166 規格による ISO 国コードです。

xmlLangCode

XML 1.0 仕様書によって定義される言語コード (www.w3.org/TR/1998/REC-xml-19980210.html を参照) です。一般的には、この言語コードには、ISO 639 言語コードと、ハイフンによって区切られる ISO 3166 国コード (任意設定) が含まれます。完全な XML 勧告とは異なる IANA や私的な言語コードを cXML で使用すべきではありません。IANA と私的なサブコードを使用する場合は、それらの前に正しい ISO 3166 国コードを指定してください。推奨される cXML 言語コードフォーマットは、xx[-YY[-zzz]*]? です。ここで、xx は ISO 639 言語コード、YY は ISO 3166 国コード、そして zzz は IANA または該当する言語についての私的なサブコードです。国コードは常に指定するようにしてください。言語コードは小文字、国コードは大文字で表記する規約がありますが、コードが正しく一致するための必要条件ではありません。

UnitOfMeasure

UnitOfMeasure には、製品を梱包して出荷する方法を記述します。数量単位は、数量の共通コードである UN/CEFACT 単位に準拠していなければなりません。参照資料 www.unece.org/cefact/codesfortrade/codes_index.html を参照してください。

URL

HTTP/1.1 規格によって定義された URL (Uniform Resource Locator) です。

3.2.2 ベース要素

この項で説明する要素は、Name や Extrinsic などの一般的な要素から Money などの特定の要素まで、仕様全体に使用されます。

Money

Money 要素には、currency、alternateAmount、および alternateCurrency. の 3 つの属性があります。currency と alternateCurrecy 属性は、必ず ISO 4217 で規定された 3 文字の通貨コードにしてください。Money 要素と aternateAmount (代替通貨) 属性の値は、数値でなければなりません。

例:

<Money currency="USD">12.34</Money>

任意設定の alternateCurrency と alternateAmount 属性は同時に使用し、代替通貨の金額を指定します。これらは、ユーロのような二重通貨をサポートするためにも使用できます。

例:

<Money currency="USD" alternateCurrency="EUR" alternateAmount="14.28">12.34</Money>

注記
任意で 3 桁ごとに区切りのカンマを使用することができます。小数点の代わりにカンマを使用しないでください。

State

都道府県/州または国細分識別子が含まれます。PostalAddress 要素の中で定義します。これには、任意設定の isoStateCode [42 ページ] 属性があります。

<State isoStateCode="US-CA">CA</State>

所在地の項で指定する国名です。PostalAddress 要素の中で定義します。これには、任意設定の isoCountryCode[42 ページ] 属性があります。

<Country isoCountryCode="US">United States</Country>
CountryCode

国コードに対応した、ITU 電話コードです。エスケープコードの後に電話キーパッドから入力して、該当の国に接続します。TelephoneNumber 要素で使用されます。

<TelephoneNumber>
 <CountryCode isoCountryCode="US">1</CountryCode>
 <AreaOrCityCode>800</AreaOrCityCode>
 <Number>5551212</Number>
</TelephoneNumber>
連絡先

Contact 要素には、現在のトランザクションにとって重要などのような連絡先に関する情報も定義できます。

例:

<Contact>
 <Name xml:lang="en-US">Mr. Smart E. Pants</Name>
 <Email>sepants@workchairs.com</Email>
 <Phone name="Office">
 …
 </Phone>
</Contact>



← cXML リファレンスガイド 目次へ戻る

 プロファイルトランザクションを使用すると、サポート対象の cXML のバージョン、トランザクション、およびそれらのトランザクションに対するオプションなどを含む cXML サーバー機能を確認できます。ProfileRequest ドキュメントとProfileResponse ドキュメントは、cXML 1.1 およびそれ以降のバージョンで実装されたすべてのサーバーでサポートされます。

4.1 プロファイルトランザクションの概要

プロファイルトランザクションを使用すると、組織またはグループから相手側に対して、cXML 機能に関する照会ができます。これらの組織には、サプライヤ、バイヤー、ネットワークハブ、サービスプロバイダ、およびマーケットプレイスがあります。サーバー機能を照会するには、ProfileRequest ドキュメントを送信します。サーバーは、そのサーバー情報を含む ProfileResponse ドキュメントを返信します。 cXML を実装したすべてのサーバーは、プロファイルトランザクションをサポートする必要があります。それは、アプリケーション間のバックエンド統合を行うためで、それにより cXML サーバーの機能がクライアントのシステムで使用可能になります。 ProfileResponse には、特定の Web サイトでサポートされるすべての Request が記載されますが、組織がサポートするすべての Request を記載する必要はありません。OrderRequest ドキュメントの受信、さまざまなメッセージの送信、または Request/Response トランザクションの開始を実行できるサプライヤは、プロファイルトランザクションで自社の OrderRequest サポートを記述します。ProfileRequest によって返されたデータはキャッシュしておき、取引を行うコミュニティの管理者によって決められた期間使用できます。プロファイルトランザクションはサーバーを “ping” する cXML プロトコル機能としても使用することができます。プロファイルトランザクションは、ドキュメントのトラッキングでその所在地を検索するためにも使用することができます。この使用方法は、OrderRequest ドキュメントで使用される Followup 要素に代わるものです。任意のドキュメントの送信先を取得するには、ProfileRequest ドキュメントをサーバーに送信します。

4.2 ProfileRequest

この要素には内容はありません。Header を使用して、該当する cXML サーバーに単にルーティングされるだけです。サーバーは、以下に示すように ProfileResponse 要素を 1 つ含めて応答します。この応答で唯一変更される部分は、cXML 要素自体の payloadID 属性と timestamp 属性です。このメッセージに限り、サーバーは複数の地域情報で応答する必要はありません。この種類の Request の例を示します。

<cXML payloadID="9949494" xml:lang="en-US" timestamp="2000-03-12T18:39:09-08:00">
 <Header>
 Routing, identification, and authentication information.
 </Header>
 <Request>
 <ProfileRequest />
 </Request>
</cXML>

ProfileRequest ドキュメントをネットワークハブに送信するときは、「ルート」 URL に送信する必要があります。この URL は絶対に変更されることがありません。このルート URL に ProfileRequest を送信することによって、cXML のすべての Request の種類の URL 所在地を取得できます。ネットワークハブからの ProfileResponse は、ProfileRequest の To 要素によって異なります。

4.3 ProfileResponse

この要素には、サポートされるトランザクション、それらの所在地、およびサポートされるすべてのオプションのリストが含まれます。次のような ProfileResponse を取得できます。

<ProfileResponse effectiveDate="2001-03-03T12:13:14-05:00">
 <Option name="Locale">1</Option>
 …
 <Transaction requestName="PunchOutSetupRequest">
 <URL>http://www.workchairs.com/cXML/PunchOut.asp</URL>
 <Option name="operationAllowed">create inspect</Option>
 <Option name="dynamic pricing">0</Option>
 …
 </Transaction>
 …
</ProfileResponse>

現在のサプライヤから次のような ProfileResponse が取得されます。

<ProfileResponse effectiveDate="2000-01-01T05:24:29-08:00" lastRefresh="2001-09-08T05:24:29-08:00">
 <Transaction requestName="OrderRequest">
 <URL>http://workchairs.com/cgi/orders.cgi</URL>
 <Option name=”service”>workchairs.orders</Option>
 </Transaction>
 <Transaction requestName="PunchOutSetupRequest">
 <URL>http://workchairs.com/cgi/PunchOut.cgi</URL>
 <Option name=”service”>workchairs.signin</Option>
 </Transaction>
</ProfileResponse>

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

属性 説明
effectiveDate(必須) これらのサービスを利用できるようになった日付と時刻。将来の日付は使用できません。
lastRefresh プロファイルのキャッシュの最終更新がいつかを表します。アプリケーションがプロファイルキャッシュサーバーから ProfileResponse を受信すると、キャッシュ内のデータの年数がわかります。

4.3.1 Option 要素

Option 要素には、サービス全体または特定のトランザクションのどちらかに定義されたオプションの値が含まれます。Option には次の属性があります。

属性 説明
name
(必須)
このオプションの名称。この属性をそのまま表示しないでください (プロファイルは機械が読み取るためのものだからです)。ProfileResponse ドキュメントを受信する前に、クライアントシステムはこの制約を理解する必要があります。 name に現在定義されている値は、”service”、”attachments”、”changes”、および”requestNames” です。
4.3.1.1 MAC オプション

ProfileResponse ドキュメントが信頼できるサードパーティ (ネットワークハブなど) によって送信されており、MAC 認証を前提としたトランザクションがリストされている場合には、MAC 認証値をリストした Option 要素が含まれます。クライアントは、サーバーに直接送信するドキュメント内の CredentialMac 要素にこれらの値を挿入します。

例:

<ProfileResponse>
 <Option name="CredentialMac.type">FromSenderCredentials</Option>
 <Option name="CredentialMac.algorithm">HMAC-SHA1-96</Option>
 <Option name="CredentialMac.creationDate">2003-01-17T17:39:09-08:00</Option>
 <Option name="CredentialMac.expirationDate">2003-01-17T23:39:09-08:00</Option>
 <Option name="CredentialMac.value">67mURtR6VI6YnIsK</Option>
</ProfileResponse>

サーバーがダイレクトパンチアウトをサポートしている場合は、ProfileResponse 内の PunchOutSetupRequestに追加の Option 要素が表示されます。

4.3.1.2 サービス

プロファイルトランザクションでは、1 つのトランザクションタイプについて複数のバリエーションを返せます。 cXML サーバーが特定のトランザクションについて複数の実装をサポートしている場合、ProfileResponse でそれらを区別することができます。たとえば、マーケットプレイスが ProviderSetupRequest トランザクション内で marketplace.signin と marketplace.console という 2 つのサービスを提供しているとします。ProfileReponse では、その 2 つを区別できるように一覧表示される必要があります。 ProfileResponse は、1 トランザクションのバリエーションごとに、特定の所在地を一意に識別できます。 ProviderSetupRequest の場合、バリエーションはサービス名です。ProfileResponse では Option 要素を使用して、サービス名と値が設定されます。次に例を示します。

<Transaction requestName=”ProviderSetupRequest”>
 <URL>http://service.hub.com/signin</URL>
 <Option name="service">signin</Option>
</Transaction>
<Transaction requestName=”ProviderSetupRequest”>
 <URL>http://service.hub.com/console</URL>
 <Option name="service">console</Option>
</Transaction>

特定のトランザクションタイプの所在地が 1 つしかない場合は、Option 要素は不要です。特定のトランザクションタイプの検索で、Option name=”service” と記述されている場合は、記述されたサービスに一致するトランザクションを使用します。そのような Option 名と値に一致するものがない場合は、オプション名と値のない最初のトランザクションを使用します。1 トランザクションの各バリエーションは、それ自体の特定の所在地を一意に識別する必要があります。 ProviderSetupRequest の場合、一意に識別できる識別子は「service」です。これらの識別子では、Transaction 要素の Option 要素が使用されます。この Option 要素には、一意に識別できる識別子名が含まれます。この Option 要素の値は、一意に識別できる識別子の値です。

4.3.1.3 PunchOutSetupRequest オプション

PunchOutSetupRequest がサポート対象のトランザクションとして返された場合、ダイレクトパンチアウトがサポートされていることを示す 3 つのオプションを指定できます。これらのオプションによって、認証のためネットワークハブ経由にすることなく PunchOutSetupRequest ドキュメントをサーバーに直接送信可能であること、およびどの認証方法がサポートされているかがクライアントに通知されます。

  • ダイレクトパンチアウトの PunchOutSetupRequest ドキュメントを直接受信する URL を指定するには、次のようにします。
  • <Option name="Direct.URL">https://asp.workchairs.com/directPunchout</Option>
    
  • サーバーでメッセージ認証コード (MAC) による認証がサポートされていることを示すには、次のようにします。
  • <Option name="Direct.AuthenticationMethod.CredentialMac">Yes</Option>
    

    さらに、このオプションは、この信頼できるサードパーティに対してサーバーのメッセージ認証コード (MAC) を生成するように指示しています。信頼できるサードパーティが送信したプロファイルの ProfileResponse 要素内には、追加の Option 要素が表示されます。

  • サーバーでデジタル証明書による認証方法がサポートされていることを示すには、次のようにします。
  • <Option name="Direct.AuthenticationMethod.Certificate">Yes</Option>
    

    このオプションは、PunchOutSetupRequest を検証するために、サーバーにより AuthRequest ドキュメントが送信されることを示しています。これらのオプションは通常のパンチアウトには使用されません。

    4.3.1.4 OrderRequest オプション

    OrderRequest がサポート対象のトランザクションとして返された場合は、attachments と changes という 2 つのオプションを指定する必要があります。attachments オプションでは、添付ファイルが受け取られるかどうかが指定されます。changes オプションでは、変更オーダーと削除オーダーが受け取られるかどうかが指定されます。添付ファイルの受け取りの指定は、次のとおりです。

    <Option name = "attachments">Yes</Option>
    

     変更オーダー受け取りの指定は、次のとおりです。

    <Option name = "changes">Yes</Option>
    

    どちらのオプションも、通常の値は No です。attachments または changes が No に設定されているドキュメントは、これらのオプションの記述がないドキュメントとまったく同様に処理する必要があります。

    4.3.1.5 SessionStatusRequest オプション

    SessionStatusRequest がサポート対象の取引として返された場合、requestNames というオプションを指定する必要があります。このオプションには通常の値はありません。このオプションでは、Option 要素の内容で指定したどのトランザクションの実行時にも、サーバーがセッションのチェックと更新をサポートすることがクライアントに通知されます。この内容は、「OrderStatusSetupRequest」、「ProviderSetupRequest」、および「PunchOutSetupRequest」の組み合せをスペースで区切った形式のリストで指定する必要があります。一覧表示された各 Request の Transaction 要素も、ProfileResponse ドキュメントに含まれる必要があります。

    4.3.2 トランザクション

    サーバーのサービスによってサポートされるトランザクションの説明です。プロファイル定義は、特定の Request を送信する宛先の現在の所在地を示します。cXML の将来のバージョンでは、さらに Option 定義が追加されるとともに、現在サポートされている Request のより詳細な情報が含まれるようにプロファイル情報が拡張される可能性があります。 Transaction 要素には URL 属性が含まれている必要があります。Transaction には次の属性があります。

    属性 説明
    requestName(必須) このサーバーが特定の Request を受け付ける URL を指定します。この値は、cXML で定義されている Request ドキュメント名のいずれかになります。

    4.4 シナリオ

    ProfileRequest ドキュメントをさまざまな組織またはグループから送信して、サプライヤ、バイヤー、ネットワークハブ、サービスプロバイダ、およびマーケットプレイスのサーバー機能および情報を取得することができます。次のシナリオで現実的な組織の組み合せと、そこから入手できるトランザクション情報の種類について、説明します。

    4.4.1 バイヤーからサプライヤへ

    ProfileRequest ドキュメントは、ネットワークハブを介してバイヤーからサプライヤに送信されます。ネットワークハブは、定期的にサーバー情報をサプライヤに照会してキャッシュします。この情報は、バイヤーに送信する ProfileResponse ドキュメントで使用されます。

    図 3: バイヤーからサプライヤに送信される ProfileRequest

    サプライヤは、サポートしているトランザクションを ProfileResponse で返します。

    例:

  • OrderRequest
  • PunchOutSetupRequest

    バイヤーに送信される ProfileResponse には、そのサプライヤに代わってネットワークハブが提供する機能も含めることができます。

    4.4.2 バイヤーからネットワークハブへ

    ProfileRequest ドキュメントは、バイヤーからネットワークハブに送信されます。

    図 4: バイヤーからネットワークハブに送信される ProfileRequest ドキュメント

    ネットワークハブは、サポートしているトランザクションを ProfileResponse で返します。

    例:

  • SupplierDataRequest
  • SubscriptionListRequest
  • SubscriptionContentRequest
  • GetPendingRequest
  • OrderStatusSetupRequest
  • SupplierListRequest
  • ProviderSetupRequest
  • SessionStatusSetupRequest

    ProfileRequest ドキュメントの例:

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE cXML SYSTEM "http://xml.cXML.org/schemas/cXML/1.2.014/cXML.dtd">
    <cXML payloadID="9949494" xml:lang="en-US" timestamp="2002-02-04T18:39:09-08:00">
     <Header>
     <From>
     <Credential domain="NetworkId">
     <Identity>AN01001010101</Identity> <!-- marketplace's id -->
     </Credential>
     </From>
     <To>
     <Credential domain="NetworkId">
     <Identity>AN01000000001</Identity> <!-- Network -->
     </Credential>
     </To>
     <Sender>
     <Credential domain="NetworkId">
     <Identity>AN01001010101</Identity>
     <!-- marketplace's shared secret -->
     <SharedSecret>abracadabra</SharedSecret>
     </Credential>
     <UserAgent>Marketplace 7.5</UserAgent>
     </Sender>
     </Header>
     <Request>
     <ProfileRequest />
     </Request>
    </cXML>
    

    ProfileResponse ドキュメントの例:

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE cXML SYSTEM "http://xml.cXML.org/schemas/cXML/1.2.014/cXML.dtd">
    <cXML payloadID="9949494" xml:lang="en-US" timestamp="2002-02-04T18:39:49-08:00">
     <Response>
     <Status code="200" text="OK"/>
     <ProfileResponse effectiveDate="2002-01-01T05:24:29-08:00">
     <Transaction requestName="OrderStatusSetupRequest">
     <URL>https://superduper.com/a/OrderStatusSetup</URL>
     </Transaction>
     <Transaction requestName="GetPendingRequest">
     <URL>https://superduper.com/a/GetPending</URL>
     </Transaction>
     <Transaction requestName="SubscriptionListRequest">
     <URL>https://superduper.com/b/SubscriptionList</URL>
     </Transaction>
     <Transaction requestName="SubscriptionContentRequest">
     <URL>https://superduper.com/b/SubscriptionContent</URL>
     </Transaction>
     <Transaction requestName="SupplierListRequest">
     <URL>https://superduper.com/c/SupplierList</URL>
     </Transaction>
     <Transaction requestName="SupplierDataRequest">
     <URL>https://superduper.com/c/SupplierData</URL>
     </Transaction>
     <Transaction requestName="ProviderSetupRequest">
     <URL>https://superduper.com/d/ProviderSetup</URL>
     </Transaction>
     <Transaction requestName="SessionStatusRequest">
     <URL>https://superduper.com/d/SessionStatus</URL>
     <Option name="requestNames">OrderStatusSetupRequest</Option>
     </Transaction>
     </ProfileResponse>
     </Response>
    </cXML>
    

    4.4.3 ネットワークハブからサプライヤへ

    ProfileRequest は、ネットワークハブからサプライヤに送信されます。ネットワークハブは、定期的にサーバー情報をサプライヤに照会してキャッシュします。この特定のサプライヤに関する情報は、バイヤー企業に送信する ProfileResponse ドキュメントで使用されます。

    図 5: ネットワークハブからサプライヤに送信される ProfileRequest

    サプライヤは、サポートしているトランザクションを ProfileResponse ドキュメントで返します。

    例:

  • OrderRequest
  • PunchOutSetupRequest

    ProfileRequest ドキュメントの例:

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE cXML SYSTEM "http://xml.cXML.org/schemas/cXML/1.2.014/cXML.dtd">
    <cXML payloadID="9949494" xml:lang="en-US" timestamp="2002-02-04T18:39:09-08:00">
     <Header>
     <From>
     <Credential domain="NetworkId">
     <Identity>AN01001010101</Identity> <!-- Network's id -->
     </Credential>
     </From>
     <To>
     <Credential domain="NetworkId">
     <Identity>AN01234663636</Identity> <!-- any supplier's id -->
     </Credential>
     </To>
     <Sender>
     <Credential domain="NetworkId">
     <Identity>AN01001010101</Identity>
     <!-- Network's sharedscret -->
     <SharedSecret>abracadabra</SharedSecret>
     </Credential>
     <UserAgent>Marketplace 7.5</UserAgent>
     </Sender>
     </Header>
     <Request>
     <ProfileRequest />
     </Request>
    </cXML>
    
    

    ProfileResponse ドキュメントの例:

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE cXML SYSTEM "http://xml.cXML.org/schemas/cXML/1.2.014/cXML.dtd">
    <cXML payloadID="9949494" xml:lang="en-US" timestamp="2002-02-04T18:39:49-08:00">
     <Response>
     <Status code="200" text="OK"/>
     <ProfileResponse effectiveDate="2002-01-01T05:24:29-08:00">
     <Transaction requestName="PunchOutSetupRequest">
     <URL>https://www.acme.com/cxml/PunchOutSetup</URL>
     </Transaction>
     <Transaction requestName="OrderRequest">
     <URL>https:// www.acme.com/cxml /Order</URL>
     <Option name="attachments">yes</Option>
     <Option name="changes">yes</Option>
     </Transaction>
     </ProfileResponse>
     </Response>
    </cXML>
    

    4.4.4 ネットワークハブからサービスプロバイダへ

    ProfileRequest は、ネットワークハブからサービスプロバイダに送信されます。ルーティングサービスプロバイダは、返信される ProfileReponses の数が 1 つであるか 2 つであるかを指定する必要があります。プロファイル情報はサービスプロバイダおよびサービスプロバイダに紐付けられたサプライヤアカウントの両方に返信することができるためです。

    図 6: ネットワークハブからサービスプロバイダに送信される ProfileRequest

    サービスプロバイダは、サポートしているトランザクションを ProfileResponse ドキュメントで返します。

    例:

  • ProviderSetupRequest
  • SessionStatus
  • OrderRequest

    4.4.5 ネットワークハブからバイヤーへ

    ProfileRequest は、ネットワークハブからバイヤーに送信されます。ネットワークハブは、定期的にサーバー情報をバイヤーに照会してキャッシュします。後で、バイヤーに関するこの情報は、サービスプロバイダとサプライヤに送信される ProfileResponse ドキュメントで使用されます。

    図 7: ネットワークハブからバイヤーに送信される ProfileRequest

    バイヤーは、サポートしているトランザクションを ProfileResponse ドキュメントで返します。

    例:

  • StatusUpdateRequest
  • InvoiceDetailRequest

    4.4.6 サービスプロバイダからバイヤーへ

    ProfileRequest はネットワークハブを介してルーティングされ、サービスプロバイダからバイヤーに送信されます。このシナリオは、Followup 要素に代わるものです。ネットワークハブは、定期的にサーバー情報をバイヤーに照会してキャッシュします。後で、バイヤーに関するこの情報は、サービスプロバイダに送信される ProfileResponse ドキュメントで使用されます。

    図 8: サービスプロバイダからバイヤーに送信される ProfileRequest

    ネットワークハブは、バイヤーの代わりにサポートしているトランザクションを ProfileResponse でサービスプロバイダに返します。

    例:

  • StatusUpdateRequest
  • InvoiceDetailRequest



    ← cXML リファレンスガイド 目次へ戻る

     パンチアウトを使用すると、購買アプリケーションのユーザーは、サプライヤの 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 サイトにあるユーザーアカウントにログインします。次の図は、パンチアウト要求手順を示しています。

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

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

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

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

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

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

    5.2.2 手順 3: 製品の選択

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

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

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

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

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

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

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

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

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

    5.2.4 手順 5: 注文書の送信

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

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

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

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

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

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

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

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

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

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

    <?xml version="1.0" encoding="UTF-8"?>
    <!-- type of cXML doc and URL of DTD -->
    <!DOCTYPE Index SYSTEM "http://xml.cxml.org/schemas/cXML/1.2.016/cXML.dtd">
    <Index>
     <SupplierID domain="DUNS">83528721</SupplierID>
     <IndexItem>
     <IndexItemPunchout>
     <ItemID>
     <!-- The supplier’s identifier for the PunchOut item -->
     <SupplierPartID>5555</SupplierPartID>
     </ItemID> <PunchoutDetail punchoutLevel="shelf">
     <Description xml:lang="en-US">Desk Chairs</Description>
     <Description xml:lang="fr-FR">Chaises de Bureau</Description>
     <!-- URL of the PunchOut website (launch page) if not configured elsewhere -->
     <URL>http://www.workchairs.com/punchout.asp</URL>
     <Classification domain="UNSPSC">5136030000</Classification>
     </PunchoutDetail>
     </IndexItemPunchout>
     </IndexItem>
    </Index>
    

    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 ドキュメントの例を以下に示します。

    <?xml version="1.0"?>
    <!DOCTYPE cXML SYSTEM "http://xml.cxml.org/schemas/cXML/1.2.014/cXML.dtd">
    <cXML xml:lang="en-US" payloadID="933694607118.1869318421@jlee" timestamp="2002-08-15T08:36:47-07:00">
     <Header>
     <!-- Originator (buying organization) -->
     <From>
     <Credential domain="DUNS">
     <Identity>65652314</Identity>
     </Credential>
     </From>
     <!-- Destination (supplier) -->
     <To>
     <Credential domain="DUNS">
     <Identity>83528721</Identity>
     </Credential>
     </To>
     <!-- Previous relaying entity (network hub in this case) -->
     <Sender>
     <Credential domain="NetworkId">
     <Identity>AN200001</Identity>
     <SharedSecret>abracadabra</SharedSecret>
     </Credential>
     <UserAgent>Procurement System 2.0</UserAgent>
     </Sender>
     </Header>
     <Request>
     <!-- type of request -->
     <PunchOutSetupRequest operation="create">
     <BuyerCookie>1CX3L4843PPZO</BuyerCookie>
     <Extrinsic name="UserEmail">jsmith</Extrinsic>
     <Extrinsic name="UniqueName">John_Smith</Extrinsic>
     <Extrinsic name="CostCenter">610</Extrinsic>
     <!-- destination for final PunchOutOrderMessage -->
     <BrowserFormPost>
     <URL>https://bigbuyer.com:2600/punchout?client=NAwl4Jo</URL>
     </BrowserFormPost>
     <SupplierSetup>
     <URL>http://www.workchairs.com/punchout.asp</URL>
     </SupplierSetup>
     <ShipTo>
     <Address addressID="1000467">
     <Name xml:lang="en">1000467</Name>
     <PostalAddress>
     <DeliverTo>John Smith</DeliverTo>
     <Street>123 Main Street</Street>
     <City>Sunnyvale</City>
     <State isoStateCode="US-CA">CA</State>
     <PostalCode>94089</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     </PostalAddress>
     </Address>
     </ShipTo>
     <!-- item selected by user -->
     <SelectedItem>
     <ItemID>
     <SupplierPartID>5555</SupplierPartID>
     </ItemID>
     </SelectedItem>
     </PunchOutSetupRequest>
     </Request>
    </cXML>
    

    先頭部分にある 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 セッションの開始要求の例を以下に示します。

    <?xml version="1.0"?>
    <!DOCTYPE cXML SYSTEM "http://xml.cxml.org/schemas/cXML/1.2.014/cXML.dtd">
    <cXML xml:lang="en-US" payloadID="933695135608.677295401@jlee" timestamp="2002-08-15T08:45:35-07:00">
     <Header>
     <From>
     <Credential domain="DUNS">
     <Identity>65652314</Identity>
     </Credential>
     </From>
     <To>
     <Credential domain="DUNS">
     <Identity>83528721</Identity>
     </Credential>
     </To>
     <Sender>
     <Credential domain="NetworkId">
     <Identity>AN200001</Identity>
     <SharedSecret>abracadabra</SharedSecret>
     </Credential>
     <UserAgent>Procure 2.1</UserAgent>
     </Sender>
     </Header>
     <Request>
     <PunchOutSetupRequest operation="edit">
     <BuyerCookie>1CX3L4843PPZO</BuyerCookie>
     <Extrinsic name="UserEmail">jsmith</Extrinsic>
     <Extrinsic name="UniqueName">John_Smith</Extrinsic>
     <Extrinsic name="CostCenter">610</Extrinsic>
     <BrowserFormPost>
     <URL>https://bigbuyer.com:2600/punchout?client=NAwliuo</URL>
     </BrowserFormPost>
     <SupplierSetup>
     <URL>http://www.workchairs.com/punchout.asp</URL>
     </SupplierSetup>
     <ItemOut quantity="2">
     <ItemID>
     <SupplierPartID>220-6338</SupplierPartID>
     <SupplierPartAuxiliaryID>E000028901
     </SupplierPartAuxiliaryID>
     </ItemID>
     </ItemOut>
     </PunchOutSetupRequest>
     </Request>
    </cXML>
    

    ユーザーがカタログ品目を選択して 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 ドキュメントの例を次に示します。

    <?xml version="1.0"?>
    <!DOCTYPE cXML SYSTEM "http://xml.cxml.org/schemas/cXML/1.2.014/cXML.dtd">
    <cXML xml:lang="en-US" payloadID="933694607739" timestamp="2002-08-15T08:46:00-07:00">
     <Response>
     <Status code="200" text="success"></Status>
     <PunchOutSetupResponse>
     <StartPage>
     <URL>
     http://xml.workchairs.com/retrieve?reqUrl=20626;Initial=TRUE
     </URL>
     </StartPage>
     </PunchOutSetupResponse>
     </Response>
    </cXML>
    

    5.3.4 PunchOutOrderMessage

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

    <?xml version="1.0"?>
    <!DOCTYPE cXML SYSTEM "http://xml.cxml.org/schemas/cXML/1.2.014/cXML.dtd">
    <cXML xml:lang="en-US" payloadID="933695160894" timestamp="2002-08-15T08:47:00-07:00">
     <Header>
     <From>
     <Credential domain="DUNS">
     <Identity>83528721</Identity>
     </Credential>
     </From>
     <To>
     <Credential domain="DUNS">
     <Identity>65652314</Identity>
     </Credential>
     </To>
     <Sender>
     <Credential domain="workchairs.com">
     <Identity>website 1</Identity>
     </Credential>
     <UserAgent>Workchairs cXML Application</UserAgent>
     </Sender>
     </Header>
     <Message>
     <PunchOutOrderMessage>
     <BuyerCookie>1CX3L4843PPZO</BuyerCookie>
     <PunchOutOrderMessageHeader operationAllowed="edit">
     <Total>
     <Money currency="USD">763.20</Money>
     </Total>
     </PunchOutOrderMessageHeader>
     <ItemIn quantity="3">
     <ItemID>
     <SupplierPartID>5555</SupplierPartID>
     <SupplierPartAuxiliaryID>E000028901
     </SupplierPartAuxiliaryID>
     </ItemID>
     <ItemDetail>
     <UnitPrice>
     <Money currency="USD">763.20</Money>
     </UnitPrice>
     <Description xml:lang="en">
     <ShortName>Excelsior Desk Chair</ShortName>
     Leather Reclining Desk Chair with Padded Arms
     </Description>
     <UnitOfMeasure>EA</UnitOfMeasure>
     <Classification domain="UNSPSC">5136030000
     </Classification>
     <LeadTime>12</LeadTime>
     </ItemDetail>
     </ItemIn>
     </PunchOutOrderMessage>
     </Message>
    </cXML>
    

    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 ドキュメントが含まれます。

    <FORM METHOD=POST ACTION=<%= url%>>
     <INPUT TYPE=HIDDEN NAME="cxml-urlencoded" VALUE="<% CreateCXML toUser, fromUser, buyerCookie, unitPrice, supPartId, supPartAuxId, desc%>">
     <INPUT TYPE=SUBMIT value=BUY>
    </FORM>
    

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

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

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

    5.4.4 オーダー受信ページ

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

    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 メッセージフローの順序は、次の図のとおりです。

    図 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 要素の例を次に示します。

    <Header>
     <From>
     <Credential domain="DUNS">
     <Identity>65652314</Identity>
     </Credential>
     </From>
     <To>
     <Credential domain="DUNS">
     <Identity>83528721</Identity>
     </Credential>
     </To>
     <Sender>
     <Credential domain="NetworkId">
     <Identity>AN12345</Identity>
     <SharedSecret>abracadabra</SharedSecret>
     </Credential>
     <UserAgent>Procure Software 3.3</UserAgent>
     </Sender>
    </Header>
    
    From

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

    To

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

    Sender

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

    UserAgent

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

    5.6.2.2 PunchOutSetupRequest

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

    <!ELEMENT PunchOutSetupRequest (
     BuyerCookie,
     Extrinsic*,
     BrowserFormPost?,
     Contact*,
     SupplierSetup?,
     ShipTo?,
     SelectedItem?,
     ItemOut*)>
    

    PunchOutSetupRequest の例を次に示します。

    <PunchOutSetupRequest operation="create">
     <BuyerCookie>34234234ADFSDF234234</BuyerCookie>
     <Extrinsic name="UserEmail">betty</Extrinsic>
     <Extrinsic name="UniqueName">BettyBuyer</Extrinsic>
     <Extrinsic name="CostCenter">Marketing</Extrinsic>
     <BrowserFormPost>
     <URL>http://orms.acme.com:1616/punchoutexit</URL>
     </BrowserFormPost>
     <SelectedItem>
     <ItemID>
     <SupplierPartID>54543</SupplierPartID>
     </ItemID>
     </SelectedItem>
     <SupplierSetup>
     <URL>http://workchairs.com/cxml</URL>
     </SupplierSetup>
     <ShipTo>
     <Address addressID="1000467">
     <Name xml:lang="en">1000467</Name>
     <PostalAddress>
     <DeliverTo>Betty Buyer</DeliverTo>
     <Street>123 Main Street</Street>
     <City>Sunnyvale</City>
     <State isoStateCode="US-CA">CA</State>
     <PostalCode>94089</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     </PostalAddress>
     </Address>
     </ShipTo>
    </PunchOutSetupRequest>
    

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

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

    この要素には、BuyerCookie、Extrinsic、BrowserFormPost、Contact、ShipTo、SelectedItem、SupplierSetup の各要素と ItemOut リスト要素も含まれます。BuyerCookie 要素のみが必須です。Extrinsic要素、Contact, 要素、および ShipTo 要素の構造については、「OrderRequestHeader 要素 」でより詳細に説明されています。ItemOut 要素については、「ItemOut」で説明されています。このコンテキスト(OrderRequest 外) では、Distribution 要素と Comments 要素、および ItemOut の lineNumber 属性、 requisitionID 属性、requestedDeliveryDate 属性は値をほとんど追加しないか、まったく追加しないため、含めないようにする必要があります。パンチアウトセッションはオーダーの前に発生するため、この情報は PunchOutSetupRequest 内では関連性がありません。ItemOut リストには、既存のショッピングカートの内容 (以前のパンチアウトセッションの品目) が記述されます。 inspect 操作では、(クライアントとサーバーの両方で実施される) 読み取り専用パンチアウトセッションが開始され、記述されている品目の詳細が表示されます。edit 操作も (ItemOut リストを使用して記述される) 以前のショッピングカートから開始されますが、変更を行うことができます。edit 操作がサポートされることは、inspect もサポートされることを示します (「PunchOutOrderMessageHeader」および「空のショッピングカート」を参照)。このリストには、ソーシングされた品目も記述されます。詳細については、「Sourcing」を参照してください。サプライヤの 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 プロトコルを拡張し、すべての実装にとって必ずしも必要とはならないような機能をサポートします。次のコンテキストでは、新しいデータはパンチアウト要求を開始するユーザーの詳細を表します。

    <Extrinsic name="department">Marketing</Extrinsic>
    

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

    <Extrinsic name="CostCenter"">450</Extrinsic>
    <Extrinsic name="User">jsmith</Extrinsic>
    

    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>5555</SupplierPartID>
     </ItemID>
    </SelectedItem>
    

    購買アプリケーションは、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 を使用して応答します。

    <PunchOutSetupResponse>
     <StartPage>
     <URL>
     http://premier.workchairs.com/store?23423SDFSDF23
     </URL>
     </StartPage>
    </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>
     <BuyerCookie>34234234ADFSDF234234</BuyerCookie>
     <PunchOutOrderMessageHeader operationAllowed="create">
     <Total>
     <Money currency="USD">100.23</Money>
     </Total>
     </PunchOutOrderMessageHeader>
     <ItemIn quantity="1">
     <ItemID>
     <SupplierPartID>1234</SupplierPartID>
     <SupplierPartAuxiliaryID>
     additional data about this item
     </SupplierPartAuxiliaryID>
     </ItemID>
     <ItemDetail>
     <UnitPrice>
     <Money currency="USD">10.23</Money>
     </UnitPrice>
     <Description xml:lang="en">
     Learn ASP in a Week!
     </Description>
     <UnitOfMeasure>EA</UnitOfMeasure>
     <Classification domain="SPSC">12345</Classification>
     <LeadTime>1</LeadTime>
     </ItemDetail>
     </ItemIn>
    </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 」を参照してください。
    Path パンチアウト連鎖シナリオでユーザーが移動するパスを記録するノードのリストです。「Path 要素」を参照してください。
    ItemDetail
    (必須)
    購買アプリケーションでユーザーに提示される品目に関する記述的な情報が含まれます。「ItemDetail」を参照してください。
    SupplierID | SupplierList ソーシングプロセスに関与できるサプライヤのリストが指定されます。
    ● SupplierID はサプライヤの ID です。
    ● SupplierList には、各サプライヤの Name および SupplierID のリストが含まれます。
    SupplierID または SupplierList」を参照してください。
    ShipTo 品目の出荷先住所です。ShipTo には、4 つの要素(AddressaCarrierIdentifier、TransportInformation、および IdReference) が含まれます。
    Shipping cXML 出荷明細の定義です。ショッピングカートの出荷費用を表します。
    Tax 税に関する情報。
    SpendDetail 支出詳細情報が取得されます。「SpendDetail」を参照してください。
    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 の例を次に示します。

    <ItemIn quantity="2" openQuantity="2" promisedQuantity="2" itemCategory="subcontract">
     <ItemID>
     <SupplierPartID>1234</SupplierPartID>
     <SupplierPartAuxiliaryID>supplier cookie to describe configuration options on this item</SupplierPartAuxiliaryID>
     </ItemID>
     <ItemDetail>
     <UnitPrice>
     <Money currency="USD">10.23</Money>
     </UnitPrice>
     <Description xml:lang="en">UX Design Principles</Description>
     <UnitOfMeasure>EA</UnitOfMeasure>
     <Classification domain="SPSC">12345</Classification>
     <ManufacturerPartID>ISBN-23455634</ManufacturerPartID>
     <ManufacturerName>Way Cool Tech Books</ManufacturerName>
     </ItemDetail>
     <DateInfo type="confirmedShipmentDate" date="2017-06-25T18:02:53-07:00"/>
     <DateInfo type="confirmedDeliveryDate" date="2017-06-27T18:02:53-07:00"/>
    </ItemIn>
    <ItemIn quantity="2" openQuantity="2" promisedQuantity="1">
     <ItemID>
     <SupplierPartID>4567</SupplierPartID>
     </ItemID>
     <ItemDetail>
     <UnitPrice>
     <Money currency="USD">50</Money>
     </UnitPrice>
     <Description xml:lang="en">Python Deep Dive</Description>
     <UnitOfMeasure>EA</UnitOfMeasure>
     <Classification domain="SPSC">12345</Classification>
     <ManufacturerPartID>ISBN-123456</ManufacturerPartID>
     <ManufacturerName>Way Cool Tech Books</ManufacturerName>
     <DateInfo type="confirmedShipmentDate" date="2017-06-25T18:02:53-07:00"/>
     <DateInfo type="confirmedDeliveryDate" date="2017-06-27T18:02:53-07:00"/>
     </ItemDetail>
    </ItemIn>
    
    5.6.4.4.1 ItemID

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

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

    例:

    <Description xml:lang="en-US">
    <ShortName>Big Computer</ShortName>
    This wonder contains three really big disks, ....
    </Description>
    

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

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

    例:

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

    例:

    <ExpectedLimit>
     <Money currency="USD">800.00</Money>
    </ExpectedLimit>
    
    UnitOfMeasure
    (必須)
    製品を梱包または出荷する方法が記述されます。数量単位の共通コードである UN/CEFACT 単位に準拠している必要があります。参照資料 www.unece.org/cefact/codesfortrade/codes_index.html を参照してください。PriceBasisQuantity 明細の数量ベースの価格設定が記述されます。要素として UnitOfMeasure および Description 、属性として quantity および conversionFactor が含まれます。. 「PriceBasisQuantity」を参照してください。
    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 バイヤーが製品を受け取るまでに必要な日数が指定されます。
    例:

    <LeadTime>14</LeadTime>
    
    Dimension 品目の次元が指定されます。「Dimension」を参照してください。
    ItemDetailIndustry 業種固有の詳細情報が含まれます。「ItemDetailIndustry」を参照してください。
    AttachmentReference リモート添付ファイルへの参照が含まれます。「AttachmentReference」を参照してください。
    PlannedAcceptanceDays バイヤーがスケジュールした、商品を受け取ってから検査を行うまでの日数が指定されます。
    Extrinsic このオブジェクトに関連するすべての追加情報が含まれます。「Extrinsic」を参照してください。
    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 が推奨されています。
    Table Table

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

    <ItemDetail>
     ...
     <AttachmentReference version="1">
     <Name xml:lang="en">name of remote file</Name>
     <Description xml:lang="en">Description Text</Description>
     <InternalID></InternalID>
     <URL>https://link.to/remote.file</URL>
     </AttachmentReference>
     ...
    </ItemDetail>
    
    5.6.4.4.3 SupplierID または SupplierList

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

    <ItemOut quantity="6" lineNumber="1">
     <ItemID>
     <SupplierPartID>unknown</SupplierPartID>
     </ItemID>
     <ItemDetail>
     <UnitPrice>
     <Money currency="USD">10.23</Money>
     </UnitPrice>
     <Description xml:lang="en">Learn ASP in a Week!</Description>
     <UnitOfMeasure>EA</UnitOfMeasure>
     <Classification domain="SPSC">12345</Classification>
     <ManufacturerPartID>ISBN-23455634</ManufacturerPartID>
     <ManufacturerName>O'Reilly</ManufacturerName>
     <URL> URL for more information </URL>
     <LeadTime>7</LeadTime>
     </ItemDetail>
     <SupplierList>
     <Supplier>
     <Name xml:lang="en">Supplier #1 </Name>
     <SupplierID domain="duns">0000000</SupplierID>
     </Supplier>
     <Supplier>
     <Name xml:lang="en">Supplier #2 </Name>
     <SupplierID domain="duns">1111111</SupplierID>
     <SupplierID domain="duns">2222222</SupplierID>
     </Supplier>
     </SupplierList>
    </ItemOut>
    

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

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

    5.7.1 認証方法

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

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

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

    5.7.2 ProfileResponse

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

    <Transaction requestName="PunchOutSetupRequest">
     <URL>https://service.bighub.com/cxml</URL>
     <Option name="Direct.URL">https://bigsupplier.com/punchout</Option>
     <Option name="Direct.AuthenticationMethod.CredentialMac">Yes</Option>
     <Option name="Direct.AuthenticationMethod.Certificate">Yes</Option>
    



    ← cXML リファレンスガイド 目次へ戻る

     購入申請は、購買プロセスの最初の手順です。購入申請は、品目を購入するための申請です。購入申請には、それぞれ一意の ID (PR2394 など) が割り当てられます。この ID によって、購買のプロセス全体を通じて購入申請の処理状況を追跡できます。各購入申請には、複数の明細を含めることができます。各購入申請には、「申請者の会社のカタログ」「サプライヤのカタログ (PunchOut カタログ)」「カタログ外品目 (別のソースから)」のソースのいずれかから品目を含めることができます。

    6.1 購入申請のプロセス

    このトピックでは、一般的な購入申請のプロセスについて説明します。このプロセスは、購買システムによって異なる場合があります。

    1. 従業員が品目を検索し、購入申請を作成します。
    2. 購入申請が提出されると、以下のいずれが実行されます。
      • 承認が必要な品目の場合は、購入申請が組織内の承認者に送信されます。購入申請が承認されると、サプライヤに注文書が送信されます。購入申請が却下された場合は、購入申請者に通知されます。この場合は、購入申請を取り消すことも、編集した上で承認を受けるために再提出することもできます。
      • 承認が不要な品目の場合は、直接サプライヤに注文書が送信されます。
    3. サプライヤが注文書を受け取り、オーダーの履行に同意する場合は、その品目を出荷します。
    4. 購買組織は、品目が到着したら、品目の受領書を作成します。サプライヤに受領書が送信されます。
    5. サプライヤは、受領書を受け取ったら、支払いを求める請求書を発行します。

    注記
    通常は、購買担当者が品目のオーダーおよび受領を管理し、購入申請を提出した人物にそれらの品目を送ります。

    6.2 PurchaseRequisitionRequest

    PurchaseRequisitionRequest は購入申請を定義します。これには、バイヤーから別のバイヤーシステムに送信されたデータが含まれます。属性はなく、1 つの要素 PurchaseRequisition が含まれます。PurchaseRequisitionRequest 要素の構造は次のとおりです。

    <PurchaseRequisitionRequest>
     <PurchaseRequisition>
     <PurchaseRequisitionHeader>
     <Shipping/>
     <Tax/>
     <Total/>
     <ShipTo/>
     <BillTo/>
     <Contact/>
     <Comments/>
     <DocumentReference/>
     <Extrinsic/>
     </PurchaseRequisitionHeader>
     <ItemIn>
     <ItemID/>
     <Path/>
     <ItemDetail/>
     <SupplierID/> | <SupplierList/>
     <ShipTo/>
     <Shipping/>
     <Tax/>
     <SpendDetail/>
     <Distribution/>
     <Contact/>
     <Comments/>
     <BillTo/>
     </ItemIn>
     </PurchaseRequisition>
    </PurchaseRequisitionRequest>
    

    PurchaseRequisitionRequest の例を次に示します。

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE cXML SYSTEM "http://xml.cxml.org/schemas/cXML/1.2.026/cXML.dtd">
    <cXML payloadID="req00001" timestamp="2016-05-26T00:00:00-08:00" xml:lang="enUS">
     <Header>
     <From>
     <!-- Ariba Network buyer account -->
     <Credential domain="NetworkID">
     <Identity>AN71000002012</Identity>
     </Credential>
     <Credential domain="EndPointID">
     <Identity>ERP</Identity>
     </Credential>
     </From>
     <To>
     <!-- Ariba Network buyer account -->
     <Credential domain="NetworkID">
     <Identity>AN71000002012</Identity>
     </Credential>
     <Credential domain="EndPointID">
     <Identity>ERP</Identity>
     </Credential>
     </To>
     <Sender>
     <!-- This document has passed from the ERP
     to the Ariba Procurement Solution. -->
     <Credential domain="NetworkID">
     <Identity>AN71000002012</Identity>
     </Credential>
     <Credential domain="EndPointID">
     <Identity>ERP</Identity>
     <SharedSecret>welcome3a</SharedSecret>
     </Credential>
     <UserAgent>Ariba.com Network V1.0</UserAgent>
     </Sender>
     </Header>
     <Request>
     <PurchaseRequisitionRequest>
     <PurchaseRequisition>
     <PurchaseRequisitionHeader requisitionID="pr123456" requisitionDate="2016-05-26T00:00:00-08:00" type="new">
     <ShipTo>
     <Address addressID="3000">
     <Name xml:lang="en">New York</Name>
     <PostalAddress>
     <DeliverTo>Joe Smith</DeliverTo>
     <Street>691 Random Ave</Street>
     <City>New York</City>
     <State isoStateCode="US-NY">NY</State>
     <PostalCode>10001</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     </PostalAddress>
     </Address>
     </ShipTo>
     <BillTo>
     <Address addressID="US006">
     <Name xml:lang="en">New York</Name>
     <PostalAddress>
     <Street>691 Random Ave</Street>
     <City>New York</City>
     <State isoStateCode="US-NY">NY</State>
     <PostalCode>10001</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     </PostalAddress>
     </Address>
     </BillTo>
     <Contact role="preparer">
     <Name xml:lang="en-US">Jane Doe</Name>
     <PostalAddress>
     <Street>123 Anystreet</Street>
     <City>Sunnyvale</City>
     <State isoStateCode="US-CA">CA</State>
     <PostalCode>94089</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     </PostalAddress>
     <Email>jdoe@company.com</Email>
     </Contact>
     <Contact role="requester">
     <Name xml:lang="en-US">Jane Doe</Name>
     <PostalAddress>
     <Street>123 Anystreet</Street>
     <City>Sunnyvale</City>
     <State isoStateCode="US-CA">CA</State>
     <PostalCode>94089</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     </PostalAddress>
     <Email>jdoe@company.com</Email>
     </Contact>
     </PurchaseRequisitionHeader>
     <ItemIn quantity="10.000" lineNumber="00001">
     <ItemID>
     <SupplierPartID>MON923 6</SupplierPartID>
     </ItemID>
     <ItemDetail>
     <UnitPrice>
     <Money currency="USD">100.00</Money>
     </UnitPrice>
     <Description xml:lang="en">Optimax-V Monitor Cable DB9M/DB23F </Description>
     <UnitOfMeasure>EA</UnitOfMeasure>
     <Classification domain="UNSPSC">43211800</Classification>
     <Extrinsic name="AccountCategory">K</Extrinsic>
     <Extrinsic name="PurchaseOrg">3000</Extrinsic>
     <Extrinsic name="PurchaseGroup">100</Extrinsic>
     <Extrinsic name="BuyerPartNumber">SSP16446-cXML</Extrinsic>
     <Extrinsic name="Facility">Bangalore</Extrinsic>
     <Extrinsic name="Need-by Date">2016-06-10T00:00:00-08:00</Extrinsic>
     </ItemDetail>
     <SupplierList>
     <Supplier>
     <Name xml:lang="en">JCN Technologies</Name>
     <SupplierID domain="NetworkID">AN70000000004</SupplierID>
     </Supplier>
     </SupplierList>
     <Distribution>
     <Accounting name="Default">
     <AccountingSegment id="100">
     <Name xml:lang="en">Percentage</Name>
     <Description xml:lang="en">Percentage</Description>
     </AccountingSegment>
     <AccountingSegment id="02">
     <Name xml:lang="en">Company</Name>
     <Description xml:lang="en">ID</Description>
     </AccountingSegment>
     <AccountingSegment id="5000">
     <Name xml:lang="en">CostCenter</Name>
     <Description xml:lang="en">ID</Description>
     </AccountingSegment>
     <AccountingSegment id="US002">
     <Name xml:lang="en">BusinessUnit</Name>
     <Description xml:lang="en">ID</Description>
     </AccountingSegment>
     <AccountingSegment id="8100">
     <Name xml:lang="en">Account</Name>
     <Description xml:lang="en">ID</Description>
     </AccountingSegment>
     <AccountingSegment id="5009">
     <Name xml:lang="en">SubAccount</Name>
     <Description xml:lang="en">ID</Description>
     </AccountingSegment>
     </Accounting>
     <Charge>
     <Money currency="USD">20000.00</Money>
     </Charge>
     </Distribution>
     </ItemIn>
     </PurchaseRequisition>
     </PurchaseRequisitionRequest>
     </Request>
    </cXML>
    

    6.2.1 PurchaseRequisition

    PurchaseRequisition には、購入申請の詳細が含まれます。以下の要素が含まれます。

    要素 説明
    PurchaseRequisitionHeader
    (必須)
    購入申請のヘッダー要素です。「PurchaseRequisitionHeader」を参照してください。
    ItemIn 購買アプリケーションでショッピングカートから申請に追加された品目を表します。「ItemIn」を参照してください。
    6.2.1.1 PurchaseRequisitionHeader

    PurchaseRequisitionHeader は、購入申請のヘッダー要素であり、すべての購入申請の共通情報が含まれます。この要素には、次の属性があります。

    属性 説明
    requisitionID この購入申請のバイヤーシステム購入申請 ID。
    requisitionDate 購入申請が作成された日時。
    type 購入申請の種類。使用可能な値は次のとおりです。
    ● new (通常設定)
    ● update
    ● delete
    update および delete 購入申請では、DocumentReference 要素を使用して、変更される PurchaseRequisition を参照する必要があります。
    requisitionVersion この購入申請のバイヤーシステム購入申請バージョン番号。元の購入申請バージョン番号は 1 にし、その後の更新では 1 ずつバージョン番号を増やします (たとえば、2、3、4 など)。

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

    要素 説明
    Shipping 購入申請の出荷費用が含まれます。
    Tax 税情報が含まれます。
    Total 購入申請の品目の合計金額が含まれます (税および出荷費用を除く)。
    ShipTo 購入申請の納入先住所が含まれます。
    BillTo 購入申請の請求先住所が含まれます。
    Contact 購入申請をフォローアップするための連絡先情報が含まれます。
    Comments このオブジェクトに関連付けられた、判読可能な任意の情報が含まれます。
    DocumentReference 購入申請の以前のバージョンへの参照を提供します。
    Extrinsic このオブジェクトに関連するすべての追加情報が含まれます。



    ← cXML リファレンスガイド 目次へ戻る

     この項では、cXML フォーマットの注文書を受信するための Web サイトの設定方法について説明します。この項では、さらに購入のオーダー状況メッセージをバイヤー企業またはマーケットプレイスに送信する方法についても説明します。

    ページ内の目次
    7.1 注文書の処理
    7.2 OrderRequest ドキュメント

    7.2.1 OrderRequestHeader
    7.2.1.1 Total
    7.2.1.2 ShipTo/BillTo
    7.2.1.3 BusinessPartner
    7.2.1.4 Shipping
    7.2.1.5
    7.2.1.6 Payment
    7.2.1.7 PaymentTerm
    7.2.1.8 Contact
    7.2.1.9 コメント
    7.2.1.9.1 添付ファイル
    7.2.1.10 Followup
    7.2.1.11 ControlKeys
    7.2.1.11.1 OCInstruction
    7.2.1.11.2 ASNInstruction
    7.2.1.11.3 InvoiceInstruction
    7.2.1.11.4 SESInstruction
    7.2.1.12 DocumentReference
    7.2.1.13 SupplierOrderInfo
    7.2.1.14 TermsOfDelivery
    7.2.1.15 DeliveryPeriod
    7.2.1.16 OrderRequestHeaderIndustry
    7.2.1.16.1 ReferenceDocumentInfo
    7.2.1.17 Extrinsic
    7.2.2 ItemOut
    7.2.2.1 ItemDetail
    7.2.2.1.1 ItemDetailIndustry
    7.2.2.1.1.1 ItemDetailRetail
    7.2.2.2 BlanketItemDetail
    7.2.2.3 SpendDetail
    7.2.2.3.1 FeeDetail
    7.2.2.3.2 LaborDetail
    7.2.2.3.3 Extrinsic
    7.2.2.4 Distribution
    7.2.2.5 TermsofDelivery
    7.2.2.6 TravelDetail
    7.2.2.7 共通の TravelDetail 要素
    7.2.2.7.1 AirDetail
    7.2.2.7.2 CarRentalDetail
    7.2.2.7.3 HotelDetail
    7.2.2.7.4 RailDetail
    7.2.2.8 許容範囲
    7.2.2.9 ControlKeys
    7.2.2.10 ScheduleLine
    7.2.2.11 ItemOutIndustry
    7.2.2.11.1 QualityInfo
    7.2.2.11.1.1 CertificateInfo
    7.2.2.11.2 SerialNumberInfo
    7.2.2.11.3 BatchInfo
    7.2.2.11.4 PackagingDistribution
    7.2.2.11.4.1 StoreCode
    7.2.2.12 Packaging
    7.2.2.13 ReleaseInfo
    7.2.2.14 Batch
    7.2.3 在庫転送オーダーの OrderRequest の例

    7.3 OrderRequest への Response
    7.4 注文書添付ファイルの受け入れ

    7.1 注文書の処理

    購買アプリケーションは、承認された購入申請を 1 つ以上の注文書に変換します。注文書は、バイヤー企業からサプライヤへの、契約を履行する正式な Request です。 cXML は、注文書の送信に使用されるフォーマットの 1 つです。その他の一般的なフォーマットは、電子メール、FAX、および ANSI X.12 EDI (電子データ交換) などです。cXML の注文書は、オーダー処理を容易に自動化できるという意味で、最良のフォーマットです。cXML は明確な構造をしているため、注文処理システムは注文書の要素 (element) を容易に解読することができます。注文書の該当データを、人間がほとんど、もしくはまったく介入することなく、必要に応じて発送部門、請求書部門、および販売部門に転送することができます。さらに、cXML オーダー通信手段を使用すると、任意のサプライヤクッキー (SupplierPartAuxiliaryID) や注文書の添付ファイルを送信できます。ネットワークハブのアカウントを設定する際に、すべての cXML 注文書の送信先となる URL を指定します。注文書を受信したら、それを内部オーダー管理システムに送信し、通常の手順でそれを実行します。さらに、Web サイトは注文書を正常に受信して構文解析したことをバイヤーに通知するために、オーダー応答ドキュメントをネットワークハブに返信する必要があります。cXML 注文書を受信するのにパンチアウト Web サイトは必要ありません。パンチアウトと cXML オーダー受信は独立した機能です。ただし、パンチアウトのサポートに必要なインフラストラクチャとアプリケーション機能は、cXML 注文書の受信にも同様に必要です。注文書のトランザクションには、2 通りの cXML ドキュメントが使用されます。購買アプリケーションは、OrderRequest ドキュメントを送信し、オーダー受信サイトは、それに対して一般的な Response ドキュメントを返信します。これらのドキュメントは、認証とルーティングのためにネットワークハブを介します。

    7.2 OrderRequest ドキュメント

    OrderRequest ドキュメントは一般的な注文書に相当します。次の例は OrderRequest 要素の構造を示しています。

    <OrderRequest>
     <OrderRequestHeader>
     <Total/>
     <ShipTo/>
     <BillTo/>
     <LegalEntity/>
     <OrganizationUnit/>
     <Shipping/>
     <Tax/>
     <Payment/>
     <PaymentTerm/>
     <Contact/>
     <Comments/>
     <Followup/>
     <ControlKeys/>
     <DocumentReference/>
     <SupplierOrderInfo/>
     <TermsOfDelivery/>
     <DeliveryPeriod/>
     <IdReference/>
     <OrderRequestHeaderIndustry/>
     <Extrinsic/>
     </OrderRequestHeader>
     <ItemOut>
     <ItemID/>
     <Path/>
     <ItemDetail/> | <BlanketItemDetail/>
     <SupplierID/> | <SupplierList/>
     <ShipTo/>
     <Shipping/>
     <Tax/>
     <SpendDetail/>
     <Distribution/>
     <Contact/>
     <TermsOfDelivery/>
     <Comments/>
     <Tolerances/>
     <ControlKeys/>
     <ScheduleLine/>
     <MasterAgreementReference/> | <MasterAgreementIDInfo/>
     <ItemOutIndustry/>
     <Packaging/>
     <ReleaseInfo/>
     <Batch/>
     </ItemOut>
    </OrderRequest>
    

    注記
    OrderStatusRequest については、「 OrderStatusRequest 」を参照してください。

    品目に関する OrderRequest の例を次に示します。

    <?xml version="1.0" encoding="UTF-8">
    <!DOCTYPE cXML SYSTEM "http://xml.cxml.org/schemas/cXML/1.2.014/cXML.dtd">
    <cXML xml:lang="en-US" payloadID="93369535150910.10.57.136" timestamp="2000-08-03T08:49:11+07:00">
     <Header>
     <From>
     <Credential domain="AribaNetworkUserId">
     <Identity>admin@acme.com</Identity>
     </Credential>
     </From>
     <To>
     <Credential domain="DUNS">
     <Identity>114315195</Identity>
     </Credential>
     </To>
     <Sender>
     <Credential domain="AribaNetworkUserId">
     <Identity>sysadmin@ariba.com</Identity>
     <SharedSecret>abracadabra</SharedSecret>
     </Credential>
     <UserAgent>Network Hub V1.1</UserAgent>
     </Sender>
     </Header>
     <Request>
     <OrderRequest>
     <OrderRequestHeader orderID="DO102880" orderDate="2012-08-03T08:49:09+07:00" type="new">
     <Total>
     <Money currency="USD">86.50</Money>
     </Total>
     <ShipTo>
     <Address isoCountryCode="US" addressID="1000467">
     <Name xml:lang="en">Acme, Inc.</Name>
     <PostalAddress name="default">
     <DeliverTo>John Q. Smith</DeliverTo>
     <DeliverTo>Buyers Headquarters</DeliverTo>
     <Street>123 Main Street</Street>
     <City>Mountain View</City>
     <State isoStateCode="US-CA">CA</State>
     <PostalCode>94089</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     </PostalAddress>
     <Email name="default">john_smith@acme.com</Email>
     <Phone name="work">
     <TelephoneNumber>
     <CountryCode isoCountryCode="US">1</CountryCode>
     <AreaOrCityCode>800</AreaOrCityCode>
     <Number>5555555</Number>
     </TelephoneNumber>
     </Phone>
     </Address>
     </ShipTo>
     <BillTo>
     <Address isoCountryCode="US" addressID="12">
     <Name xml:lang="en">Acme Accounts Payable</Name>
     <PostalAddress name="default">
     <Street>124 Union Street</Street>
     <City>San Francisco</City>
     <State isoStateCode="US-CA">CA</State>
     <PostalCode>94128</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     </PostalAddress>
     <Phone name="work">
     <TelephoneNumber>
     <CountryCode isoCountryCode="US">1</CountryCode>
     <AreaOrCityCode>415</AreaOrCityCode>
     <Number>6666666</Number>
     </TelephoneNumber>
     </Phone>
     </Address>
     </BillTo>
     <LegalEntity>
     <IdReference domain="CompanyCode" identifier="CH01">
     <Description>SAP AG</Description>
     </IdReference>
     </LegalEntity>
     <OrganizationalUnit>
     <IdReference domain=" PurchasingOrganization" identifier="SCP">
     <Description> SCPM Purchasing Org </Description>
     </IdReference>
     </OrganizationalUnit>
     <OrganizationalUnit>
     <IdReference domain=" PurchasingGroup" identifier="0001">
     <Description> PGP Buyer </Description>
     </IdReference>
     </OrganizationalUnit>
     <Shipping>
     <Money currency="USD">10.00</Money>
     <Description xml:lang="en-US">FedEx 2-day</Description>
     </Shipping>
     <Tax>
     <Money currency="USD">1.5</Money>
     <Description xml:lang="en">CA State Tax</Description>
     </Tax>
     <Payment>
     <PCard number="1234567890123456" expiration="2015-03-12"/>
     </Payment>
     </OrderRequestHeader>
     <ItemOut quantity="2" lineNumber="1">
     <ItemID>
     <SupplierPartID>220-3165</SupplierPartID>
     <SupplierPartAuxiliaryID>E000028901</SupplierPartAuxiliaryID>
     </ItemID>
     <ItemDetail>
     <UnitPrice>
     <Money currency="USD">55.00</Money>
     </Modifications>
     <Modification>
     <OriginalPrice>
     <Money currency = "USD">50.00</Money>
     </OriginalPrice>
     <AdditionalCost>
     <Money currency = "USD">5</Money>
     </AdditionalCost>
     <ModificationDetail endDate = "2013-11-30T10:15:00-08:00" name = "Royalties" startDate = "2012-08-03T10:15:00-08:00">
     <Description xml:lang = "en-US">Charge for Royalties
     </Description>
     </ModificationDetail>
     </Modification>
     </Modifications>
     </UnitPrice>
     <Description xml:lang="en">Laptop Computer Notebook Pentium® II processor w/AGP, 300 MHz, with 12.1&quot; TFT XGA Display</Description>
     <UnitOfMeasure>EA</UnitOfMeasure>
     <Classification domain="UNSPSC">43171801</Classification>
     <URL>http://www.supplier.com/Punchout.asp</URL>
     <Extrinsic name="ExtDescription">Enhanced keyboard</Extrinsic>
     </ItemDetail>
     <Distribution>
     <Accounting name="DistributionCharge">
     <AccountingSegment id="7720">
     <Name xml:lang="en-US">Account</Name>
     <Description xml:lang="en-US">Office Supplies
     </Description>
     </AccountingSegment>
     <AccountingSegment id="610">
     <Name xml:lang="en-US">Cost Center</Name>
     <Description xml:lang="en-US">Engineering Management
     </Description>
     </AccountingSegment>
     </Accounting>
     <Charge>
     <Money currency="USD">20.00</Money>
     </Charge>
     </Distribution>
     </ItemOut>
     </OrderRequest>
     </Request>
    </cXML>
    

    7.2.1 OrderRequestHeader

    オーダー全体に適用されるヘッダー情報を定義します。これは、サプライヤがそれぞれのオーダー管理システムでオーダーできるようにするためにサプライヤに送信されるデータです。OrderRequestHeader には次の属性があります。

    属性 説明
    orderID
    (必須)
    このオーダーの識別子。オーダー番号に相当します。
    orderDate
    (必須)
    このオーダーが配置された日付と時刻 (ISO 8601 フォーマット) です。 orderType オーダーの種類。使用可能な値は次のとおりです。

    • regular (初期値) – 通常の注文書。
    • release – 既存の基本契約書、契約、または包括注文書に対するリリース。
    • blanket – 包括注文書。
    • stockTransport – 在庫転送オーダー。
    • stockTransportRelease – 在庫転送分納契約リリース (SAR)。
    releaseRequired 包括注文書でリリース (注文書) が必要であるかどうかを示すために、orderType が blanket である場合にのみ使用されます。”yes” が指定されている場合は、サプライヤが処理する前に、包括注文書で個別のリリースオーダーが必要です。指定されていない場合は、サプライヤが包括注文書自体を処理できます。通常の設定では指定されていません。
    type 申請の種類: new (通常の設定) 、update、または delete。update オーダーと delete オーダーでは、元の注文書を参照する payloadID を DocumentReference 要素に含めて使用する必要があります。「DocumentReference」を参照してください。
    orderVersion 元のオーダーを 1 として、変更オーダーのオーダーバージョン番号を指定します。
    isInternalVersion バイヤー企業内にのみ関係する変更がオーダーに含まれるかどうかを示します。たとえば、サプライヤが使用する情報に影響しない簡単な変更が行われたとします。顧客の設定により、この属性はサプライヤには見えないようになります。
    agreementID 関連する主契約または包括注文書のバイヤー識別子を示すために、orderType が release である場合にのみ使用されます。
    agreementPayloadID 関連する主契約または包括注文書の cXML ドキュメントペイロード ID を示すために、orderType が release である場合にのみ使用されます。
    parentAgreementID 親包括注文書を示すために、orderType が blanket である場合にのみ使用されます。
    parentAgreementPayloadID 親包括注文書のドキュメント参照識別子を示すために、orderType が blanket である場合にのみ使用されます。
    effectiveDate 包括注文書が有効になる日付 (包括注文書用にリリースを作成できる日付または請求書を提出できる日付) を示すために、orderType が blanket である場合に必須です。
    expirationDate 包括注文書が期限切れになる日付を示すために、orderType が blanket である場合にのみ使用されます。この日付後に包括注文書に対してリリースを作成することはできません。
    requisitionID このオーダー全体を対象としたバイヤーの購入申請識別子。orderID と同じ場合があります。また、この ID がまったく含まれない場合もあります。ItemOut 要素で requisitionID が指定されている場合は、この ID を含めないでください。
    shipComplete 分割出荷に対する基本設定。指定可能な値は「yes」のみです。通常は、品目は入手可能となったときに出荷されます。オーダーには ShipTo 要素の異なる品目が含まれる可能性があるため、shipComplete=“yes” となる完了時まで、出荷先が共通の品目グループのみを保持する必要があります。
    pickUpDate オーダーの出荷および配達の準備ができる日付です。
    requestedDeliveryDate サプライやおよび運送業者に関する重要な日付情報です。多くの場合、バイヤーが商品の受領を希望する日付 (または期間) が反映されます。
    isSTOOutbound この OrderRequest を使用してサプライヤに在庫を送ることを示すには、 yes に設定します。商品がバイヤーのプラントからサプライヤのプラントに送られます。これは、現在、在庫転送オーダーシナリオのみに関連します。

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

    要素 説明
    Total
    (必須)
    オーダーの品目の合計金額が含まれます (税および出荷費用を除く)。「合計」を参照してください。
    ShipTo オーダーの納入先住所 (任意) です。納入先住所は、品目レベルでも表示されます。「ShipTo/BillTo」を参照してください。
    BillTo
    (必須)
    オーダーの請求先住所です。「ShipTo/BillTo」を参照してください。
    BusinessPartner 品目のビジネスパートナーに関する情報が含まれます。「BusinessPartner」を参照してください。
    LegalEntity 外部システム内の法人を識別します。
    OrganizationalUnit 外部システム内の発注ユニットまたは発注グループを識別します。
    Shipping オーダーの出荷費用が含まれます。「Shipping」を参照してください。
    Tax オーダーと関連付けられている税金が含まれます。「」を参照してください。
    Payment オーダーの支払いに使用される支払手段を示します。「Payment」を参照してください。
    PaymentTerm オーダーの支払条件を定義します。「PaymentTerm」を参照してください。
    Contact オーダーを追跡するための連絡先情報が含まれます。「Contact」を参照してください。
    Comments このオーダーに関連するコメントが含まれます。「コメント」を参照してください。
    Followup 追加の StatusUpdateRequest ドキュメントを掲載する URL を指定します。「Followup」を参照してください。
    ControlKeys オーダー確認、出荷通知、サービスシート、および請求書に対する通常のビジネスルールを上書きできる要素が提供されます。「ControlKeys」を参照してください。
    DocumentReference 種類が “update” または”delete” の場合のみ必要となります。オーダーの最新の OrderRequest ドキュメントを参照します。「DocumentReference」を参照してください。
    SupplierOrderInfo 注文書に関連したサプライヤ受注情報を定義します。「SupplierOrderInfo」を参照してください。
    TermsOfDelivery オーダーおよび出荷通知で記述された、出荷の配達条件を指定します。「TermsOfDelivery」を参照してください。
    DeliveryPeriod 出荷の開始日と終了日を指定します。「DeliveryPeriod」を参照してください。
    IdReference ID 参照を定義します。「IdReference」を参照してください。
    OrderRequestHeaderIndustry オーダーに関する業種固有の情報が含まれます。「OrderRequestHeaderIndustry 」を参照してください。
    Extrinsic オーダーに関連する追加情報が含まれます。「Extrinsic」を参照してください。

    OrderRequestHeader および ItemOut (ItemDetail で拡張されている場合) にも、同様の情報が含まれます。OrderRequestHeader に全体的な請求 (BillTo) と支払い (Payment, PaymentTerm) の情報が含まれる場合は、ItemOut に (ItemID、ItemDetail, SpendDetail、および Distribution 内の) 個別の品目が記述されます。OrderRequestHeader 内の情報を品目固有の要素の通常設定として使用しないでください。存在する場合は、ShipTo、Shipping、Contact、および各名前付きの Extrinsic がすべての ItemOut とともに、または OrderRequestHeader 内に表示される必要があります。Comments 要素および Tax 要素は、両方 (ヘッダーと品目)のレベルで同時に表示することができます。ただし、ヘッダーレベルの Tax 要素にはオーダーの合計金額の税金が含まれ、品目レベルの Tax 要素にはその品目だけの金額の税金が含まれます。Comments 要素では、両方のレベルで情報が重複しないようにしてください。

    次の例は、OrderRequestHeader を詳細に示しています。

    <OrderRequestHeader orderID="DO1234" orderDate="2013-06-03T13:30:23+8.00" type="new" requisitionID="R1234" shipComplete="yes">
     <Total>
     <Money currency="USD">65.00</Money>
     </Total>
     <Modifications>
     <Modification>
     <OriginalPrice>
     <Money currency = "USD">40.00</Money>
     </OriginalPrice>
     <AdditionalCost>
     <Money currency = "USD">10</Money>
     </AdditionalCost>
     <ModificationDetail endDate = "2013-11-30T10:15:00-08:00" name = "Access Charges" startDate = "2013-06-03T10:15:00-08:00">
     <Description xml:lang = "en-US">Access Charges
     </Description>
     </ModificationDetail>
     </Modification>
     </Modifications>
     <ShipTo>
     <Address>
     <Name xml:lang="en">Acme Corporation</Name>
     <PostalAddress name="Headquarters">
     <DeliverTo>Joe Smith</DeliverTo>
     <DeliverTo>Mailstop M-543</DeliverTo>
     <Street>123 Anystreet</Street>
     <City>Sunnyvale</City>
     <State isoStateCode="US-CA">CA</State>
     <PostalCode>90489</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     </PostalAddress>
     </Address>
     <CarrierIdentifier domain="companyName">UPS</CarrierIdentifier>
     <TransportInformation>
     <Route method="motor"/>
     <ShippingContractNumber>34567</ShippingContractNumber>
     <ShippingInstructions>
     <Description xml:lang="en-US">As per the contract</Description>
     </ShippingInstructions>
     </TransportInformation>
     </ShipTo>
     <BillTo>
     <Address>
     <Name xml:lang="en">Acme Corporation</Name>
     <PostalAddress name="Finance Building">
     <Street>124 Anystreet</Street>
     <City>Sunnyvale</City>
     <State isoStateCode="US-CA">CA</State>
     <PostalCode>90489</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     </PostalAddress>
     </Address>
     </BillTo>
     <Shipping>
     <Money currency="USD">12.5</Money>
     <Description xml:lang="en-US">FedEx 2-day</Description>
     </Shipping>
     <Tax>
     <Money currency="USD">2.5</Money>
     <Description xml:lang="en">CA State Tax</Description>
     </Tax>
     <Payment>
     <PCard number="1234567890123456" expiration="2015-03-12"/>
     </Payment>
     <PaymentTerm payInNumberOfDays="45">
     </PaymentTerm>
     <PaymentTerm payInNumberOfDays="30">
     <Discount>
     <DiscountPercent percent="2">
     </Discount>
     </PaymentTerm>
     <PaymentTerm payInNumberOfDays="20">
     <Discount>
     <DiscountPercent percent="3">
     </Discount>
     </PaymentTerm>
     <Contact role="purchasingAgent">
     <Name xml:lang="en-US">Mr. Purchasing Agent</Name>
     <Email>puragent@acme.com</Email>
     <Phone name="Office">
     <TelephoneNumber>
     <CountryCode isoCountryCode="US">1</CountryCode>
     <AreaOrCityCode>800</AreaOrCityCode>
     <Number>5551212</Number>
     </TelephoneNumber>
     </Phone>
     </Contact>
     <Comments xml:lang="en-US">Anything well formed in XML can go here.</Comments>
     <TermsOfDelivery>
     <TermsOfDeliveryCode value="PriceCondition"/>
     <ShippingPaymentMethod value="AdvanceCollect"/>
     <TransportTerms value="Other">Contract Transport terms</TransportTerms>
     <Address>
     <Name xml:lang="en-US">SN Services/Name>
     <PostalAddress name="default">
     <Street>123 Anystreet</Street>
     <City>Birmingham</City>
     <State isoStateCode="US-AL">AL</State>
     <PostalCode>35505</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     </PostalAddress>
     </Address>
     <Comments xml:lang="en-US" type="Transport">Transport Terms
     </Comments>
     <Comments xml:lang="en-US" type="TermsOfDelivery">Terms per the contract</Comments>
     </TermsOfDelivery>
     <DeliveryPeriod>
     <Period startDate="2013-06-10T14:37:31-07:00" endDate = "2013-06-11T14:37:31-07:00"></Period>
     </DeliveryPeriod>
     <IDReference></IDReference>
     <SupplierOrderInfo orderID=12345>
    </OrderRequestHeader>
    

    品目に関する OrderRequestHeader の例を次に示します。

    <OrderRequestHeader parentAgreementPayloadID="1184102133611.2058850054.000000002@1zVE0KpzNZLO9HTrpqF27NebqbI=" parentAgreementID="BPO31" expirationDate="2007-07-31T23:59:59-07:00" orderDate="2007-07-10T14:37:31-07:00" orderID="BPO36" orderVersion="1" effectiveDate="2007-07-10T00:00:00-07:00" releaseRequired="yes" orderType="blanket" type="new">
     ...
    </OrderRequestHeader>
    
    7.2.1.1 Total

    この要素には、オーダー品目の税金と出荷費用を除く合計金額が含まれます。これは、Money および Modifications要素を入れるためのものです。

    要素 説明
    Money (必須) 品目の支払いに使用される商品分類を表します。
    Modifications 品目の元の価格または出荷価格の変更が格納されます。「ModificDtions [115 ページ]」を参照してください。

    オーダーの種類が「包括」の場合は、明細レベルの小計を集計する際に Total 要素が使用されません。その後、Total はサプライヤとの最高限度額を示すために使用されます。この合計は、各明細レベルの小計または MaxAmounts に加算されません。明細レベルの MaxAmounts の合計は、ヘッダーレベルの合計を超過しないようにしてください。明細レベルの MaxAmount が指定されていない場合は、明細レベルの最高金額は注文書の合計最高金額と同じであるとみなされます。

    <OrderRequestHeader orderDate="2012-08-03T10:15:00-08:00" orderID="2482012_5" orderType="regular" type="new">
     <Total>
     <Money currency = "USD">52</Money>
     <Modifications>
     <Modification>
     <OriginalPrice>
     <Money currency = "USD">100.00</Money>
     </OriginalPrice>
     <AdditionalDeduction>
     <DeductionAmount>
     <Money currency = "USD">50.00</Money>
     </DeductionAmount>
     </AdditionalDeduction>
     <ModificationDetail
     endDate = "2013-11-30T10:15:00-08:00"
     name = "Allowance"
     startDate = "2012-08-03T10:15:00-08:00">
     <Description xml:lang = "en-US">Promotional Allowance
     </Description>
     </ModificationDetail>
     </Modification>
     <Modification>
     <OriginalPrice>
     <Money currency = "USD">100.00</Money>
     </OriginalPrice>
     <AdditionalCost>
     <Percentage percent = "2"/>
     </AdditionalCost>
     <ModificationDetail
     endDate = "2013-11-30T10:15:00-08:00"
     name = "Export Packing Charges"
     startDate = "2012-08-03T10:15:00-08:00">
     <Description xml:lang = "en-US">Charges for export packing</
     Description>
     </ModificationDetail>
     </Modification>
     </Modifications>
     </Total>
    <ShipTo>
    
    7.2.1.1.1 Modifications

    品目の元の価格または出荷価格の変更が格納されます。この要素には、1 つまたは複数の Modification 要素を格納できます。Modifications 要素を Shipping 要素に追加できます。

    7.2.1.1.1.1 Modification

    ヘッダーレベルまたは明細レベルで適用可能な値引きおよび手数料の詳細が含まれます。Modification には以下の属性があります。

    属性 説明
    level カスケード変更で使用される変更のレベルを表します。以下に例を示します。

    • 手数料 1 (レベル 1): 元の価格 $10 の手数料: $1
    • 手数料 2 (レベル 1): 元の価格 $10 の手数料: $1
    • 手数料 3 (レベル 2): 元の価格 $8 の手数料: $1
    • 手数料 4 (レベル 3): 元の価格 $7 の手数料: $1

    Modification には以下の要素があります。

    要素 説明
    OriginalPrice 品目の元の価格が含まれます。値引きおよび手数料は、元の価格に適用されます。OriginalPrice には、Money 要素があります。また、任意設定の type 属性もあります。type 値の例は、MSRP、ListPrice、Actual、AverageSellingPrice、CalculationGross、BaseCharge、AverageWholesalePrice、ExportPrice、AlternatePrice、および ContractPriceです。
    AdditionalDeduction | AdditionalCost AdditionalDeduction には、品目に適用可能な控除の詳細が含まれます。値引きが適用可能である場合にのみ使用されます。この要素には、控除の値を定義する以下の要素のいずれかを含めることができます。
    ● DeductionAmount – この要素には Money 要素があります。
    ● DeductionPercent – この要素には percent 属性があります。
    ● DeductedPrice – この要素には Money 要素があります。これには品目の最終価格が含まれます。この価格によって品目の価格が上書きされます。
    AdditionalDeduction には、任意設定の type 属性があります。これには、品目に適用可能な控除の種類についての詳細が含まれます。
    AdditionalCost には、品目に適用される追加手数料の詳細が含まれます。
    AddtionalDeduction 要素が指定されていない場合に、この要素を指定できます。以下の要素があります。
    ● Money – value 属性に金額を入力します。. これは必須属性です。
     注記 出荷費用、その他手数料、または送料に、この要素を使用しないでください。
    ● Percentage — percent 属性にパーセント値を入力します。これは必須属性です。
    ModificationDetail AdditionalDeduction 要素または AdditionalCost 要素の詳細が含まれます。「ModificDtionDetDil [117 ページ]」を参照してください。
    Tax 値引きおよび手数料の税情報が含まれます。
    注記 OriginalPrice 要素は Modification 要素の一部として追加される場合、任意設定の要素です。「税 [381 ページ]」を参照してください。

    以下の例は、複数の変更がある品目で level 属性を使用する方法を示しています。

    <InvoiceHeaderModifications>
     <Modification level=”1”>
     <OriginalPrice>5.500</OriginalPrice>
     <AdditionalDeduction>
     <DeductionPercent>2</DeductionPercent>
     </AdditionalDeduction>
     </Modification>
     <Modification level="1">
     <OriginalPrice>5.500</OriginalPrice>
     <AdditionalCost>
     <Money currency="USD">2.00</Money>
     </AdditionalCost>
     </Modification>
     <Modification level="2">
     <OriginalPrice 7.390</OriginalPrice >
     <AdditionalDeduction>
     <DeductionPercent>10</DeductionPercent>
     </AdditionalDeduction>
     </Modification>
    </InvoiceHeaderModifications>
    
    7.2.1.1.1.1.1 ModificationDetail

    AdditionalDeduction 要素または AdditionalCost 要素の詳細が含まれます。

    ModificationDetail には以下の属性があります。

    属性 説明
    name
    (必須)
    変更の名前 (「値引き」など)。
    startDate 変更の開始日。
    endDate 変更の終了日。
    code 変更のサービスコード。

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

    要素 説明
    Description 変更の説明。
    Extrinsic このオブジェクトに関連するすべての追加情報が含まれます。
    <Modification>
     <OriginalPrice>
     <Money currency="USD">100.00</Money>
     </OriginalPrice>
     <AdditionalCost>
     <Percentage percent="2"/>
     </AdditionalCost>
     <ModificationDetail endDate="2021-11-30T10:15:00-08:00" name="Export Packing Charges" startDate="2021-08-03T10:15:00-08:00">
     <Description xml:lang="en-US">Charges for export packing</Description>
     </ModificationDetail>
    </Modification>
    
    7.2.1.2 ShipTo/BillTo

    これらの要素には、OrderRequest の ShipTo と BillTo エンティティのアドレスが含まれます。すべてのオーダーの請求先は、単一のエンティティでなければなりません。したがって、BillTo 要素は OrderRequestHeader にのみ表示されます。1 つのオーダーに含まれる品目は、複数の場所に発送される場合があります。したがって、Shipping 要素と同様に (次の項を参照)、ShipTo 要素は OrderRequestHeader、または個々の ItemOut 要素のいずれかに使用します。 IdReference については、「IdReference」を参照してください。Address 要素には次の属性が含まれます。

    属性 説明
    isoCountryCode この所在地を含む国を表す ISO 3166 の 2 文字の国コードです。
    addressID 住所の ID を指定します。この属性を使用して、ID 照会を必要とする場合の住所コードをサポートします。この値は、会社名や個人名にしないでください。この属性は、アプリケーション間の統合を強化するために使用します。たとえば、ShipTo で指定する所在地の識別子は次のとおりです。

    <Address isoCountryCode="US" addressID="1000487">
    
    addressIDDomain addressID を付与する責任がある機関または組織を表すコードを指定します。たとえば、DUNSや ILN です。このコードは、addressID 属性に値がある場合に必須です。

    Address 要素に含まれる Name 要素には、必ず会社名が指定されます。以下の例では、DeliverTo 要素は 2 行指定されています。最初の行では商品を受け取る個人名を指定し、2 番目の行ではその品目の配達先の所在地名 (建物、市区町村、事務所、メールストップ) を指定します。所在地名は宛名ラベルに使用できるよう、必ず完全なものにしてください。次に例を示します。

    <PostalAddress name="Headquarters">
     <DeliverTo>Joe Smith</DeliverTo>
     <DeliverTo>Mailstop M-543</DeliverTo>
     <Street>123 Anystreet</Street>
     <City>Sunnyvale</City>
     <State isoStateCode="US-CA">CA</State>
     <PostalCode>90489</PostalCode>
     <Country isoCountryCode="US">United States</Country>
    </PostalAddress>
    

    Country には人間が判読可能な名前が含まれます。CarrierIdentifier 要素には、出荷の運送業名が含まれます。

    例:

    <ShipTo>
     <Address>
     <Name xml:lang="USD">Acme</Name>
     <PostalAddress name="Headquarters">
     <DeliverTo>Joe Smith</DeliverTo>
     <DeliverTo>Mailstop M-543</DeliverTo>
     <Street>123 Anystreet</Street>
     <City>Sunnyvale</City>
     <State isoStateCode="US-CA">CA</State>
     <PostalCode>90489</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     </PostalAddress>
     <CarrierIdentifier domain="companyName">UPS</CarrierIdentifier>
    </ShipTo>
    

    TransportInformation 要素には、注文書または出荷通知の輸送情報が含まれます。この要素は、ヘッダーレベルのみで指定されます。TransportInformation 要素には次の属性が含まれます。

    要素 説明
    Route 出荷方法。運送業者を選択する場合に必要です。「Route」を参照してください。
    ShippingContractNumber 出荷の輸送に指定される出荷契約番号です。
    ShippingInstructions 出荷情報

    TransportInformation 要素の例を次に示します。

    <OrderRequestHeader orderDate="2010-03-26T16:40:53" orderID="POw4401" orderType="regular" type="Update">
     <Total>
     <Money currency="USD">1.00</Money>
     </Total>
     <ShipTo>
     <Address>
     <Name xml:lang="USD">Acme</Name>
     <PostalAddress name="default">
     <DeliverTo>Joe Smith</DeliverTo>
     <DeliverTo>Mailstop M-543</DeliverTo>
     <Street>123 Anystreet</Street>
     <City>Birmingham</City>
     <State isoStateCode="US-AL">AL</State>
     <PostalCode>35005</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     </PostalAddress>
     </Address>
     <CarrierIdentifier domain="companyName">UPS</CarrierIdentifier>
     <TransportInformation>
     <Route method="motor"/>
     <ShippingContractNumber>1245</ShippingContractNumber>
     <ShippingInstructions>
     <Description xml:lang="en-US">Contract Instructions</Description>
     </ShippingInstructions>
    </TransportInformation>
    

    値が不足していると EDI および cXML サプライヤが影響を受ける可能性があるため、空や空白文字の要素は避けてください。

    7.2.1.3 BusinessPartner

    品目のビジネスパートナーに関する情報が含まれます。BusinessPartner には次の属性があります。

    属性 説明
    type
    (必須)
    ビジネスパートナーの種類を識別します。指定可能な値は organizationのみです。
    role
    (必須)
    購買プロセスでパートナーが果たす役割を示します。指定可能な値はsoldTo、shipFrom、または orderingAddress です。

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

    要素 説明
    Address
    (必須)
    ビジネスパートナーの説明を提供します。role ごとに、以下の指示に従います。

    • soldTo: 要素 IdReference の domain 属性は、”buyerAccountID” (販売先 ID に対する ID) に設定する必要があります。addressIDDomain は、”buyerAccountID” に設定する必要があります。addressID は、販売先 ID に設定する必要があります。説明の名前を使用します。
    • shipFrom: addressIDDomain は、”shipFromAddressID” に設定する必要があります。addressID は、出荷元 ID に設定する必要があります。説明の名前を使用します。
    • orderingAddress: addressIDDomain は、”supplierCorporate” に設定する必要があります。addressID は、発注元住所 ID に設定する必要があります。説明の名前を使用します。
    IdReference ID ID 参照は、アプリケーションのコンテキスト (バイヤーとサプライヤの特定のペアなど) 内にあります。(ID、ドメイン) ペアは一意である必要があります。

    次の例は、いくつかの BusinessPartner 要素を示しています。

    <BusinessPartner type="organization" role="soldTo">
     <Address isoCountryCode="EN" addressID="0002" addressIDDomain="buyerAccountID">
     <Name xml:lang="de">SAP A.G.</Name>
     <PostalAddress name="SAP Labs LLC">
     <Street>Hillview Ave 3450</Street>
     <City>Palo Alto</City>
     <PostalCode>94304</PostalCode>
     <Country isoCountryCode="US"/>
     </PostalAddress>
     </Address>
     <IdReference identifier="0002" domain="buyerAccountID"/>
     <IdReference identifier="CUST_0123" domain="supplierID"/>
    </BusinessPartner>
    <BusinessPartner type="organization" role="shipFrom">
     <Address isoCountryCode="EN" addressID="0002" addressIDDomain="shipFromAddressID">
     <Name xml:lang="de">SAP A.G.</Name>
     <PostalAddress name="SAP Labs LLC">
     <Street>Hillview Ave 3450</Street>
     <City>Palo Alto</City>
     <PostalCode>94304</PostalCode>
     <Country isoCountryCode="US"/>
     </PostalAddress>
     </Address>
    </BusinessPartner>
    <BusinessPartner type="organization" role="orderingAddress">
     <Address isoCountryCode="EN" addressID="ADDR0002" addressIDDomain="supplierCorporate">
     <Name xml:lang="de">SAP A.G.</Name>
     <PostalAddress name="SAP Labs LLC">
     <Street>Hillview Ave 3450</Street>
     <City>Palo Alto</City>
     <PostalCode>94304</PostalCode>
     <Country isoCountryCode="US"/>
     </PostalAddress>
     </Address>
    </BusinessPartner>
    
    7.2.1.4 Shipping

    この要素では、明細の出荷方法と出荷費用が記述されます。Shipping 要素が OrderRequestHeader に存在する場合、ItemOut 要素に存在してはいけません。OrderRequestHeader に存在しない場合は、ItemOut 要素に存在する必要があります。

    7.2.1.5 税

    この要素には、オーダーと関連付けられた税金が含まれます。この要素は、バイヤー企業が税金を計算する場合に存在します。OrderRequestHeader に表示された Tax は、オーダーに対する合計税額を示します。品目レベルの Tax 要素には、明細の税額を記述できます。Tax 要素では、税関連の追加情報用の Extrinsic 要素がサポートされています。

    7.2.1.6 Payment

    発注品目の支払いに使用される支払手段を示します。Payment 要素には、標準の P カードを cXML ドキュメントにエンコードした PCard 要素が含まれます。将来、ほかの支払手段も定義される予定です。

    7.2.1.7 PaymentTerm

    オーダーと請求書の支払条件が定義されます。これまでの cXML のバージョンで定義されていたInvoiceDetailPaymentTerm ではなく、PaymentTerm を使用します。PaymentTerm では、支払期間 (割引なし)または割引適用期間 (割引あり) が定義されます。この要素は、DueDate や ValueDate などの情報が含まれるようにExtrinsic 要素で拡張されます。PaymentTerm には、以下の 1 つの属性があります。

    属性 説明
    payInNumberOfDays 請求書発効日から請求書支払期限まで、特定の日数が示されます。
    Discount 割引条件の割引率 (%) または割引金額。この割引率は、payInNumberOfDays で指定した期間内に請求書の合計が支払われた場合に適用されます。正の比率は割引を示し、負の比率は違約金を示します。パーセント記号 (%) を使用したり、100 で除算しないでください。たとえば、2 は 2% を意味します。PaymentTerm に支払期間 (割引なし) を指定する場合、Discount 要素は使用しないでください。
    Extrinsic 支払条件に関する追加情報です。
    7.2.1.8 Contact

    サプライヤは Contact 要素の情報を使用して、オーダーをフォローアップします。この要素で該当人物を特定し、その人物または組織に連絡する一連の方法を提供します。必須の要素は、連絡先の Name 要素だけです。任意設定であり、繰り返し使用できる要素には、PostalAddress (オーダーに関する問題を迅速に修正する場合は推奨されません)、Email、Phone、Fax、URL、IdReference, 、および Extrinsic などがあります。cXML 1.0 では、User および CostCenter という Extrinsic 要素に連絡先情報を含めていました。cXML 1.1 以降では、それらの Extrinsic に代わって、Contact 要素で情報が提供されます。

    バイヤー企業は、申請者、購買アプリケーションのシステム管理者、または、オーダーに関する問題を解決することができる責任者を確認するために、この要素を使用する場合があります。Contact は、オーダーの BillTo および ShipTo 情報のいずれとも異なっていてもかまいません。 Contact には次の属性があります。

    属性 説明
    role 購買プロセスにおけるその人物の地位です。
    addressID 住所の ID です。addressID では、ID 照会を必要とする場合の住所コードがサポートされます。
    addressIDDomain 住所 ID を付与する責任がある機関または組織を指定するコードです。たとえば、DUNS や ILN です。このコードは、addressID 属性に値がある場合に必須です。

    role 属性の値は、購買アプリケーションによって異なります。可能な値の一部を以下に示します。

    説明
    administrator 管理者の連絡先
    buyer バイヤーの連絡先
    buyerAccount バイヤーアカウントの連絡先
    buyerMasterAccount バイヤーマスタアカウントの連絡先
    cargoDelivery 輸送先住所
    companyDelivery 受入の連絡先
    customerService カスタマサービスの連絡先
    defaultDelivery 個人届け先の住所
    endUser エンドユーザーの連絡先
    postDelivery 郵送先住所
    privateEndUser 購入申請者の住所
    purchasingAgent 発注担当者の連絡先
    sales 営業の連絡先
    soldTo 顧客の連絡先
    subsequentBuyer 後続のバイヤーの連絡先
    SupplierAccount サプライヤアカウントの連絡先
    supplierCorporate サプライヤの連絡先
    supplierMasterAccount サプライヤマスタアカウントの連絡先
    technicalSupport テクニカルサポートの連絡先

    ヘッダーと品目の両方のレベルで同じ Contact role を使用しないでください。 Contact 要素には、まったく異なる内容の情報を含めることができるため、role 属性には、通常の値がありません。そのため cXML アプリケーションでは、role 属性が空の Contact を、新規 role として処理します。

    IdReference

    ID 参照を定義します。識別子/ドメインのペアは、それぞれの取引先との取引関係 (バイヤー企業およびサプライヤ) において一意であることが必要です。「IdReference」を参照してください。

    TelephoneNumber

    TelephoneNumber 要素には、商品の出荷先や請求先となる個人や部門の電話番号が含まれます。例えば、米国の電話番号は次のとおりです。

    <TelephoneNumber>
     <CountryCode isoCountryCode="US">1</CountryCode>
     <AreaOrCityCode>800</AreaOrCityCode>
     <Number>5551212</Number>
    </TelephoneNumber>
    

    国際電話の場合、CountryCode には、エスケープコードのあとに国のダイヤルコードが入ります。例えば英国は、次のように表します。

    <CountryCode isoCountryCode="UK">44</CountryCode>
    

    次はロンドンの例です。

    <TelephoneNumber>
     <CountryCode isoCountryCode="UK">44</CountryCode>
     <AreaOrCityCode>137</AreaOrCityCode>
     <Number>2801007</Number>
    </TelephoneNumber>
    
    FAX

    Fax 要素では、商品の出荷先や請求先となる個人や部門の FAX 番号が指定されます。この要素には、前述のTelephoneNumber 要素が含まれます。

    Municipality

    住所がある州の一区域である自治体の名前を示します。これは任意設定の要素であり、PostalAddress 要素の一部として追加されます。

    例:

    <PostalAddress>
     <Street>24 Mossy Creek</Street>
     <City>Chihuahua</City>
     <Municipality>Juárez</Municipality>
     <State isoStateCode="MX-CH">Chihuahua</State>
     <PostalCode>94089</PostalCode>
     <Country isoCountryCode="MX">Mexico</Country>
    </PostalAddress>
    
    Extrinsic

    部門または従業員の名前を指定します。Extrinsic 要素に指定できる値は、次のとおりです。

    Extrinsic 項目 説明
    ContactPerson 担当者の名前です。例:

    <Extrinsic name="ContactPerson">JIM SMITH</Extrinsic>
    
    7.2.1.9 コメント

    バイヤーが注文書に含めて送信することができる、人間に判読可能な任意の情報です。この文字列データは、サプライヤサイトのシステムでの自動処理を対象にしたものではありません。Comments 要素は、複数回発生する可能性があります。Comments 要素には、外部ファイルを含めるために Attachment 要素を含めることができます。

    7.2.1.9.1 添付ファイル

    Comments に外部ファイルを添付して、注文書を補足することができます。Comments 内で表示される Attachment 要素には、添付ファイルの外部 MIME パートへの参照のみが含まれます。すべての添付ファイルは、OrderRequest ドキュメントとともに単一のマルチパート転送で送信されます。これが不可能な場合でも、Attachment 要素によって提供される contentID から添付ファイルを入手可能である必要があります。添付ファイルの転送に関する詳細については、「添付ファイル」を参照してください。Attachment には、スキーム「cid:」の付いた URL が 1 つ含まれます。cXML ドキュメント内の添付ファイルは、次のように示されます。

    <Comments>
     <Attachment>
     <URL>cid: uniqueCID@cxml.org</URL>
     </Attachment>
     Please see attached image for my idea of what this should look like
    </Comments>
    

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

    属性 説明
    visibility 添付ファイルの表示レベルを示します。値 “internal” を指定すると、添付ファイルが内部目的で使用され、サプライヤには表示されないことが示されます。

    以下の Attachment は、サプライヤに表示されます。

    <Attachment visibility="internal">
     <URL>cid: uniqueCID@cxml.org</URL>
    </Attachment>
    
    7.2.1.10 Followup

    Followup 要素を使用しないことを強く推奨します。これまでの実装では、Followup 要素を使用して、後で発生する可能性のある StatusUpdateRequest ドキュメントが送信される URL を指定していました。cXML のすべての実装において、サーバー機能に関する情報 (サポートされる cXML バージョン、サポートされるトランザクション、およびそのトランザクションのオプションなど) を抽出し転送するには、より確実なプロファイルトランザクションを使用してください。

    7.2.1.11 ControlKeys

    オーダー確認、出荷通知、サービスシート、および請求書に対する通常のビジネスルールを上書きできる要素が提供されます。ControlKeys には以下の要素が含まれます。

    要素 説明
    OCInstruction ネットワークハブで設定された通常のビジネスルールに関係なく、このオーダーまたは明細でオーダー確認が許可されるかどうかを示します。「OCInstruction」を参照してください。
    ASNInstruction ネットワークハブで設定された通常のビジネスルールに関係なく、このオーダーまたは明細で出荷通知が許可されるかどうかを示します。「ASNInstruction」を参照してください。
    InvoiceInstruction ネットワークハブで設定された通常のビジネスルールに関係なく、このオーダーまたは明細で請求書が許可されるかどうかを示します。「InvoiceInstruction」を参照してください。
    SESInstruction ネットワークハブで設定された通常のビジネスルールに関係なく、このオーダーまたは明細でサービスシートが許可されるかどうかを示します。「SESInstruction」を参照してください。

    以下は、OrderRequestHeader 要素で使用される ControlKeys 要素の例です。

    <OrderRequestHeader orderDate="2015-12-31T16:52:15+05:30" orderID="ERS_header_10" orderType="regular" type="new">
     ...
    <ControlKeys>
     <InvoiceInstruction value="isERS"/>
     </ControlKeys>
    </OrderRequestHeader>
    
    7.2.1.11.1 OCInstruction

    ネットワークハブで設定された通常のビジネスルールに関係なく、このオーダーまたは明細でオーダー確認が許可されるかどうかを示します。OCInstruction には次の属性があります。

    属性 説明
    value
    (必須)
    オーダー確認が許可されるかどうかを示す値です。使用可能な値は次のとおりです。

    • allowed – オーダー確認が許可されます。
    • notAllowed – オーダー確認が許可されません。
    • requiredBeforeASN – 出荷通知の前にオーダー確認が必須です。

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

    要素 説明
    Lower 下限を定義する許容範囲を指定します。
    Upper 上限を定義する許容範囲を指定します。

    以下に OCInstruction の例を示します。

    <ControlKeys>
     <OCInstruction value="requiredBeforeASN">
     <Lower>
     <Tolerances>
     <QuantityTolerance>
     <Percentage percent="90"/>
     </QuantityTolerance>
     </Tolerances>
     </Lower>
     <Upper>
     <Tolerances>
     <QuantityTolerance>
     <Percentage percent="110"/>
     </QuantityTolerance>
     </Tolerances>
     </Upper>
     </OCInstruction>
    </ControlKeys>
    
    7.2.1.11.2 ASNInstruction

    ネットワークハブで設定された通常のビジネスルールに関係なく、このオーダーまたは明細で出荷通知が許可されるかどうかを示します。ASNInstruction には次の属性があります。

    属性 説明
    value
    (必須)
    出荷通知が許可されるかどうかを示す値です。使用可能な値は次のとおりです。

    • allowed – 出荷通知が許可されます。
    • notAllowed – 出荷通知が許可されません。

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

    属性 説明
    Lower 下限を定義する許容範囲を指定します。
    Upper 上限を定義する許容範囲を指定します。

    以下に ASNInstruction の例を示します。

    <ControlKeys>
     <ASNInstruction value="allowed">
     <Lower>
     <Tolerances>
     <QuantityTolerance>
     <Percentage percent="90"/>
     </QuantityTolerance>
     </Tolerances>
     </Lower>
     <Upper>
     <Tolerances>
     <QuantityTolerance>
     <Percentage percent="110"/>
     </QuantityTolerance>
     </Tolerances>
     </Upper>
     </ASNInstruction>
    </ControlKeys>
    
    7.2.1.11.3 InvoiceInstruction

    ネットワークハブで設定された通常のビジネスルールに関係なく、このオーダーまたは明細で請求書が許可されるかどうかを示します。InvoiceInstruction には次の属性があります。

    属性 説明
    value
    (必須)
    請求書が許可されるかどうかを示す値です。使用可能な値は次のとおりです。

    • isERS – オーダーまたは明細に、入庫に基づいて自動的にその請求書が転記されることを示す入庫/請求自動決済フラグが付けられます。
    • isNotERS オーダーまたは明細に入庫/請求自動決済フラグが付けられません。
    • allowed – 請求書が許可されます。
    • notAllowed – 請求書が許可されません。
    verificationType サポートされる値は、この品目における請求書の検証が入庫に基づいて行われることを示すgoodsReceipt だけです。これにより、請求書品目を入庫品目と一意に一致させることができます。入庫に基づく請求書検証は、複数の品目に分けて配達が行われ、請求書が転記される予定である場合に有効です。
    unitPriceEditable 請求書の作成時に単価を更新することがバイヤーまたはサプライヤに許可されるかどうかが指定されます。使用可能な値は次のとおりです。

    • yes – バイヤーまたはサプライヤが単価を編集できます。新しい価格は価格の許容範囲内である必要があります。
    • no – ネットワークハブで定義された取引ルールに関係なく、単価を編集できません。

    unitPriceEditable 属性が存在しない場合は、ネットワークハブに存在する通常設定の取引ルールに従います。

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

    要素 説明
    TemporaryPrice 価格設定情報が一時的なものであるか、最終的なものであるかを示します。オーダーヘッダーレベルまたはオーダー品目レベルで設定することができます。必須の value 属性があります。この属性は、yes または no に設定することができます。オーダー品目レベルで yes に設定すると、品目の価格設定は一時的なものとして見なされ、サプライヤは品目の請求書を作成することができません。オーダーヘッダーレベルで yes に設定すると、注文書全体の価格設定は一時的なものとして見なされ、サプライヤはオーダーのどの品目に対しても請求書を作成することができません。
    Lower 下限を定義する許容範囲を指定します。
    Upper 上限を定義する許容範囲を指定します。

    以下に InvoiceInstruction の例を示します。

    <ControlKeys>
     <InvoiceInstruction value="isNotERS" verificationType="goodsReceipt"
     unitPriceEditable="yes"/>
    </ControlKeys>
    

    次に示すのは、許容範囲の上限および下限を指定する InvoiceInstruction の別の例です。

    <ControlKeys>
     <InvoiceInstruction value="allowed">
     <Lower>
     <Tolerances>
     <QuantityTolerance>
     <Percentage percent="5.00"/>
     </QuantityTolerance>
     </Tolerances>
     </Lower>
     <Upper>
     <Tolerances>
     <QuantityTolerance>
     <Percentage percent="10.00"/>
     </QuantityTolerance>
     </Tolerances>
     </Upper>
     </InvoiceInstruction>
    </ControlKeys>
    
    7.2.1.11.4 SESInstruction

    ネットワークハブで設定された通常のビジネスルールに関係なく、このオーダーまたは明細でサービスシートが許可されるかどうかを示します。SESInstruction には次の属性があります。

    属性 説明
    value
    (必須)
    サービスシートが許可されるかどうかを示す値です。使用可能な値は次のとおりです。

    • allowed – サービスシートが許可されます。
    • notAllowed – サービスシートが許可されません。
    unitPriceEditable サービスシートの作成時に単価を更新することがバイヤーまたはサプライヤに許可されるかどうかが指定されます。使用可能な値は次のとおりです。

    • yes – バイヤーまたはサプライヤが単価を編集できます。新しい価格は価格の許容範囲内である必要があります。
    • no – ネットワークハブで定義された取引ルールに関係なく、単価を編集できません。

    unitPriceEditable 属性が存在しない場合は、ネットワークハブに存在する通常設定の取引ルールに従います。

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

    属性 説明
    Lower 下限を定義する許容範囲を指定します。
    Upper 上限を定義する許容範囲を指定します。

    以下に SESInstruction の例を示します。

    <ControlKeys>
     <SESInstruction value="allowed" unitPriceEditable="yes"/>
    </ControlKeys>
    

    次に示すのは、許容範囲の上限および下限を指定する SESInstruction の例です。

    <ControlKeys>
     <SESInstruction value="allowed">
     <Lower>
     <Tolerances>
     <QuantityTolerance>
     <Percentage percent="5.00"/>
     </QuantityTolerance>
     </Tolerances>
     </Lower>
     <Upper>
     <Tolerances>
     <QuantityTolerance>
     <Percentage percent="10.00"/>
     </QuantityTolerance>
     </Tolerances>
     </Upper>
     </SESInstruction>
    </ControlKeys>
    
    7.2.1.12 DocumentReference

    この要素では、前のドキュメント (OrderRequest、MasterAgreementRequest、InvoiceReference など) への正確な参照が提供されます。StatusUpdateRequest では、DocumentReference で更新する注文書が識別されます。

    7.2.1.13 SupplierOrderInfo

    この要素は、オーダーに関連したサプライヤ受注書の情報を定義するために、OrderRequestHeader 内で使用されます。SupplierOrderInfo は、OrderRequest および InvoiceDetailRequest ドキュメント内で使用されます。PunchOutOrderMessage 内で SupplierOrderInfo が使用されると、サプライヤが PunchOutOrderMessage に関連したオーダーを作成したことを表します。「delete」タイプの OrderRequest と OrderRequestHeader に削除対象の受注書を参照する SupplierOrderInfo 要素を含めて送信すると、バイヤーは後でオーダーをキャンセルできます。 SupplierOrderInfo には次の属性があります。

    属性 説明
    orderID このオーダーのサプライヤの受注書 ID。
    orderDate オーダーがサプライヤに送信される日付。
    7.2.1.14 TermsOfDelivery

    この要素では、注文書または出荷通知の配達条件が指定されます。TermsOfDelivery 要素は、ヘッダーレベルまたは明細レベルで適用できます。明細レベルに追加するには、この要素を ItemOut 要素に含めます。

    注記
    この要素を ShipNoticeHeader に追加して、ヘッダーレベルで条件を指定することもできます。明細レベルに追加するには、この要素を ShipNoticeItem 要素に含めます。TermsOfDelivery 要素には次の属性が含まれます。

    属性 説明
    TermsOfDeliveryCode 標準の配達条件およびインコタームズです。
    ShippingPaymentMethod 送料支払方法

    • Account – 送料がアカウントに請求される場合
    • Collect – 受取人が送料を支払う場合
    • Prepaid by Seller – 販売者が出荷前に送料を運送業者に支払う場合
    • Mixed – 委託の一部が受取人によって支払われて、一部が前払いされる場合
    • Other – その他の出荷支払方法または第三者が送料を支払う場合。支払方法の追加情報を入力できます。
    TransportTerms 輸送条件。使用可能な値は次のとおりです。

    • Free-Carrier
    • CostAndFreight
    • DeliveredAtFrontier
    • Other – このオプションを指定するときに、説明を追加で入力できます。
    Address 出荷通知の届け先住所
    Comments 輸送条件に “Other” が選択されたときなどの、配達条件に関する追加情報。

    TermsOfDelivery 要素の例を次に示します。

    <TermsOfDelivery>
     <TermsOfDeliveryCode value=”PriceCondition”/>
     <ShippingPaymentMethod value=”AdvanceCollect”/>
     <TransportTerms value=”Other”>Contract Terms</TransportTerms>
     <Address>
     <Name xml:lang=”en-US”>SN Services</Name>
     <PostalAddress name="default">
     <Street>123 Anystreet</Street>
     <City>Birmingham</City>
     <State isoStateCode="US-AL">AL</State>
     <PostalCode>35005</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     </PostalAddress>
     </Address>
     <Comments xml:lang=”en-US” type=”Transport”>As per the Transport contract</Comments>
     <Comments xml:lang=”en-US” type=”TermsOfDelivery”>Delivery at the doorstep</Comments>
    </Terms Of Delivery>
    
    7.2.1.15 DeliveryPeriod

    サプライヤが商品を配達できるか、受入担当者が入荷を処理できる最早日と最遅日が指定されます。

    Period

    次の属性が含まれます。

    属性 説明
    startDate サプライヤが商品を配達できるか、受入担当者が入荷を受け入れることができる最早日が指定されます。
    endDate サプライヤが商品を配達できる最遅日、または受入担当者が入荷を受け入れることができなくなる日付が指定されます。
    7.2.1.16 OrderRequestHeaderIndustry

    オーダーに関する業種固有の情報が含まれます。OrderRequestHeaderIndustry には以下の要素が含まれます。

    属性 説明
    ReferenceDocumentInfo 参照されるドキュメントに関する情報が含まれます。この要素は任意設定であり、複数回発生する可能性があります。「ReferenceDocumentInfo」を参照してください。
    Priority サプライヤのオーダーの優先度を示します。この要素は任意設定です。優先度を示すDescription 要素が含まれます。 Priority には次の属性があります。

    属性 説明
    level (必須) 優先度レベル (1 ~ 5 の整数) を指定します。
    sequence 優先度レベルが同じ品目に優先度を付けるための 2 つ目の一意のオーダー番号です。優先度レベルが同じ 2 つの品目に、同じ順序番号を持たせることはできません。
    inventory_level ターゲットに関する在庫 (バッファ) レベル (%) が表示されます。これは、0.00 から 100.00 までの小数値として指定されます。
    ExternalDocumentType 外部システム (ERP など) で管理されるドキュメントに関する情報が含まれます。オーダーとともに送信すると、さまざまな業務取引を一意に区別できます。外部システムからドキュメントの種類を指定する必須の documentType 属性が含まれます。また、任意設定の Description 要素もあります。
    QualityInfo OrderRequest 全体の品質情報を表します。
    AssetInfo 明細の単位あたりの詳細な資産情報を提供します。「AssetInfo」を参照してください。

    次の例は、ヘッダーレベルで認定を要求する OrderRequest の OrderRequestHeaderIndustry を示しています。

    <OrderRequestHeaderIndustry>
     <QualityInfo requiresQualityProcess="yes">
     <IdReference domain="certificateType" identifier="CERT123">
     <Description xml:lang="en-US">Certificate Type description</Description>
     </IdReference>
     </QualityInfo>
    </OrderRequestHeaderIndustry>
    
    7.2.1.16.1 ReferenceDocumentInfo

    参照されるドキュメントに関する情報が含まれます。ReferenceDocumentInfo には次の属性があります。

    属性 説明
    lineNumber 参照されるドキュメントの明細の明細番号。
    scheduleLineNumber 参照される lineNumber の納入日程行明細の納入日程行番号。この属性に値がある場合、 lineNumber 属性は必須です。
    status 参照されるドキュメントを参照するために使用される状況。使用可能な値は、次のとおりです。

    • created
    • released
    • open
    • completed
    • closed
    • cancelled

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

    属性 説明
    DocumentInfo | DocumentReference DocumentInfo により、システムで認識される、以前のドキュメントが識別されます。「DocumentInfo」を参照してください。DocumentReference により、更新される以前のオーダーへの正確な参照が提供されます。「DocumentReference 」を参照してください。
    DateInfo このドキュメントに関連する日付情報が含まれます。
    Contact オーダーをフォローアップするための連絡先情報。「Contact」を参照してください。
    Extrinsic このオブジェクトに関連するすべての追加情報が含まれます。
    7.2.1.17 Extrinsic

    この要素には、機械が判読可能な、オーダーに関連した情報が含まれますが、cXML プロトコルによって定義されたものではありません。一方で、Comments 要素は、人間が使用できる情報を渡します。Extrinsic 要素には、後続のドキュメントに表示される可能性のあるデータが含まれますが、Comments 要素には含まれません。このレベルでは、 Extrinsic によって注文書に含まれるすべての品目の記述が拡張されます。ItemOut に含まれる記述に一切影響を与えず、注文書全体の情報を Extrinsic に記述することも可能です。

    Extrinsic 要素の name 属性で指定された値は、OrderRequestHeader 要素および個々の ItemOut 要素(ItemDetail 要素の中) の中のリストで 1 回だけ使用できます。OrderRequestHeader 一覧と ItemOut 要素に関連付けられた任意の一覧の両方で、同じ名前を表示することはできません。すべての ItemOut 一覧内で同じExtrinsic 名と値が繰り返す場合は、それを OrderRequestHeader に移動する必要があります。Extrinsic 要素は、IndexItem 要素、PunchOutSetupRequest, 要素、ContractItem, and 、およびPostalAddress 要素の中でも使用できます。これらのコンテキストについては、本マニュアルの中で後ほど説明します。Extrinsic 値は、大文字と小文字を区別します。

    7.2.2 ItemOut

    次の例は、最小限の有効な ItemOut 要素を示しています。

    <ItemOut quantity="1" lineNumber="1">
     <ItemID>
     <SupplierPartID>5555</SupplierPartID>
     </ItemID>
    </ItemOut>
    

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

    属性 説明
    quantity
    (必須)
    要求された品目の数。数量単位として分数が許容されます。値は、パンチアウトセッション中に、サプライヤによって既に検査済みになっている場合があります。この値には、負の値は使用できません。
    lineNumber オーダーにおける品目の位置。この順序の値は、「新規」 OrderRequest 内のItemOut ごとに 1 ずつ増加します。ほかの ItemOut のコンテキストに比べて、この属性は意味がない場合もありますが、クライアントは、常にこの属性を OrderRequest内で指定する必要があります。
    requisitionID この明細に対するバイヤーの購入申請識別子。requisitionID がOrderRequestHeader 内で指定されている場合は含めないでください。
    agreementItemNumber この明細に対するバイヤーの主契約の識別子。
    requestedDeliveryDate 配達の日付項目が要求されたことを示します。これにより、OrderRequest 内で品目レベルの配達日付を使用できます。日付は、ISO 8601 フォーマットに従っていなければなりません。
    isAdHoc 品目がカタログ外 (特別) であることを示します。カタログ外の注文書には、電子カタログから選択された品目ではなく、申請者によって手動で入力された品目が記載されています。このような品目には有効な品番がないことがよくあります。通常、カタログ外のオーダーには特別な検証および処理が必要です。製品やサービスを特別に購入するために、または電子カタログで検索できないためにユーザーはカタログ外品目を入力する場合があります。
    parentLineNumber 対応する親明細の明細番号。これは必須フィールドであり、itemType=”item” を含む明細にのみ適用できます。
    itemType 品目の種類を指定します。使用可能な値は次のとおりです。

    • composite – 品目グループを識別します。
    • item – 独立した明細を識別します。
    • lean – 明細で予定されている子品目がないことを示します。
    requiresServiceEntry サービスを提供した方法を記述する ServiceEntryRequest サービスシートが品目に必要であるかどうかを指定します。
    confirmationDueDate サプライヤがバイヤーに対して注文書の受領確認を回答する期限を指定します。
    compositeItemType 親品目でグループごとの価格設定が使用されるかどうかを指定します。使用可能な値は”groupLevel” または”itemLevel” です。
    itemClassification 現在の明細が品目とサービスのどちらであるかを指定します。使用可能な値は次のとおりです。

    • material
    • service
    itemCategory 構成品目または商品の購買方法を指定します。使用可能な値は次のとおりです。

    • materialUnknown – 品目コードを指定しない商品の購買を示します。
    • text – 自由記入形式のテキスト項目の購買を示します。
    • stockTransfer – あるプラントから別のプラントへの在庫の転送を示します。
    • materialGroup – 値または数量を指定しない商品の購買を示します。
    • subcontract – 最終製品を製造する契約製造メーカーに構成品目情報を提供して品目を購買します。
    • consignment – バイヤーによって品目またはサービスが消費されるまでサプライヤへの支払いが保留される特別なプロセスを使用して品目を管理します。
    • thirdParty – サードパーティベンダから品目を購買します。
    • limit – この品目の対象である計画外サービスまたは品目に想定上の限度があることを示します。
    subcontractingType 通常の外注改修または置換シナリオをサポートするように決定された品目提供区分に基づいて、バイヤーの ERP システムで外注の種類が決定されます。使用可能な値は次のとおりです。

    • regular – 標準の外注シナリオ。
    • refurbWithoutChange – 品目の変更なしの改修。
    • refurbWithChange – 品目の変更ありの改修。
    • replacement – 品目の置換。
    stockTransferType バイヤーの ERP システムから、在庫転送オーダーまたは在庫転送リリースに基づいて在庫転送の種類が送信されます。使用可能な値は次のとおりです。

    • intra – 同じ会社コード内の 1 つのプラントから別のプラントに在庫を転送することを示します。
    • inter – 1 つのプラントから異なる会社コードの別のプラントに在庫を転送することを示します。「在庫転送オーダーの OrderRequest の例」を参照してください。
    requestedShipmentDate 品目のバイヤーが依頼した出荷日。
    isReturn “yes” に設定すると、品目が返品品目であることが示されます。
    returnAuthorizationNumber 明細の返品確認番号。
    isDeliveryCompleted “yes” に設定すると、この品目が終了とみなされ、今後の配達は予定されません。このフラグは、情報の目的でバイヤーによって設定されます。
    unlimitedDelivery yes に設定すると、明細が数量制限なしの納入に対応していることが示されます。ERPでは、対応する許容範囲として納入無制限のフラグが設定されます。このフラグは、出荷通知の作成時にのみ使用されます。
    isItemChanged yes に設定すると、品目が変更されたことが示されます。
    isKanban yes に設定すると、品目に対してかんばんプロセスのフラグが設定されていることが示されます。かんばん関連のオーダーでは、期限内に 100% の品質を提供することが求められます。
    stoDelivery 在庫転送オーダー明細に対して使用可能な配送オプション。

    • full (通常の設定) – オーダーに対して完全配達のみが許可されます。これは、在庫転送オーダーまたは在庫転送リリースに固有です。
    • partial – オーダーに対して部分配達が許可されます。これは、在庫転送オーダーまたは在庫転送リリースに固有です。
    stoOrderCombination 属性 itemCategory に値 “stockTransfer” が含まれ、属性 stoOrderCombination が “yes” に設定されている場合、出荷通知の作成時に設定されたフラグを使用して、さまざまな在庫転送オーダーからの品目を組み合わせることができます。オーダーの組み合わせの対応するフラグは、バイヤーの ERP で設定されます。この設定は、在庫転送オーダーまたは在庫転送リリースに関連します。
    stoFinalDelivery 属性 itemCategory に値「stockTransfer」が含まれ、属性 stoFinalDelivery が「yes」に設定されている場合、出荷通知をさらに作成することはできません。この設定は、在庫転送オーダーまたは在庫転送リリースに関連します。

    オーダーに更新が発生しても、品目の lineNumber 属性の値は変更されずに保持されます。品目をオーダーから削除しても、残りの品目の lineNumber 属性は変更されません。新しい品目には、以前のオーダーに含まれていた品目よりも大きな数が付けられます。既存の品目に変更を加えても (たとえば、数量の増加)、その品目の lineNumber 属性には影響を与えません。

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

    属性 説明
    ItemID 品目の一意の ID が指定されます。「ItemID」を参照してください。
    Path ドキュメントのノードおよびパス情報を示します。「Path 要素」を参照してください。
    ItemDetail | BlanketItemDetail ItemDetail には、購買アプリケーションでユーザーに提示される明細に関する記述的な情報が含まれます。「ItemDetail」を参照してください。
    BlanketItemDetail は、包括注文書に固有のサプライヤおよび商品分類レベルの詳細を示します。「BlanketItemDetail」を参照してください。
    SupplierID | SupplierList SupplierID はサプライヤの ID です。SupplierList では、見積品目に関連する可能性があるサプライヤの一覧を定義します。「SupplierID または SupplierList」を参照してください。
    ShipTo 品目の出荷先住所を指定します。
    Shipping 品目の出荷費用が含まれます。
    Tax 品目の税情報が含まれます。
    SpendDetail 出張明細、費用明細、および人材明細に関する詳細情報が提供されます。「SpendDetail」を参照してください。
    Distribution 品目の費用を複数の組織で分割します。「Distribution」を参照してください。
    Contact オーダーをフォローアップするための連絡先情報が含まれます。「Contact」を参照してください。
    TermsOfDelivery 出荷通知に対する配達条件が指定されます。「TermsOfDelivery」を参照してください。
    Comments この品目に関連するコメントが含まれます。「コメント」を参照してください。
    Tolerances オーダー確認、出荷通知、サービスシート、および請求書に対する通常のビジネスルールを上書きできる要素が提供されます。「ControlKeys」を参照してください。
    ScheduleLine 明細の配送スケジュールに関する情報が含まれます。「ScheduleLine」を参照してください。
    MasterAgreementReference | MasterAgreementIDInfo MasterAgrreementReference には、リリースの派生元である主契約への参照が含まれます。MasterAgreementIDInfo には、リリースの派生元である主契約の ID が含まれます。
    ItemOutIndustry 業種固有の情報が含まれます。「ItemOutIndustry」を参照してください。
    Packaging 明細のパッケージに関する詳細が指定されます。「Packaging」を参照してください。
    ReleaseInfo 品目または商品のリリースについての詳細が含まれます。「ReleaseInfo」を参照してください。
    Batch 1 回の生産実行で生産される品目または製品のバッチ情報が含まれます。「Batch」を参照してください。

    次の例は、複雑な ItemOut を示しています。

    <ItemOut quantity="2" lineNumber="1"
     requestedDeliveryDate="1999-03-12">
     <ItemID>
     <SupplierPartID>1233244</SupplierPartID>
     <SupplierPartAuxiliaryID>ABC</SupplierPartAuxiliaryID>
     </ItemID>
     <ItemDetail>
     <UnitPrice>
     <Money currency="USD">1.34</Money>
     </UnitPrice>
     <Description xml:lang="en">hello</Description>
     <UnitOfMeasure>EA</UnitOfMeasure>
     <Classification domain="UNSPSC">12345</Classification>
     <ManufacturerPartID>234</ManufacturerPartID>
     <ManufacturerName xml:lang="en">foobar</ManufacturerName>
     <URL>www.bar.com</URL>
     </ItemDetail>
     <ShipTo>
     <Address>
     <Name xml:lang="en">Acme Corporation</Name>
     <PostalAddress name="Headquarters">
     <Street>123 Anystreet</Street>
     <City>Sunnyvale</City>
     <State isoStateCode="US-CA">CA</State>
     <PostalCode>90489</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     </PostalAddress>
     </Address>
     </ShipTo>
     <Shipping>
     <Money currency="USD">1.34</Money>
     <Description xml:lang="en-US">FedEx 2-day</Description>
     </Shipping>
     <Tax>
     <Money currency="USD">1.34</Money>
     <Description xml:lang="en">foo</Description>
     </Tax>
     <Distribution>
     <Accounting name="DistributionCharge">
     <AccountingSegment id="23456">
     <Name xml:lang="en-US">G/L Account</Name>
     <Description xml:lang="en-US">Entertainment</Description>
     </AccountingSegment>
     <AccountingSegment id="2323">
     <Name xml:lang="en-US">Cost Center</Name>
     <Description xml:lang="en-US">Western Region Sales
     </Description>
     </AccountingSegment>
     </Accounting>
     <Charge>
     <Money currency="USD">.34</Money>
     </Charge>
     </Distribution>
     <Distribution>
     <Accounting name="DistributionCharge">
     <AccountingSegment id="456">
     <Name xml:lang="en-US">G/L Account</Name>
     <Description xml:lang="en-US">Travel</Description>
     </AccountingSegment>
     <AccountingSegment id="23">
     <Name xml:lang="en-US">Cost Center</Name>
     <Description xml:lang="en-US">Europe Implementation
     </Description>
     </AccountingSegment>
     </Accounting>
     <Charge>
     <Money currency="USD">1</Money>
     </Charge>
     </Distribution>
     <Comments xml:lang="en-US">Comment</Comments>
    </ItemOut>
    

    ItemDetail によって示される品目の一意の識別子のみを使う代わりに、ItemID 要素で追加データをサプライヤに送信できます。isAdHoc = “yes” が一部の品目に存在するが、ほかの品目には存在しない場合は、購入申請を 2 つの購入申請 (カタログ品目用に 1 つとカタログ外品目用に 1 つ) に分割する必要があります。これによって、サプライヤは可能な限り多くの購入申請品目を自動的に処理できるようになり、カタログ品目とカタログ外品目の両方を手動で処理する必要がなくなります。ShipTo、Shipping、Tax、Contact、Comments、および Extrinsic 要素 (一部は ItemDetail またはSpendDetail 内で入れ子になります) は、OrderRequestHeader 内で使用できる要素と同一です。これらの要素では、出荷、出荷タイプ、および関連付けられたコストなどのデータを品目ごとに指定します。これらの要素は、OrderRequestHeader レベル、または ItemOut レベルのいずれか一方で使用してください。両方のレベルでは使用しないでください。税金は唯一の例外です。詳細については、「」を参照してください。

    返品品目に関する ItemOut の例を次に示します。

    <ItemOut quantity="2" isReturn="true" returnAuthorizationNumber="RMA235">
     <ItemDetail>
     ...
     </ItemDetail>
     <Comments>Defective product</Comments>
    </ItemOut>
    

    以下の例は、グループごとに価格が設定されている品目グループの種類を示しています。

    <InvoiceDetailOrder>
     <InvoiceDetailOrderInfo>
     <OrderIDInfo orderID=""></OrderIDInfo>
     </InvoiceDetailOrderInfo>
     <InvoiceDetailItem quantity="1" invoiceLineNumber="1" itemType="composite" compositeItemType="groupLevel">
     <UnitOfMeasure></UnitOfMeasure>
     <UnitPrice>
     <Money currency="USD">21.00</Money>
     </UnitPrice>
     <InvoiceDetailItemReference lineNumber="1">
     <ItemID>
     <SupplierPartID>1</SupplierPartID>
     </ItemID>
     <Description xml:lang="en">Parent Item</Description>
     </InvoiceDetailItemReference>
     <TotalAllowances>
     <Money currency="USD">25.00</Money>
     </TotalAllowances>
     <TotalAmountWithoutTax>
     <Money currency="USD">290.00</Money>
     </TotalAmountWithoutTax>
     <NetAmount>
     <Money currency="USD">290.00</Money>
     </NetAmount>
     </InvoiceDetailItem>
     <InvoiceDetailItem invoiceLineNumber="2" quantity="15" parentInvoiceLineNumber="1" itemType="item">
     <UnitOfMeasure>33</UnitOfMeasure>
     <UnitPrice>
     <Money currency="USD">21.00</Money>
     </UnitPrice>
     <InvoiceDetailItemReference lineNumber="1">
     <ItemID>
     <SupplierPartID>1</SupplierPartID>
     </ItemID>
     <Description xml:lang="en">Child Item</Description>
     </InvoiceDetailItemReference>
     <SubtotalAmount>
     <Money currency="USD">315.00</Money>
     </SubtotalAmount>
     <GrossAmount>
     <Money currency="USD">290.00</Money>
     </GrossAmount>
     <InvoiceItemModifications>
     <Modification>
     <AdditionalDeduction>
     <DeductionAmount>
     <Money currency="USD">47.25</Money>
     </DeductionAmount>
     <DeductionPercent percent="15"></DeductionPercent>
     </AdditionalDeduction>
     <ModificationDetail name="Contract Allowance">
     <Description xml:lang="en"/>
     </ModificationDetail>
     </Modification>
     </InvoiceItemModifications>
     <TotalAllowances>
     <Money currency="USD">25.00</Money>
     </TotalAllowances>
     <TotalAmountWithoutTax>
     <Money currency="USD">290.00</Money>
     </TotalAmountWithoutTax>
     <NetAmount>
     <Money currency="USD">290.00</Money>
     </NetAmount>
     </InvoiceDetailItem>
    </InvoiceDetailOrder>
    

    以下の例は、品目ごとに価格が設定されている品目グループの種類を示しています。

    <InvoiceDetailOrder>
     <InvoiceDetailOrderInfo>
     <OrderIDInfo orderID=""></OrderIDInfo>
     </InvoiceDetailOrderInfo>
     <InvoiceDetailItem quantity="1" invoiceLineNumber="1" itemType="composite" compositeItemType="itemLevel">
     <UnitOfMeasure></UnitOfMeasure>
     <UnitPrice>
     <Money currency="USD">0.00</Money>
     </UnitPrice>
     <InvoiceDetailItemReference lineNumber="1">
     <ItemID>
     <SupplierPartID>1</SupplierPartID>
     </ItemID>
     <Description xml:lang="en">Parent Item</Description>
     </InvoiceDetailItemReference>
     </InvoiceDetailItem>
     <InvoiceDetailItem invoiceLineNumber="2" quantity="15" parentInvoiceLineNumber="1" itemType="item">
     <UnitOfMeasure>33</UnitOfMeasure>
     <UnitPrice>
     <Money currency="USD">21.00</Money>
     </UnitPrice>
     <InvoiceDetailItemReference lineNumber="1">
     <ItemID>
     <SupplierPartID>1</SupplierPartID>
     </ItemID>
     <Description xml:lang="en">Child Item</Description>
     </InvoiceDetailItemReference>
     <SubtotalAmount>
     <Money currency="USD">315.00</Money>
     </SubtotalAmount>
     <GrossAmount>
     <Money currency="USD">290.00</Money>
     </GrossAmount>
     <InvoiceItemModifications>
     <Modification>
     <AdditionalDeduction>
     <DeductionAmount>
     <Money currency="USD">47.25</Money>
     </DeductionAmount>
     <DeductionPercent percent="15"/>
     </AdditionalDeduction>
     <ModificationDetail name="Contract Allowance">
     <Description xml:lang="en"></Description>
     </ModificationDetail>
     </Modification>
     </InvoiceItemModifications>
     <TotalAllowances>
     <Money currency="USD">25.00</Money>
     </TotalAllowances>
     <TotalAmountWithoutTax>
     <Money currency="USD">290.00</Money>
     </TotalAmountWithoutTax>
     <NetAmount>
     <Money currency="USD">290.00</Money>
     </NetAmount>
     </InvoiceDetailItem>
    </InvoiceDetailOrder>
    

    次の例は「リーン」明細 (子のない明細) の ItemOut を示しています。

    <ItemOut lineNumber="1" quantity="1" requestedDeliveryDate="2018-09-20T03:30:00-07:00" itemType="lean">
     <ItemID>
     <SupplierPartID>Not Available</SupplierPartID>
     </ItemID>
     <BlanketItemDetail>
     <Description xml:lang="en">Test Service PO / Previous PO Number</Description>
     <UnitPrice>
     <Money alternateAmount="" alternateCurrency="" currency="CAD">800.00</Money>
     </UnitPrice>
     <UnitOfMeasure>AU</UnitOfMeasure>
     <Classification domain="ccc">A050</Classification>
     <Extrinsic name="ExpectedUnplanned">
     <Money alternateAmount="" alternateCurrency="" currency="CAD">800.00</Money>
     </Extrinsic>
     </BlanketItemDetail>
     <SpendDetail>
     <Extrinsic name="service">service</Extrinsic>
     </SpendDetail>
    </ItemOut>
    
    7.2.2.1 ItemDetail

    基本的な ItemDetail 要素には、購買アプリケーションがユーザーに提示する明細に関する記述的な情報が含まれます。「ItemDetail」を参照してください。

    Modifications

    ItemDetail 内に含まれる UnitPrice 要素には、品目の元の価格または出荷価格の変更を格納する Modifications 要素も格納されます。「ModificDtions [115 ページ]」を参照してください。

    Modifications 要素には、明細レベルで明細に適用可能な値引きおよび手数料の詳細を含む Modification 要素を 1 つ以上格納できます。「ModificDtion [115 ページ]」を参照してください。

    7.2.2.1.1 ItemDetailIndustry

    ItemDetailIndustry には、業種固有の詳細情報が含まれます。この要素は任意設定です。この要素には、次の属性があります。

    属性 説明
    isConfigurableMaterial “yes” に設定すると、品目が選定可能品目として定義されるため、製品特性があります。

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

    属性 説明
    ItemDetailRetail 小売業に関する品目固有の詳細情報が含まれます。この要素は任意設定です。「ItemDetailRetail」を参照してください。ItemDetailIndustry の例を次に示します。
    <ItemDetail>
     <ItemDetailIndustry>
     <ItemDetailRetail>
     <EANID>815-12</EANID>
     <EuropeanWasteCatalogID>5-12</EuropeanWasteCatalogID>
     </ItemDetailRetail>
     </ItemDetailIndustry>
    </ItemDetail>
    <ItemOutIndustry>
     <ItemOutRetail>
     <PromotionVariantID>815-12</PromotionVariantID>
     <PromotionDealID>8-13</PromotionDealID>
     </ItemOutRetail>
    </ItemOutIndustry>
    
    7.2.2.1.1.1 ItemDetailRetail

    ItemDetailRetail には、小売業に関する品目固有の詳細情報が含まれます。以下の要素が含まれます。

    要素 説明
    EANID 商品の国際 EAN 協会または UPC (Universal Product Code) に従って製造メーカーの製品に割り当てられる ID が指定されます。この要素は任意設定です。
    EuropeanWasteCatalogID EU Waste Catalog (EWC) に一覧表示されている商品の一意の ID が指定されます (手数料が必要な場合)。この要素は任意設定です。
    Characteristic さまざまな業種全体で使用できる品目に関する詳細が指定されます。この要素は任意設定です。Characteristic には次の属性があります。

    属性 説明
    domain
    (必須)
    特性の種類。
    例:
    size、sizeCode、color、colorCode、quality、qualityCode、grade、gradeCode。
    value
    (必須)
    ドメインの値。
    code 通貨コードや数量単位など、特性に関連するコード。
    7.2.2.2 BlanketItemDetail

    包括注文書 (orderType=”blanket”) に固有のサプライヤおよび商品分類レベルの詳細が提供されます。

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

    例:

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

    例:

    <ExpectedLimit>
     <Money currency="USD">800.00</Money>
    </ExpectedLimit>
    
    MaxAmount 許容される最高金額を定義します。
    MinAmount 許容される最低金額を定義します。
    MaxContractAmount バイヤーによって指定されたとおりに、契約品目に対して許可される最高金額を定義します。
    MaxAdhocAmount バイヤーによって指定されたとおりに、計画外品目に対して許可される最高金額を定義します。
    MaxQuantity 許容される最高数量を定義します。
    MinQuantity 許容される最低数量を定義します。
    UnitPrice 品目の単位あたりの価格。
    UnitOfMeasure 明細の数量単位。「UnitOfMeasure」を参照してください。
    PriceBasisQuantity 明細の数量ベースの価格設定が記述されます。要素として UnitOfMeasure およびDescription 、属性として quantity および conversionFactor が含まれます。. 「PriceBasisQuantity」を参照してください。
    Classification 品目が類似するカテゴリにグループ化されます。通常は、選択した品目ごとに UNSPSC(United Nations Standard Products and Services Code) 商品分類コードが一覧表示されます。これらのコードは、バイヤー組織およびサプライヤ組織内で、経理やレポート作成のためバックエンドシステムで使用されます。UNSPSC コードの一覧については、www.unspsc.org を参照してください。Classification@domain を使用して、バックエンドシステムで使用される製品階層および商品分類情報を指定することもできます。Classification には、任意設定の code 属性があります。これに指定されたコードで商品分類が識別されます。
    Extrinsic このオブジェクトに関連するすべての追加情報が含まれます。「Extrinsic」を参照してください。

    BlanketItemDetail の例を次に示します。

    <BlanketItemDetail>
     <Description xml:lang="en">Super Security Consulting Project</Description>
     <OverallLimit>
     <Money currency="USD">1000.00</Money>
     </OverallLimit>
     <ExpectedLimit>
     <Money currency="USD">800.00</Money>
     </ExpectedLimit>
     <MaxAmount>
     <Money currency="USD">70000</Money>
     </MaxAmount>
     <MaxContractAmount>
     <Money currency="USD">50000</Money>
     </MaxContractAmount >
     <MaxAdhocAmount>
     <Money currency="USD">20000</Money>
     </MaxAdhocAmount>
     <UnitPrice><Money currency="USD">5000</Money></UnitPrice>
     <UnitOfMeasure>EA</UnitOfMeasure>
     <Classification domain="ascc">606501</Classification>
     <Extrinsic name="Construction"></Extrinsic>
     <Extrinsic name="ServicePeriod">
     <Period endDate="2013-09-01T23:59:59-00:00" startDate="2012-07-12T00:00:00-00:00"></Period>
     </Extrinsic>
    </BlanketItemDetail>
    

    7.2.2.3 SpendDetail

    この任意設定の要素では、出張明細、費用明細、および人材明細に関する詳細情報が提供されます。次の例では、cXML.dtd からの SpendDetail の要素宣言を示しています。

    <!ELEMENT SpendDetail (TravelDetail | FeeDetail | LaborDetail | Extrinsic)>
    

    SpendDetail は、次のような種類のメッセージの ItemIn および ItemOut 要素内で使用できます。

    • PunchOutSetupRequest
    • PunchOutOrderMessage
    • OrderRequest
    • ConfirmationRequest

    SpendDetail には属性がありません。基本的な ItemIn 要素では、パンチアウトセッション中にショッピングカートの品目が購買アプリケーションの購入申請に追加されます。ItemIn は「ItemIn」で定義されています。

    7.2.2.3.1 FeeDetail

    cXML のほかの部分では明示的に定義されていない 1 回限りの費用または繰り返し発生する費用についての情報を定
    義します。たとえば、家具レンタル費用のような 1 回限りの費用は TravelDetail または LaborDetail 要素のどのカテゴリにも該当しません。このような費用は、FeeDetail で定義します。FeeDetail には次の属性があります。

    属性 説明
    isRecurring 費用が繰り返し発生することが示されます。
    UnitRate

    時間またはほかの数量の単位当たりで支払われる金額。料金表のように UnitRates が複数ある場合は、TermReference 要素を使用してそれぞれを区別してください。

    Period

    FeeDetail の対象となる期間を定義します。

    7.2.2.3.2 LaborDetail

    LaborDetail には、臨時社員に関連する項目の情報が含まれます。次の例では、cXML.dtd からの LaborDetailの要素宣言を示しています。

    <!ELEMENT LaborDetail ( UnitRate+, Period, Contractor?, JobDescription?, Supervisor?, WorkLocation?, Extrinsic*)>
    

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

    属性 説明
    supplierReferenceCode サプライヤの相互参照用見積 ID または提案 ID です。
    UnitRate

    UnitRate では、時間単位当たり (またはその他の数量単位) で支払われる金額が示されます。UnitRates が複数ある場合は、TermReference 要素を使用してそれぞれを区別してください。

    TermReference

    TermReference は、該当する UnitRate の定義を識別する一般的な基本要素です。TermReference には以下の属性があります。

    属性 説明
    termName
    (必須)
    条件を含む ID 属性の名前。
    term
    (必須)
    その属性の値、つまり条件自身。

    次に、TermReference が含まれた UnitRate の例を示します。

    <UnitRate>
     <Money currency="USD">75</Money>
     <UnitOfMeasure>HUR</UnitOfMeasure>
     <TermReference termName="payCode" term="Overtime"/>
    </UnitRate>
    

    この TermReference によって、この UnitRate が Overtime payCode (時間延長支払コードのレート) であることが示されています。

    Period

    Period ではサービスが発生する期間を定義します。

    Contractor

    Contractor では、臨時社員として業務に従事するコントラクタが識別されます。コントラクタはContractorIdentifier 要素で一意に識別されます。これはオーダーまたはタイムカードを送信する前に、バイヤーとサプライヤ間で交換されます。TimeCard トランザクションの詳細については、「TimeCard トランザクション」を参照してください。Contractor には以下の要素が含まれます。

    属性 説明
    ContractorIdentifier バイヤーおよびサプライヤの両方でコントラクタが一意に識別されます。
    ContractorIdentifier には次の属性があります。

    属性 説明
    domain
    (必須)
    コントラクタの識別情報を表すドメイン。この属性により、バイヤーおよびサプライヤシステムのどちらが ID を割り当てたのかを判断することが可能となります。buyerReferenceID は、ID がバイヤーシステムで生成されたことを示します。supplierReferenceID は、ID がサプライヤシステムで生成されたことを示します。
    Contact コントラクタに関する連絡先情報が含まれます。
    JobDescription

    JobDescription は、実行される業務または仕事についてのテキスト形式の説明です。

    Supervisor

    Supervisor では、コントラクタの指揮命令者の連絡先情報が指定されます。

    WorkLocation

    WorkLocation は、業務の就業場所の住所です。

    Extrinsic

    LaborDetail 内のこの任意設定の要素には、バイヤー企業がサプライヤに渡す追加データが含まれます。cXML 仕様では Extrinsic 要素の内容が定義されません。内容については、それぞれのバイヤー企業とサプライヤが合意して、実装する必要があります。以下の例では、作業が実行される地域が渡されます。

    <Extrinsic name=”region"">sfbay</Extrinsic>
    
    7.2.2.3.3 Extrinsic

    Extrinsic は、バイヤーとサプライヤのペアが TravelDetail、FeeDetail、または LaborDetail 内で一致しない支出に関する詳細情報を通知できる SpendDetail, でサポートされています。Extrinsic 要素は、機械が判読できる追加情報を提供するように設計されています。この要素は cXML プロトコルを拡張し、すべての実装にとって必ずしも必要とはならないような機能をサポートします。cXML 仕様では、Extrinsic 要素のコンテンツが定義されません。バイヤーとサプライヤの各ペアは、Extrisic 要素の定義に合意し、実装する必要があります。未定義の支出カテゴリの詳細情報が説明されます。Extrinsic 要素の name 属性では、印刷、市場調査、またはプロジェクトの人材などの支出カテゴリの種類を指定する必要があります。1 つの SpendDetail 要素内の全 Extrinsic 要素は、カテゴリ名を指定するために使用された name 属性とともに 1つの Extrinsic の下に含めることが推奨されます。この例は、SpendDetail 要素内の 1 つのヘッダーの下に入れ子になった 2 つの Extrinsic 要素を示しています。

    <SpendDetail>
     <Extrinsic name="MarketResearchDetail">
     <Extrinsic name="ResearchObjectives">test objectives</Extrinsic>
     <Extrinsic name="ProjectNumber">PN3434343</Extrinsic>
     </Extrinsic>
    </SpendDetail>
    

    Extrinsic 要素は、OrderRequestHeader、ItemDetail、および ContractItem 要素に表示することもできます。これらのコンテキストについては、本マニュアルのほかの箇所でさらに詳しく説明します。

    7.2.2.4 Distribution

    Distribution は、複数の組織の間で品目のコスト負担を分割します。サプライヤは、バイヤーの支払照合処理を円滑にするために、請求書で Distribution 要素を返信します。

    Accounting

    Accounting 要素では、AccountingSegments をグループ化して請求先が識別されます。Accounting には次の属性があります。

    属性 説明
    name
    (必須)
    この会計の組み合せの名前。この請求の支払い元である会計情報。
    AccountingSegment

    AccountingSegment 要素には、バイヤー企業で使用される関連する会計コードを含めることができます。設定できる
    値の例として、資産番号、請求コード、コストセンタ、G/L 勘定科目、および部門があります。

    例:

    <AccountingSegment id="456">
     <Name xml:lang="en-US">G/L Account</Name>
     <Description xml:lang="en-US">Travel</Description>
    </AccountingSegment>
    

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

    属性 説明
    id
    (必須)
    この AccountingSegment タイプ内の一意の識別子です。タイプが「Cost Center」である場合、この値は実際の会計コードです。
    Name

    Accounting 要素内のその他のものに対する、この AccountingSegment の識別名です。

    Description

    会計エンティティの説明。

    Charge

    Accounting 要素によって表されるエンティティに請求される金額が指定されます。

    Money

    明細レベルの Charge の金額が含まれます。

    属性 説明
    currency
    (必須)
    ISO 規格による、一意の 3 文字の通貨コード。たとえば、「USD」は米国ドルです。alternateAmount alternateCurrency の金額です。任意で設定でき、ユーロのような二重通貨をサポートするために使用されます。
    alternateCurrency alternateAmount の通貨を指定します。ISO 4217 通貨コードに従う必要があります。
    7.2.2.5 TermsofDelivery

    出荷通知に対する配達条件が指定されます。「TermsOfDelivery」を参照してください。

    7.2.2.6 TravelDetail

    TravelDetail は SpendDetail の子であり、出張明細に関する情報が記述されます。次の例では、cXML.dtd からの TravelDetail の要素宣言を示しています。

    <!ELEMENT TravelDetail (
     (AirDetail | CarRentalDetail | HotelDetail | RailDetail),
     PolicyViolation*,
     Comments?,
     TermsAndConditions?)>
    

    次の例は、OrderRequest ドキュメント内の SpendDetail および TravelDetail の位置を示しています。

    <OrderRequest... >
     <OrderRequestHeader >
     ...
     </OrderRequestHeader >
     <ItemOut>
     <ItemDetail >
     ...
     </ItemDetail>
     <SpendDetail>
     <TravelDetail>
     ...
     </TravelDetail>
     </SpendDetail>
     </ItemOut>
    </OrderRequest>
    

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

    属性 説明
    confirmationNumber (必須) 出張者およびこの出張明細のサービスを提供するベンダによって理解される、一意の確認番号です。例えば、ホテル予約番号や航空会社の電子チケット番号です。
    pnrLocator 出張予約プロバイダが使用する、予約記録 (PNR) のロケータです。
    属性 説明
    quoteExpirationTime/td>

    この見積りの有効期限が切れる日時。通常、この値は PunchoutOrderMessage で提供されます。値が指定されていない場合、この見積りには有効期限がないものとみなされます。
    7.2.2.7 共通の TravelDetail 要素

    いくつかの共通要素が TravelDetail 全体で使用されます。

    cXML 内の日付および時刻

    cXML 内にある日付と時刻は、ISO 8601 で制限されたサブセットでフォーマットされなければなりません。この情報は、『Word Wide Web Consortium (W3C) Note』の「Date and Time Format」に記述されており、www.w3.org/TR/NOTE-datetime-970915.html で入手できます。詳細については、「日付、時刻およびその他のデータタイプ」を参照してください。

    Vendor

    共通の Vendor 要素です。TravelDetail で使用された場合、Vendor によってサービスベンダに関する情報が提供されます。Vendor は、AirLeg、CarRentalDetail、HotelDetail、および RailLeg で使用できます。Vendor には、以下の 1 つの属性があります。

    属性 説明
    preferred
    (必須)
    これは優先されるベンダですか?
    yes | no

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

    属性 説明
    Address ベンダの所在地が提供される基本的な Address 要素です。通常、これはベンダの企業所在地または本社の住所です。Address については、「cXML の規則」を参照してください。Address 要素には、addressID を付与する責任がある機関または組織を表すコードを指定するaddressIDDomain 属性が含まれます。たとえば、DUNS や ILN です。このコードは、addressID フィールドに値がある場合に必須です。Address には以下の要素が含まれます。

  • SupplierID

    このベンダの Supplier ID。これはドメインと値のペアです。出張予約プロバイダは DUNS やTaxID などの選択した規約に従って SupplierID 要素を定義できます。SupplierID には、1 つの必須の属性があります。

    属性 説明
    domain
    (必須)
    サプライヤ ID のドメイン

    各出張予約プロバイダは複数の Supplier ID 値を指定できます。この機能により、出張予約プロバイダは単一の実装を使用して、異なる SupplierID を使用したさまざまな企業実装を組み合わせることができます。

  • TermsAndConditions

    出張明細に関連した契約条件のテキスト形式の説明。たとえば、レンタカーの TermsAndConditions には、通常、利用範囲の制限、超過走行距離代金請求、ガソリン代金請求、およびその他の制約情報が含まれます。複数のTermsAndConditions を 1 つの出張明細に含めることができます。TermsAndConditions には以下の要素が含まれます。

    属性 説明
    Description 契約条件のテキスト形式の説明。TermsAndConditions が存在する場合、Description が必須です。
    PolicyViolation

    この特定の出張項目をユーザーが選択した結果生じる明細レベルの規定違反。どの明細に対する違反かを明確に識別するため、規定違反はヘッダーレベルでは関連付けられません。PolicyViolation には、以下の 1 つの属性があります。

    属性 説明
    level
    (必須)
    PolicyViolation のレベルは次のとおりです。warning | violation
    warning – 重要ではない違反
    violation – 企業ポリシーの重要な違反

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

    属性 説明
    Description Description は一般的なフリーテキスト要素です。PolicyViolation 要素などのテキスト形式による説明を提供します。
    PolicyViolationJustification この PolicyViolation の理由。通常、ユーザーは出張予約プロバイダのWeb サイトで一般的な違反の理由の一覧から 1 つのPolicyViolationJustification を選択します。
    Comments PolicyViolationJustification をさらに明確化するためのユーザーによる追加コメント。
    Penalty

    この出張セグメントの違約金 (存在する場合)。Penalty には以下の要素が含まれます。

    属性 説明
    Money 違約金の額。
    Description 違約金の理由に関するテキスト形式の説明。例えば、航空券に関する変更料金。
    AvailablePrice


    共通の AvailablePrice 要素では、ユーザーが選択しなかったほかの利用可能な価格が定義されます。AvailablePrice には、以下の 1 つの属性があります。

    属性 説明
    type
    (必須)
    企業ポリシーへの準拠レベルの説明。

    AvailablePrice の type 属性に指定できる値は、次のとおりです。

    属性 説明
    lowest 出張ポリシーに関係なく、利用可能な最低価格。
    lowestCompliant 出張ポリシーに準拠した、利用可能な最低価格。
    highestCompliant 出張ポリシーに準拠した、利用可能な最高価格。
    highest 出張ポリシーに関係なく、利用可能な最高価格。
    other その他 (Description で指定します)

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

    属性 説明
    Money 利用可能な価格の金額。
    Description 利用可能な価格のテキスト形式の説明。その価格の検索方法、またはその価格固有の必要条件などの情報を含みます。
    Rate

    出張項目の単価を定義します。次の例は、CarRentalFee の Rate 要素を示しています。

    <CarRentalFee type="baseRate">
     <Total>
     <Money currency="USD">215.99</Money>
     </Total>
     <Rate quantity="4">
     <Total>
     <Money currency="USD">119.96</Money>
     </Total>
     <UnitRate>
     <Money currency="USD">215.99</Money>
     <UnitOfMeasure>WEE</UnitOfMeasure>
     </UnitRate>
     </Rate>
    </CarRentalFee type="baseRate">
    

    Rate には、以下の 1 つの属性があります。

    説明
    属性
    quantity
    (必須)
    単価の数量。例えば、ホテルに 4 泊する場合は次のように表現されます。
    quantity = 4
    UnitRate の UnitofMeasure = DAY

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

    要素 説明
    Total 単価の合計金額。合計金額は quantity x UnitRate と一致する必要があります。明細におけるすべての Rate の金額は、明細の Total に計上される必要があります。
    UnitRate UnitRate では、数量単位に従って 1 つの単位の単価が定義されます。たとえば、ホテル一室の一泊分単価は、一泊単価額に等しい Money および DAY に等しい UnitOfMeausre で表現することができます。単位当たり (時間単位またはほかの数量単位) で支払われる金額。UnitRates が複数ある場合 (料金表の場合) は、TermReference 要素を使用してそれぞれを区別してください。
    Description 単価についてのテキスト形式の説明。ホテルの宿泊では、Description に ホテル一泊分の単価を含めることもできます。
    BookingClassCode

    BookingClassCode は共通の要素です。出張明細で使用されると、明細のクラスが示されます。たとえば、BookingClassCode は、一般に航空機での出張予約のためのマイレージサービス関連情報を通知するために使用されます。バイヤーと出張予約プロバイダの各ペアは、任意の業界標準を選択して使用できます。次の例は、最小限のBookingClassCode 要素を示しています。

    <BookingClassCode code="W">
     <Description xml:lang="en">Coach class</Description>
    </BookingClassCode>
    

    レンタカーコードの情報は、「CarRentalDetail」を参照してください。BookingClassCode には、次の属性があります。

    属性 説明
    domain
    (必須)
    このコードのドメイン、例えば IATA。
    code
    (必須)
    業界標準コード、またはバイヤーと出張予約プロバイダ間の契約によります。

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

    要素 説明
    Description Description コードのテキスト形式の説明が含まれます。
    Airport

    AirLegOrigin, AirLegDestination、CarRentalPickup, CarRentalDropoff、HotelDetail、RailLegOrigin 、および RailLegDestination では、共通の Airport 要素が使用されます。また、この要素には 3 文字の IATA 空港コードが含まれます。Airport には、以下の 1 つの属性があります。

    属性 説明
    airportCode
    (必須)
    3 文字の IATA 空港コード。 International Air Transport Association (IATA) 規格の情報については、www.iata.org/nr/rdonlyres/3346f400-3450-48a6-a543-86a3921c23f7/0/xml_fuel_transaction_v202.pdf を参照してください。

    Airport には、任意設定の以下の要素が含まれます。

    説明
    属性
    Address 空港の所在地を定義します。
    Meal

    AirLeg の Meal 要素では、BookingClassCode と Description の 2 つの任意設定の共通要素が定義されます。次の例では、AirLeg の菜食主義用の温かい夕食を示しています。

    <Meal>
     <Description xml:lang="en">vegetarian dinner</Description>
     <BookingClassCode code="H"></BookingClassCode>
    </Meal>
    

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

    属性 説明
    Description 食事のテキスト形式の説明。菜食主義用、無グルテン食、または乳製品を含まない食事など、必要な特別食の情報を指定します。
    BookingClassCode 共通の BookingClassCode 要素については、「BookingClassCode」を参照してください。食事コードを定義します。例えば、航空会社は通常、次の食事コードを使用します。

    コード 説明
    B 朝食
    C アルコール類の無料サービス
    D 夕食
    F 有料の食事
    G 有料の食事および飲み物
    H 温かい食事
    K 朝食 (コンチネンタル)
    L 昼食
    M 食事
    N 食事サービスなし
    O 加熱されない食事
    P 有料のアルコール類
    R 軽食
    S スナックまたはブランチ
    V 有料の軽食
    7.2.2.7.1 AirDetail

    AirDetail 要素は TravelDetail の子であり、飛行機による出張に関する情報を提供します。次の例では、cXML.dtd からの AirDetail の要素宣言を示しています。

    <!ELEMENT AirDetail (
     TripType,
     AirLeg+,
     AvailablePrice*,
     Penalty?)>
    

    AirDetail には属性がありません。

    TripType

    TripType には、type 属性が含まれます。この属性は、往復、片道、または複数区間の出張を示すために、AirDetail と RailDetail の両方で必須です。

    たとえば、往復出張の TripType は、次のように表示されます。

    <TripType type="round"></TripType>
    

    TripType 要素には以下の属性があります。

    属性 説明
    type
    (必須)
    round: 往復、oneWay: 片道、multiLeg: 複数区間または OPEN JAW の出張
    AirLeg

    各 AirDetail には、少なくとも 1 つの AirLeg 要素が含まれる必要があります。次の例では、cXML.dtd からの AirLeg の要素宣言を示しています。

    <!ELEMENT AirLeg (
     Vendor,
     AirLegOrigin,
     AirLegDestination,
     BookingClassCode?,
     Rate?,
     Meal*)>
    

    AirLeg 要素では、航空便が 1 つ以上含まれる出張の詳細情報が定義されます。次の例は、片道の航空便を含む AirLeg 要素を示しています。

    <AirLeg travelSegment="1" departureTime="2004-12-01T16:10:00-08:00" arrivalTime="2004-12-01T17:10:00-08:00" flightNumber="SW 990" seatNumber="20F" seatType="aisle" stops="0" equipment="Boeing 737">
     <Vendor preferred="no">
     <Address>
     ...
     </Address>
     </Vendor>
     <AirLegOrigin>
     <Airport airportCode="SFO">
     <Address>
     ...
     </Address>
     </Airport>
     </AirLegOrigin>
     <AirLegDestination>
     <Airport airportCode="BUR">
     <Address>
     ...
     </Address>
     </Airport>
     </AirLegDestination>
     <BookingClassCode code="W">
     <Description xml:lang="en">Coach class</Description>
     </BookingClassCode>
     <Meal type="snack">
     <Description xml:lang="en">Vegetarian snack</Description>
     </Meal>
    </AirLeg>
    

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

    属性 説明
    travelSegment
    (必須)
    この出張セグメントを識別するテキスト形式の説明。これは出張予約プロバイダに固有の情報です。
    departureTime
    (必須)
    この航空便の現地出発日および出発時間。
    arrivalTime
    (必須)
    この航空便の現地到着日および到着時間。
    flightNumber
    (必須)
    この航空便の便名。
    seatNumber この航空便の座席番号。
    seatType 座席のタイプ。
    window、aisle、または middle
    upgrade これはアップグレードされた航空券かどうか。
    no (通常の設定) または yes
    stops この航空便の経由地の数。経由地の数、または直行便には「0」 (ゼロ) を使用します。数字が指定されていない場合、「0」 (ゼロ) とみなされます。
    equipment この航空便の飛行機に関する情報。例えば、使用される機種。

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

    属性 説明
    Vendor 共通の Vendor 要素。サービスベンダに関する情報を提供します。「Vendor」を参照してください。
    AirLegOrigin | AirLegDestination これらの要素には、AirLeg の AirLegOrigin と AirLegDestination エンティティのアドレスが含まれます。AirLegOrigin および AirLegDestination には、以下の子要素が含まれます。

  • Airport
      共通の Airport 要素については、「Airport」を参照してください。この要素には、 3 文字の IATA 空港コードを示す airportCode 属性と、任意設定の Address 要素が含まれます。International Air Transport Association (IATA) 規格の情報については、www.iata.org/codesを参照してください。次の例では、サンフランシスコからマイアミへの航空便の詳細な AirLeg が示されています。

      <AirLegOrigin>
       <Airport airportCode="SFO">
       <Address>
       <Name xml:lang="en">San Francisco Internal Airport</Name>
       <PostalAddress>
       <Street>San Francisco International Airport</Street>
       <City>San Francisco</City>
       <State isoStateCode="US-CA">CA</State>
       <PostalCode>94128</PostalCode>
       <Country isoCountryCode="US">United States</Country>
       </PostalAddress>
       </Address>
       </Airport>
      </AirLegOrigin>
      <AirLegDestination>
       <Airport airportCode="MIA">
       <Address>
       <Name xml:lang="en">Miami International Airport</Name>
       <PostalAddress>
       <Street>4200 NW 21 Street>
       <City>Miami</City>
       <State isoStateCode="US-FL">FL</State>
       <PostalCode>33122</PostalCode>
       <Country isoCountryCode="US">United States</Country>
       </PostalAddress>
       </Address>
       </Airport>
      </AirLegDestination>
      
  • BookingClassCode
      共通の BookingClassCode 要素については、「BookingClassCode」を参照してください。AirLeg の BookingClassCode 要素では、 AirLeg の出張クラスが事実上の航空会社規格に従って定義されます。次の表に、IATA コードの例を示します。

      IATA コード 説明
      F, FN, P, R, A ファーストクラス
      C, CN, D, J, I, Z ビジネスクラス
      Y, YN, B, BN, M, H, V, VN, O, Q, QN, S, K, KN, L, U, T, W エコノミークラス

      コード例が正確であること、および最新であることは保証しません。International Air Transport Association (IATA) 規格の情報については、www.iata.org/codes を参照してください。BookingClassCode には以下の要素が含まれます。

    • Rate
      共通の Rate 要素については、「Rate」を参照してください。指定されたすべての AirLeg 単価の合計は、明細合計と等しい必要があります。

    • Meal
      出張明細で 1 回の食事を記述する共通の Meal 要素は、「Meal」で定義されています。
  • AvailablePrice

    ユーザーが選択しなかった指定可能な価格を定義する任意設定で共通の AvailablePrice 要素は、「AvailablePrice」で定義されています。AirDetail の AvailablePrice 要素では、単一区間、複数区間、または往復区間で利用可能な価格を定義します。

    Penalty

    共通の Penalty 要素。出張明細へのユーザーによる変更に対するベンダの追加請求を定義します。「Penalty」を参照してください。AirLeg の Penalty 要素では、航空便の予約変更、またはキャンセルに対する追加請求が定義されます。

    7.2.2.7.2 CarRentalDetail

    CarRentalDetail は TravelDetail の子であり、単一のレンタカーイベントに関する情報を提供します。
    次の例では、cXML.dtd からの CarRentalDetail の要素宣言を示しています。

    <!ELEMENT CarRentalDetail (
     Vendor,
     CarRentalPickup,
     CarRentalDropoff,
     BookingClassCode?,
     CarRentalFee+,
     LimitedMileage?,
     AvailablePrice*)>
    

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

    属性 説明
    travelSegment
    (必須)
    この出張セグメントの識別に使用されるテキスト形式の説明。これは出張予約プロバイダに固有の説明です。
    pickupTime
    (必須)
    予定する現地での出発日時。
    dropoffTime
    (必須)
    予定する現地での返却日時。
    Vendor

    共通の Vendor 要素。サービスベンダに関する情報を提供します。「Vendor」を参照してください。

    CDrRentDlPickup/CDrRentDlDropoff

    これらの要素には、CarRentalDetail の CarRentalPickup と CarRentalDropoff エンティティのアドレスが含まれます。CarRentalPickup と CarRentalDropoff の両方で、空港所在地を指定する共通の Airport 要素が必須です。

    BookingClassCode

    レンタカーのクラスを示す 4 文字のコード。バイヤーと出張予約プロバイダは、規格を選択して使用できます。例えば、一般的なレンタカーの米国規格は次のとおりです。

    文字の位置 意味
    1 文字目 M (ミニ)
    E (エコノミー)
    C (小型)
    S (標準)
    I (中型)
    F (大型)
    P (プレミアム)
    L (高級車)
    V (ミニバン)
    X (特別)
    2 文字目 B (2 ドア)
    C (2/4 ドア)
    D (4 ドア)
    T (オープンカー)
    F (四輪駆動)
    V (バン)
    W (ワゴン)
    S (スポーツ)
    X (特別)
    3 文字目 A (オートマチック)
    M (マニュアル)
    4 文字目 R (A/C)
    N (非 A/C)
    CarRentalFee

    CarRentalFee では、このレンタカーに適用される実際の請求と費用が定義されます。さまざまな費用の内訳を取得するには、1 つの CarRentalDetail 要素内で複数の CarRentalFee 要素を使用します。これらの費用の合計は、明細レベルで合計に計上される必要があります。

    注記
    走行距離制限を超過している追加走行距離などの項目に対する条件付の請求を指定するには、 TermsAndConditions テキストを使用します。CarRentalFee には、以下の 1 つの属性があります。

    属性 説明
    type 「baseRate」形式で表現された費用のタイプです。

    CarRentalFee の type に指定できる値は、次のとおりです。

    説明
    additionalDriver 追加運転者費用
    airportAccessFee 空港アクセス費用
    baseRate 基本レンタル費用
    childSeat チャイルドシート料金
    collisionDamageInsurance 車両損害補償保険
    dropOffCharge 乗り捨て料金
    liabilityInsurance 損害賠償保険
    luggageRack 携行品保険料金
    mobilePhone 携帯電話基本料金
    navigationSystem ナビゲーションシステム
    other その他の請求
    prepaidGasoline 燃料先払い料金
    touristTax 旅行者税
    vehicleLicensingFee 車両登録費

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

    要素 説明
    Total この CarRentalFee の合計金額です。明細におけるすべての Rate の金額は、明細の Total に計上される必要があります。
    Rate この CarRentalFee に対する各請求の費用情報です。

    LimitedMileage

    LimitedMileage では、走行距離制限の距離数と数量単位が指定されます。 LimitedMileage には、以下の 1 つの属性があります。

    属性 説明
    quantity
    (必須)
    数値で表された走行距離制限の距離数。

    LimitedMileage には、1 つの要素が含まれます。

    要素 説明
    UnitOfMeasure 数量単位。マイルまたはキロ。「UnitOfMeasure」を参照してください。
    AvailablePrice

    任意設定で共通の AvailablePrice 要素。ユーザーが選択しなかった利用可能な価格を定義します。
    AvailablePrice 」を参照してください。

    7.2.2.7.3 HotelDetail

    HotelDetail は TravelDetail の子です。次の例では、cXML.dtd からの HotelDetail の要素宣言を示しています。

    <!ELEMENT HotelDetail (
     Vendor,
     Address,
     RoomType,
     BookingClassCode?,
     Meal*,
     Rate*,
     AvailablePrice*)>
    

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

    属性 説明
    travelSegment
    (必須)
    この出張セグメントを識別するテキスト形式の情報。これは出張予約プロバイダに固有の情報です。
    arrivalTime
    (必須)
    ホテル到着の現地での日時。これはホテルベンダへの到着日時の報告として使用されます。
    departureTime
    (必須)
    ホテル出発の現地での日時。これはホテルベンダへの出発日時の報告として使用されます。
    checkinTime
    (必須)
    ホテルの規定チェックイン現地時間。
    checkoutTime
    (必須)
    ホテルの規定チェックアウト現地時間。
    earlyCheckinAllowed ホテルでは規定時間前のチェックインが可能ですか?
    no または yes (default)
    lateCheckoutAllowed ホテルでは規定時間後のチェックアウトが可能ですか?
    no または yes (default)
    Vendor

    共通の Vendor 要素。サービスベンダに関する情報を提供します。「Vendor」を参照してください。HotelDetail, では、Vendor 要素でホテル業者が定義されます。

    Address

    ホテルの所在地。Vendor フィールドで指定した住所と異なる可能性があります。たとえば、Vendor 内の Address は、ホテル本社の住所である可能性がありますが、HotelDetail 内の Address は個々のホテルの住所です。

    RoomType

    予約されたホテルの客室タイプについての情報。RoomType には次の属性があります。

    属性 説明
    smoking
    (必須)
    喫煙または禁煙の客室:
    yes | no
    numberOfBed 客室内のベッド数。
    bedType 客室内のベッドのタイプ。
    king | queen | full | double | single | other

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

    要素 説明
    Description ホテル客室のテキスト形式の説明。
    Amenities 設備のテキスト形式の説明。例えば、DSL 接続、2 本の電話回線、およびホテル客室に関するその他の情報。Amenities には属性がありません。1 つの要素があります。

  • Description
      設備のテキスト形式の説明。例えば、DSL 接続、2 本の電話回線、およびホテル客室に関するその他の情報。

  • BookingClassCode

    共通の BookingClassCode 要素については、「BookingClassCode」を参照してください。バイヤーと出張予約プロバイダはペアで、規格を選択し使用できます。

    Meal

    共通の Meal 要素については、「Meal」を参照してください。HotelDetail の Meal 要素では、コンチネンタル式朝食などの客室料金に含まれる無料の食事が定義されます。

    Rate

    共通の Rate 要素については、「Rate」を参照してください。HotelDetail の Rate 要素では、ホテル宿泊に関する 1 つ以上の単価が定義されます。例えば、一泊の単価や係員付き駐車サービスの単価などです。

    AvailablePrice

    共通の AvailablePrice 要素については、「AvailablePrice」を参照してください。HotelDetail の
    AvailablePrice 要素では、ユーザーが選択しなかったその他の利用可能な価格が定義されます。同じベンダまたは
    ほかのベンダで利用可能な価格です。

    7.2.2.7.4 RailDetail

    次の例では、cXML.dtd からの RailDetail の要素宣言を示しています。

    <!ELEMENT RailDetail (
     TripType,
     RailLeg+,
     AvailablePrice*,
     Penalty?)>
    

    RailDetail には属性がありません。

    TripType

    TripType は、type 属性のコンテナであり、AirDetail と RailDetail の両方で必須です。TripType 要素では、往復、片道、または複数区間の出張が定義されます。たとえば、往復出張の TripType は、次のように表示されます。

    <TripType type="round"></TripType>
    

    TripType の type 属性に指定できる値は、次のとおりです。

    説明
    round 往復
    oneWay 片道
    multiLeg 複数区間または OPEN JAW
    RailLeg

    この RailDetail を構成する 1 つ以上の RailLeg 要素です。各 RailDetail には、少なくとも RailLeg が 1 つ含まれる必要があります。次の例は、DTD からの RailLeg の要素宣言を示しています。

    <!ELEMENT RailLeg (
     Vendor,
     RailLegOrigin,
    RailLegDestination,
     BookingClassCode?,
     Rate?,
     Meal*)>
    

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

    属性 説明
    travelSegment
    (必須)
    この出張セグメントを識別するテキスト形式の情報。これは出張予約プロバイダに固有の情報です。
    departureTime
    (必須)
    始発地点からの現地での出発日時。
    arrivalTime
    (必須)
    終着地点への現地での到着日時。
    trainNumber
    (必須)
    列車番号。
    seatNumber 座席番号。
    carType 客車のタイプ。
    Vendor

    共通の Vendor 要素。サービスベンダに関する情報を提供します。「Vendor」を参照してください。RailLeg では、Vendor 要素で Amtrak などの鉄道旅客業者が定義されます。

    RailLegOrigin/RailLegDestination

    RailLegOrigin および RailLegDestination では 2 つの要素を定義できますが、どちらか 1 つは必ず定義する必要があります。

    要素 説明
    Airport 共通の Airport 要素については、「Airport」を参照してください。この要素には、3 文字の IATA 空港コードを示す airportCode 属性と、任意設定の Address 要素が含まれます。International Air Transport Association (IATA) 規格の情報については、www.iata.org/codes を参照してください。
    Address 駅の所在地。

    RailLegOrigin と RailLegDestination はどちらも属性がありません。

    BookingClassCode

    共通の BookingClassCode 要素については、「BookingClassCode」を参照してください。RailLeg 要素の BookingClassCode 要素では、バイヤーと出張予約プロバイダのペアによって合意された鉄道規格に従って、RailLeg の出張クラスが定義されます。

    Rate

    共通の Rate 要素については、「Rate」を参照してください。この鉄道区間の単価情報です。指定される場合、全鉄道区間でのすべての単価が、出張明細レベルで合計に計上される必要があります。

    Meal

    共通の Meal 要素については、「Meal」を参照してください。HotelDetail の Meal 要素では、コンチネンタル式朝食などの客室料金に含まれる無料の食事が定義されます。

    AvailablePrice

    共通の AvailablePrice 要素については、「AvailablePrice」を参照してください。RailDetail の AvailablePrice 要素では、ユーザーが選択しなかったその他の利用可能な価格が定義されます。同じベンダまたはほかのベンダで利用可能な価格です。

    Penalty

    共通の Penalty 要素。出張明細へのユーザーによる変更に対するベンダの追加請求を定義します。「Penalty」を参照してください。RailLeg の Penalty 要素では、列車の予約変更、またはキャンセルに対する追加請求が定義されます。

    7.2.2.8 許容範囲

    これは任意設定の要素であり、バイヤーは個別注文書またはオーダー管理システムから送信する注文書のさまざまな明細に、明細の数量許容範囲を指定できます。注文書に指定された許容範囲は、サプライヤが出荷通知および請求書をその注文書に対して作成するときに適用されます。

    QuantityTolerance

    明細の数量許容範囲。この要素には以下の要素が含まれます。

    要素 説明
    Percentage 数量許容範囲の率。
    Value 数量許容範囲の数量を表す数字。
    QuantityTolerance 要素でこれらの要素のいずれかを指定できます。
    PriceTolerance

    明細の価格許容範囲。この要素には以下の要素が含まれます。

    要素 説明
    Percentage 価格許容範囲の率。
    Money 価格許容範囲の金額および通貨。
    PriceTolerance 要素で、これらの要素のいずれかを指定できます。
    TimeTolerance

    明細の時間許容範囲。具体的な配達日が依頼された配達日に関する許容範囲内であるかどうかをチェックするために使用される特定の時間数が定義されます。TimeTolerance には次の属性があります。

    属性 説明
    limit
    (必須)
    時間許容範囲を指定します。
    type 時間制限の種類を指定します。使用可能な値は、次のとおりです。

  • minutes
  • hours
  • days (通常設定)
  • weeks
  • 7.2.2.9 ControlKeys

    オーダー確認、出荷通知、サービスシート、および請求書に対する通常のビジネスルールを上書きできる要素が提供されます。「ControlKeys」を参照してください。以下は、ItemOut 要素で使用される ControlKeys 要素の例です。

    <ItemOut lineNumber="1" quantity="2" requestedDeliveryDate="2015-12-31">
     ...
     <ControlKeys>
     <InvoiceInstruction value="notAllowed"/>
     <SESInstruction value="notAllowed"/>
     </ControlKeys>
    </ItemOut>
    
    7.2.2.10 ScheduleLine

    ScheduleLine には、明細の納入日程に関する情報が含まれます。この要素には、次の属性があります。

    属性 説明
    quantity
    (必須)
    出荷される品目の数量。
    requestedDeliveryDate
    (必須)
    指定数量の納入予定日。
    deliveryWindow 数量の納入予定期間。
    lineNumber 特定の納入日程行の明細識別子として明細番号を追加できます。
    requestedShipmentDate 品目のバイヤーが依頼した出荷日。
    originalRequestedDeliveryDate 指定数量の元の納入予定日。この日付は変更対象ではありません。

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

    UnitOfMeasure

    明細の指定数量の The UnitOfMeasure です。

    ScheduleLineReleaseInfo

    ScheduleLineReleaseInfo 要素には、納入日程行に対する品目または商品の特定のリリースについての詳細が格納されます。ScheduleLineReleaseInfo には、次の属性があります。

    属性 説明
    commitmentCode
    (必須)
    出荷の種類を特定する文字列値。使用可能な値は次のとおりです。

  • firm – 製造開始。ベンダは納入日程行に基づいて出荷できます。顧客は製造コストと品目購買コストに責任を持ちます。
  • tradeoff – 投入品目購買開始。ルールが有効である場合には、ベンダは納入日程行に基づいて出荷できます。バイヤーは品目調達コストに責任を持ちます。
  • forecast – 情報。顧客は、ベンダに対する法的責任を負うことなく、納入日程行を変更できます。
  • cumulativeScheduledQuantity
    (必須)
    納入日程行に基づいて出荷される特定明細の合計数量。
    receivedQuantity 外部システム (ERP など) に送信された入庫に基づいて、オーダーまたは分納契約明細の納入日程行に対して受け取った数量です。この数量は情報目的のみで、サプライヤへの表示として使用されます。請求書または出荷処理の検証は行われません。
    SubcontractingComponent

    完成品の製造に使用される外注構成品目に関する詳細情報が含まれます。たとえば、ID、説明、バイヤーの製品 ID、数量、または必要な日付が含まれます。SubcontractingComponent には次の属性があります。

    属性 説明
    quantity
    (必須)
    数量単位で完成品を製造するために必要な外注構成品目の数量です。requirementDate 依頼された数量の外注構成品目が必要になる日付です。
    materialProvisionIndicator 構成品目の一部の外注構成種類を識別するために使用される品目提供区分です。使用可能な値は、次のとおりです。

  • reworkTo – 下請業者への品目の再作業です。
  • reworkFrom – 下請業者からの品目の再作業です。
  • regular – ベンダが在庫を提供します。
  • SubcontractingComponent には以下の要素が含まれます。

    要素 説明
    ComponentID 購買プロセス内の外注構成品目を表す識別子です。
    UnitOfMeasure 数量単位コードです。
    Description 外注構成品目の説明です。
    Product 外注構成品目に関する情報 (バイヤー製品 ID、サプライヤ製品 ID、標準製品 ID、内部製品 ID など) です。
    ProductRevisionID 構成品目の変更が行われると割り当てられる識別子です。
    Batch 1 回の生産実行で生産される品目または商品に関するバッチ情報 (バイヤー/サプライヤのバッチ ID、製造日、プロパティ評価など) を含む要素です。
    ShipTo

    明細の出荷先住所。

    Extrinsic

    また、Extrinsic 要素リストを使用して ScheduleLine 要素に関する追加データを挿入します。

    7.2.2.11 ItemOutIndustry

    この要素には、業種固有の情報が含まれます。これは任意設定の要素であり、以下の任意設定の属性が含まれます。

    属性 説明
    planningType 計画方針を指定します。使用可能な値は次のとおりです。
    ● MTO – 受注生産
    ● MTS – 見込み生産
    ● ATO – 受注組み立て
    ● CTO – 受注設定
    requiresRealTimeConsumption この品目にリアルタイム消費が必要な場合は yes に設定します。
    isHUMandatory この品目に荷役単位が必要な場合は yes に設定します。荷役単位は、梱包材 (積載装置/梱包材料) と梱包または積載される商品で構成される物理的な単位です。

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

    要素 説明
    ItemOutRetail 小売業品目固有の情報が含まれます。この要素は任意設定です。ItemOutRetail には以下の要素が含まれます。
    ● PromotionVariantID
    商品の 1 つまたはいくつかのバリアントのみが推奨される場合に、特定の ID が指定されます。製品バリアントは、製品の特性 (色や形状など) を指定する特定のコードです。この要素は任意設定です。
    ● PromotionalDealID
    販売促進活動に関連するサプライヤによって割り当てられる ID が指定されます。販売促進は将来の計画やオーダープロセス (および関連価格) に影響します。この要素は任意設定です。
    ReferenceDocumentInfo 参照されるドキュメントに関する情報が含まれます。この要素は任意設定であり、複数回発生する可能性があります。「ReferenceDocumentInfo」を参照してください。
    Priority サプライヤのオーダーの優先度を示します。この要素は任意設定です。優先度を示す Description 要素が含まれます。Priority には次の属性があります。

    属性 説明
    level
    (必須)
    優先度レベル (1 ~ 5 の整数) を指定します。
    sequence 優先度レベルが同じ品目に優先度を付けるための 2 つ目の一意のオーダー番号です。優先度レベルが同じ 2 つの
    品目に、同じ順序番号を持たせることはできません。
    inventory_level ターゲットに関する在庫 (バッファ) レベル (%) が表示されます。これは、0.00 から 100.00 までの小数値として指定されます。
    QualityInfo 明細に対する品質情報の要件を表します。「<a href="http://QualityInfo」を参照してください。
    SerialNumberInfo 明細のシリアル番号情報を表します。「<a href="http://SerialNumberInfo」を参照してください。
    BatchInfo サプライヤがオーダー応答を作成するときに品目にバッチ情報が必要かどうかを制御します。「<a href="http://BatchInfo」を参照してください。
    AssetInfo 明細の単位あたりの詳細な資産情報を提供します。「AssetInfo」を参照してください。
    PackagingDistribution 店舗間のパッケージ分割に関する情報が含まれます。「<a href="http://“>PackagingDistribution」を参照してください。

    次の例では、ItemOutIndustry 要素を示します。

    <ItemOutIndustry planningType="MTO" requiresRealTimeConsumption="yes" isHUMandatory="yes">
     <QualityInfo requiresQualityProcess="yes">
     <IdReference identifier="001" domain="controlCode">
     <Description xml:lang="en-US">Control Code description</Description>
     </IdReference>
     <IdReference identifier="CERT123" domain="certificateType">
     <Description xml:lang="en-US">Certificate Type description</Description>
     </IdReference>
     </QualityInfo>
     <SerialNumberInfo requiresSerialNumber="yes" type="list">
     <SerialNumber>3482918</SerialNumber>
     <SerialNumber>3123333</SerialNumber>
     <SerialNumber>5423325</SerialNumber>
     </SerialNumberInfo>
     <AssetInfo isReferencedAsset="no" equipmentId="SU234234234" location="Sunnyvale" serialNumber="SER12345" tagNumber="TAG67890">
     </AssetInfo>
     <PackagingDistribution quantity="25.00">
     <StoreCode>Store A</StoreCode>
     <UnitOfMeasure>EA</UnitOfMeasure>
     </PackagingDistribution>
     <PackagingDistribution quantity="25.00">
     <StoreCode>Store B</StoreCode>
     <UnitOfMeasure>EA</UnitOfMeasure>
     </PackagingDistribution>
    </ItemOutIndustry>
    
    7.2.2.11.1 QualityInfo

    QualityInfo 要素は、明細に対する品質情報の要件を表します。QualityInfo には次の属性があります。

    属性 説明
    requiresQualityProcess yes に設定すると、この品目で品質プロセスが必要であることが示されます。

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

    要素 説明
    IdReference | CertificateInfo IdReference には、明細に関する品質品目管理コードおよび検査証明書の種類に関する情報が含まれます。品質品目管理コードの場合、domain は “controlCode” です。検査証明書の種類の場合、domain は “certificateType” です。CertificateInfo を使用して、証明書情報を送信します。ここでは、証明書を任意または必須として宣言することができます。各要素では 1 つの証明書がサポートされます。

    次の例は、IdReference を使用した QualityInfo 要素を示しています。

    <ItemOutIndustry>
     <QualityInfo requiresQualityProcess="yes">
     <IdReference identifier="001" domain="controlCode">
     <Description xml:lang="en-US">Control Code description</Description>
    </IdReference>
     <IdReference identifier="CERT123" domain="certificateType">
     <Description xml:lang="en-US">Certificate Type description</Description>
     </IdReference>
     </QualityInfo>
    </ItemOutIndustry>
    

    次に示すのは、1 つの必須の証明書と 1 つの任意の証明書が含まれる QualityInfo 要素を示すもう 1 つの例です。

    <QualityInfo requiresQualityProcess="yes">
     <!-- Mandatory certificate -->
     <CertificateInfo isRequired="yes">
     <IdReference domain="certificateType" identifier="CERT123">
     <Description xml:lang="en-US">Certificate Type description CERT123</Description>
     </IdReference>
     </CertificateInfo>
     <!-- Optional certificate -->
     <CertificateInfo>
     <IdReference domain="certificateType" identifier="CERT456">
     <Description xml:lang="en-US">Certificate Type description CERT456</Description>
     </IdReference>
     </CertificateInfo>
    </QualityInfo>
    
    7.2.2.11.1.1 CertificDteInfo

    CertificateInfo 要素は、証明書情報を表します。この要素には、次の属性があります。

    属性 説明
    isRequired 証明書が必須かどうかを示します。

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

    要素 説明
    IdReference この要素を使用して、品質品目管理コードおよび検査証明書の種類に関する情報を送信します。
    品質品目管理コードの場合、domain は「controlCode」です。
    検査証明書の種類の場合、domain は「certificDteT\pe」です。
    7.2.2.11.2 SerialNumberInfo

    明細のシリアル番号情報を表します。SerialNumberInfo には次の属性があります。

    属性 説明
    requiresSerialNumber 対応する出荷通知の ShipNoticeItem 要素の AssetInfo タグで、サプライヤがこの品目にシリアル番号を指定する必要があるかどうかを示します。
    type シリアル番号の種類を指定します。使用可能な値は次のとおりです。
    ● list – 指定可能なシリアル番号のリストです。
    ● range – 指定可能なシリアル番号の範囲です (数値範囲でのみ有効)。
    ● profile – 指定可能なシリアル番号の形式です。

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

    要素 説明
    SerialNumber シリアル番号のリストです。SerialNumberInfo@type が “list” の場合に必須です。
    PropertyValue SerialNumberInfo@type が “range” の場合は、PropertyValue 要素で指定可能な最小および最大の限度値を指定する必要があります。この場合は、PropertyValue@name を “range” にする必要があり、PropertyValue@Characteristic の Characteristic@value 属性に最小値と最大値を指定し、Characteristic@domain 属性に “minimum” および”maximum” ドメインを指定する必要があります。
    SerialNumberInfo@type が “profile” の場合は、PropertyValue 要素にシリアル番号の形式を指定する必要があります。この場合は、PropertyValue@name を”profile” にする必要があり、PropertyValue@Characteristic で形式を指定する必要があります。Characteristic@domain では、これらの値をCharacteristic@value で指定するために、ドメインとして”type”、”minLength”、および “maxLength” がサポートされています。Characteristic@domain が “type” の場合は、シリアル番号の形式を指定するために、Characteristic@valueで”numeric”、”text”、および”numericAndText” がサポートされています。Characteristic@domain が “minLength” の場合は、 Characteristic@value で指定可能なシリアル番号の最小の長さが指定されます。Characteristic@domain が “maxLength” の場合は、Characteristic@value で指定可能なシリアル番号の最大の長さが指定されます。

    次の例は、シリアル番号をリストで指定した場合を示しています。

    <SerialNumberInfo requiresSerialNumber="yes" type="list">
     <SerialNumber>3482918</SerialNumber>
     <SerialNumber>3123333</SerialNumber>
     <SerialNumber>5423325</SerialNumber>
    </SerialNumberInfo>
    

    次の例は、シリアル番号を範囲 (100,000 ~ 200,000) で指定した場合を示しています。

    <SerialNumberInfo requiresSerialNumber="yes" type="range">
     <PropertyValue name="range">
     <Characteristic domain = "minimum" value="100000"/>
     <Characteristic domain = "maximum" value="200000"/>
     </PropertyValue>
    </SerialNumberInfo>
    

    次の例は、シリアル番号をプロファイル (3 ~ 10 桁の数字) で指定した場合を示しています。

    <SerialNumberInfo requiresSerialNumber="yes" type="profile">
     <PropertyValue name="profile">
     <Characteristic domain = "type" value="numeric"/>
     <Characteristic domain = "minLength" value="3"/>
     <Characteristic domain = "maxLength" value="10"/>
     </PropertyValue>
    </SerialNumberInfo>
    

    7.2.2.11.3 BatchInfo

    サプライヤがオーダー応答を作成するときに品目にバッチ情報が必要かどうかを制御します。この要素には、次の属性があります。

    属性 説明
    requiresBatch yes に設定すると、この品目は、対応する ShipNoticeRequest/ConfirmationRequest ドキュメントのShipNoticeItem/ConfirmationStatus 要素における Batch 要素にサプライヤによってバッチ番号が入力される必要があることを示します。
    7.2.2.11.4 PackagingDistribution

    店舗間のパッケージ分割に関する情報が含まれます。次の任意設定の属性があります。

    属性 説明
    quantity
    (必須)
    このパッケージ分割情報の数量です。UnitOfMeasure 要素で指定した単位で示されます。

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

    要素 説明
    StoreCode
    (必須)
    このパッケージ分割情報に割り当てられた店舗のコードです。
    UnitOfMeasure
    (必須)
    数量の数量単位。数量単位の共通コードである UN/CEFACT に準拠している必要があります。

    次の例は、PackagingDistribution 要素を示しています。

    <ItemOutIndustry>
     <PackagingDistribution quantity="25.00">
     <StoreCode>Store A</StoreCode>
     <UnitOfMeasure>EA</UnitOfMeasure>
     </PackagingDistribution>
     <PackagingDistribution quantity="25.00">
     <StoreCode>Store B</StoreCode>
     <UnitOfMeasure>EA</UnitOfMeasure>
     </PackagingDistribution>
    </ItemOutIndustry>
    
    7.2.2.11.4.1 StoreCode

    品目のパッケージに割り当てられた店舗のコードが含まれます。複数の店舗間でパッケージが分割される場合、複数の店舗コードがその分割で指定されます。

    7.2.2.12 Packaging

    明細のパッケージに関する詳細が指定されます。Packaging には以下の要素が含まれます。

    要素 説明
    (PackagingCode、Dimension)| Dimension
    (必須)
    PackagingCode では、パッケージ材料 (ボックス、コンテナ、パレット、棚) の一意の ID を指定します。「PackagingCode」を参照してください。
    Dimension では、品目のパッケージについて単一の寸法/数量を指定します。「Dimension」を参照してください。
    Description パッケージの説明を提供します。
    PackagingLevelCode パッケージのレベル (inner、outer、intermediate など) を指定します。これにより、パッケージ階層内のパッケージレベルが評価され、それに応じて積み卸しと保管を計画するためにバイヤー側にとって重要です。
    PackageTypeCodeIdentifierCode パッケージ材料 (ボックス、コンテナ、パレット、棚) の一意の ID を指定します。このフィールドによって、パッケージの種類が記述されます。このフィールドは、荷卸しおよび保管の際、受け取り人 (バイヤー) に関連します。多くの場合、パッケージの種類によって、最大積載重量または商品の重量も定義されます。
    ShippingContainerSerialCode 輸送中および棚卸中にパッケージを識別する際に役立つパッケージのシリアル番号です。
    ShippingContainerSerialCodeReference パッケージの出荷コードから次に高いパッケージレベルの出荷コードへの参照が含まれます。
    PackageID パッケージ関連の ID が含まれます。「PackageID」を参照してください。
    ShippingMark 荷印を指定します。多くの場合、このフィールドは、パッケージ提案とパッケージ階層が物流バックエンドシステムから取得される業種で使用されます。一般に、このフィールドは特別な署名や取扱説明書を指定するために使用されます。
    OrderedQuantity 注文書の特定の明細に対して品目/製品の数を指定します。「OrderedQuantity」を参照してください。
    DispatchQuantity (オーダー済み数量と比較した) 配達済み数量を指定します。「DispatchQuantity」を参照してください。
    FreeGoodsQuantity バイヤーへのコストなしで配達される数量を指定します。「FreeGoodsQuantity」を参照してください。
    QuantityVarianceNote 部分配達に関する詳細情報を指定します。この要素を使用すると、さまざまな度量衡を含む明細を指定できます。例: 1 ロット = 500 個。
    BestBeforeDate 品目/商品の品質が落ち始める日付を指定します。これを使用すると、食料品、薬品、化学薬品などに関連するすべての商品の賞味期限を示すことができます。この要素には、必須の date属性が含まれます。
    AssetInfo パッケージによって参照される資産の情報が含まれます。「AssetInfo」を参照してください。
    StoreCode このパッケージに割り当てられた店舗のコードです。
    Extrinsic この Packaging 要素に関連するすべての追加情報が含まれます。

    以下に Packaging の例を示します。

    <Packaging>
     <PackagingCode xml:lang="eu-US"/>
     <Dimension quantity="5.35" type="length">
     <UnitOfMeasure>in</UnitOfMeasure>
     </Dimension>
     <Dimension quantity="5.35" type="height">
     <UnitOfMeasure>in</UnitOfMeasure>
     </Dimension>
     <Dimension quantity="3.35" type="width">
     <UnitOfMeasure>in</UnitOfMeasure>
     </Dimension>
     <Dimension quantity="20.0" type="volume">
     <UnitOfMeasure>mm</UnitOfMeasure>
     </Dimension>
     <Dimension quantity="35.35" type="grossWeight">
     <UnitOfMeasure>kg</UnitOfMeasure>
     </Dimension>
     <Dimension quantity="40.35" type="unitNetWeight">
     <UnitOfMeasure>kg</UnitOfMeasure>
     </Dimension>
     <Description type="Package" xml:lang="eu-US">Pallet Desc2</Description>
     <PackagingLevelCode>1</PackagingLevelCode>
     <PackageTypeCodeIdentifierCode>Pallet2
     </PackageTypeCodeIdentifierCode>
     <ShippingContainerSerialCode>HU0000000097ASN
     </ShippingContainerSerialCode>
     <PackageID/>
     <OrderedQuantity quantity="27.0">
     <UnitOfMeasure>CT</UnitOfMeasure>
     </OrderedQuantity>
     <DispatchQuantity quantity="1.0">
     <UnitOfMeasure>CT</UnitOfMeasure>
     </DispatchQuantity>
     <AssetInfo tagNumber="asset1" serialNumber="0000001"/>
     <AssetInfo tagNumber="asset2" serialNumber="0000002"/>
     <AssetInfo tagNumber="asset3" serialNumber="0000003"/>
     <StoreCode>Store A</StoreCode>
     <Extrinsic name="AribaNetwork.packId">5</Extrinsic>
     <Extrinsic name="AribaNetwork.parentPackId"/>
     <Extrinsic name="AribaNetwork.mixedInstruction">false</Extrinsic>
     <Extrinsic name="AribaNetwork.shipNoticeLineIndex">1.0</Extrinsic>
    </Packaging>
    
    PackagingCode

    パッケージ材料 (ボックス、コンテナ、パレット、棚) の一意の ID を指定します。このフィールドによって、パッケージの種類が記述されます。このフィールドは、荷卸しおよび保管の際、受け取り人 (バイヤー) に関連します。多くの場合、パッケージの種類によって、最大積載重量または商品の重量も定義されます。このフィールドは必須です。各 PackagingCode には、この品目のパッケージに対応する 1 つの文字列を含める必要があります。複数のPackagingCode が使用される場合は、同じパッケージを別の言語または地域情報ですべて記述する必要があります。2 つの PackagingCode 要素に同じ xml:lang 属性を含めることはできません。PackagingCode が指定されている場合、Dimension 要素は任意です。ただし、PackagingCode 要素が指定されていない場合は、Dimension 要素が必須になります。PackagingCode には次の属性があります。

    属性 説明
    xml:lang
    (必須)
    品目の梱包に関する 1 つの言語固有のコードを指定します。”pallet”、”skid”、”truck load” などの値は、英語ベースの地域情報に適している場合があります。xml:lang 属性では、PackagingCode の内容が記述される言語または地域情報が指定されます。
    Dimension

    品目の梱包について単一の寸法/数量を指定します。品目の寸法/数量を定義する際にも使用できます。Dimension には次の属性があります。

    属性 説明
    quantity
    (必須)
    この寸法/数量でサイズを指定します。UnitOfMeasure 要素で指定した単位で示されます。
    type
    (必須)
    寸法/数量のタイプです。使用可能な値は次のとおりです。

    ● length – パッケージまたは品目の長さ。
    ● width – パッケージまたは品目の幅。
    ● height – パッケージまたは品目の高さ。
    ● weight – パッケージまたは品目の重量。
    ● volume – パッケージまたは品目の容積、あるいは正味容積。
    ● stackHeight – パッケージの段積み高さ。これは段積みパッケージの高さの合計を示します。
    ● grossWeight – 総重量はパッケージを含む合計重量です。
    ● grossVolume- パッケージを含む合計容積。
    ● unitGrossWeight – 品目の単位あたりの総重量。
    ● unitNetWeight – 品目の単位あたりの正味重量。

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

    要素 説明
    UnitofMeasure UnitOfMeasure」を参照してください。
    PackageID

    パッケージ関連の ID です。PackageID には以下の要素が含まれます。

    要素 説明
    GlobalIndividualAssetID パッケージの一意の ID です。グローバル個別資産 ID (GIAI) は 標準の GS1 システムの一部です。固定資産の所有者を識別するために使用されます。
    ReturnablePackageID パッケージをサプライヤに返品することを容易にする ID を指定します。
    PackageTrackingID サプライヤの内部番号付けスキームに基づいてパッケージを追跡するための追加情報を指定します。
    OrderedQuantity

    注文書の特定の明細に対して品目/製品の数を指定します。この要素には、任意設定の quantity 属性があります。OrderedQuantity には以下の要素が含まれます。

    要素 説明
    UnitofMeasure UnitOfMeasure」を参照してください。
    DispatchQuantity

    (オーダー済み数量と比較した) 配達済み数量を指定します。これは、出荷の修正を決定する際に役立ちます。この要素には、任意設定の quantity 属性があります。DispatchQuantity には以下の要素が含まれます。

    要素 説明
    UnitofMeasure UnitOfMeasure」を参照してください。
    FreeGoodsQuantity

    バイヤーへのコストなしで配達される数量を指定します。例: サンプル、買い戻し、プロモーション、補充など。これらは商用請求書に表示されないか、値 0.00 でマークされます。この要素には、任意設定の quantity 属性があります。
    FreeGoodsQuantity には以下の要素が含まれます。

    要素 説明
    UnitofMeasure UnitOfMeasure」を参照してください。
    7.2.2.13 ReleaseInfo

    ReleaseInfo 要素には、品目または商品のリリースについての詳細が格納されます。ReleaseInfo には、次の属性があります。

    属性 説明
    releaseType
    (必須)
    必須フィールド。分納契約リリースの納入日程の種類を特定する文字列値。
    使用可能な値は、次のとおりです。
    ● JIT (ジャストインタイム)
    ● Forecast
    cumulativeReceivedQuantity
    (必須)
    必須フィールド。特定日までの期間に、分納契約リリースに基づいて受け入れたすべての商品の累積数量を示す数値。
    releaseNumber リリース番号を示す文字列。
    productionGoAheadEndDate 任意設定のフィールド。製造開始期間の終了日。
    materialGoAheadEndDate 投入品目調達開始期間の終了日。

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

    要素 説明
    ShipNoticeReleaseInfo 配送スケジュールから最後に受け取られた出荷を表します。これは、分納契約リリースの納入日程行に基づいて最後に行われた出荷への参照です。
    UnitofMeasure 納入日程行の品目に対して指定された数量の単位。
    Extrinsic 納入日程行の品目の追加情報。
    7.2.2.14 Batch

    1 回の生産実行で生産される品目または商品のバッチ情報を含む要素。たとえば、Batch には、ID、特性、または日付を含めることができます。Batch には次の属性があります。

    属性 説明
    productionDate 品目または商品のバッチが製造される日付です。
    expirationDate 品目または商品のバッチが期限切れになる日付です。
    inspectionDate 品目または商品のバッチが検査される日付です。
    shelfLife 製造日後に製品がその承認済み製品仕様内に保持されると予測される期間です。この属性は、情報の目的でのみ使用されます。期間の語彙表示は、ISO 8601 の拡張形式 PnYn MnDTnH nMnS です。ここで、nYは年数、nM は月数、nD は日数、T は日付/時刻の区切り文字、nH は時間数、nM は分数、nS は秒数です。たとえば、60 日間の期間を示すには、P0Y0M60D と記述します。
    originCountryCode 品目または商品のバッチの発行元の国です。
    batchQuantity 品目または商品のバッチの数量です。

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

    要素 説明
    BuyerBatchID 1 回の生産実行で生産される品目/商品を識別するためのバイヤーからの ID。
    SupplierBatchID 1 回の生産実行で生産される品目/商品を識別するためのサプライヤからの ID。「SupplierBatchID または Batch」を参照してください。
    PropertyValuation プロパティとそれに関連する値です。以下の要素が含まれます。
    ● PropertyReference
    値が割り当てられるプロパティです。
    ● ValueGroup
    プロパティに関する値グループが含まれます。

    次の例は、Batch 要素を示しています。

    <Batch productionDate="2017-01-05T10:27:05 08:00" expirationDate="2017-12-05T10:27:05-08:00" inspectionDate="2017-11-05T10:27:05-08:00" shelfLife="P0Y0M60D" originCountryCode="US" batchQuantity="100">
     <BuyerBatchID>BAT-L-3</BuyerBatchID>
     <SupplierBatchID>BAT-C-3</SupplierBatchID>
    </Batch>
    

    7.2.3 在庫転送オーダーの OrderRequest の例

    社内在庫転送オーダー

    以下の例は、「社内」在庫転送オーダーを示しています。これにより、同じ会社コード内の 1 つのプラントから別のプラントに在庫が転送されます。

    <Request deploymentMode="production">
     <OrderRequest>
     <OrderRequestHeader orderID="4500030514" orderDate="2019-03-13T12:00:00+01:00" orderType="stockTransport" type="new" orderVersion="1">
     <Total>
     <Money currency="EUR">500.0</Money>
     </Total>
     <ShipTo>
     <Address isoCountryCode="DE" addressID="0001" addressIDDomain="buyerLocationID">
     <Name xml:lang="en">Werk 0001</Name>
     <PostalAddress name="default">
     <Street>Hasso-Plattner-Ring 7</Street>
     <City>Walldorf</City>
     <PostalCode>69190</PostalCode>
     <Country isoCountryCode="DE"/>
     </PostalAddress>
     </Address>
     <IdReference identifier="0001" domain="buyerLocationID"/>
     </ShipTo>
     <BillTo>
     <Address isoCountryCode="DE" addressID="CUST_0123" addressIDDomain="supplierID">
     <Name xml:lang="de">SAP A.G.</Name>
     <PostalAddress name="SAP AG">
     <Street>Hasso-Plattner-Ring 7</Street>
     <City>Walldorf</City>
     <PostalCode>69190</PostalCode>
     <Country isoCountryCode="DE"/>
     </PostalAddress>
     </Address>
     <IdReference identifier="CUST_0123" domain="supplierID"/>
     <IdReference identifier="0001" domain="buyerID"/>
     </BillTo>
     <LegalEntity>
     <IdReference identifier="0001" domain="CompanyCode">
     <Description xml:lang="en">SAP A.G.</Description>
     </IdReference>
     </LegalEntity>
     <OrganizationalUnit>
     <IdReference identifier="0001" domain="PurchasingOrganization">
     <Description xml:lang="en">Einkaufsorg. 0001</Description>
     </IdReference>
     </OrganizationalUnit>
     <PaymentTerm payInNumberOfDays="14">
     <Discount>
     <DiscountPercent percent="3.000"/>
     </Discount>
     </PaymentTerm>
     <PaymentTerm payInNumberOfDays="20">
     <Discount>
     <DiscountPercent percent="2.000"/>
     </Discount>
     </PaymentTerm>
     <PaymentTerm payInNumberOfDays="30">
     <Discount>
     <DiscountPercent percent="0.00"/>
     </Discount>
     </PaymentTerm>
     <Contact role="supplierCorporate" addressID="100000" addressIDDomain="buyerID">
     <Name xml:lang="en">Großhändler THEURER</Name>
     <PostalAddress>
     <Street>Wasserturm Straße 121</Street>
     <City>Mannheim</City>
     <PostalCode>68059</PostalCode>
     <Country isoCountryCode="DE"/>
     </PostalAddress>
     <Email name="default">100000@sap.com</Email>
     <IdReference identifier="100000" domain="buyerID"/>
     </Contact>
     <TermsOfDelivery>
     <TermsOfDeliveryCode value="TransportCondition"/>
     <ShippingPaymentMethod value="Other"/>
     <TransportTerms value="EXW">Ex Works</TransportTerms>
     <Address>
     <Name xml:lang="en">Walldoof</Name>
     </Address>
     </TermsOfDelivery>
     <OrderRequestHeaderIndustry>
     <ExternalDocumentType documentType="NB">
     <Description xml:lang="en">Standard PO</Description>
     </ExternalDocumentType>
     </OrderRequestHeaderIndustry>
     </OrderRequestHeader>
     <ItemOut quantity="10.0" lineNumber="10" requestedDeliveryDate="2019-03-15T12:00:00+01:00" itemCategory ="stockTransfer" stockTransferType="intra">
     <ItemID>
     <SupplierPartID/>
     <BuyerPartID>STANDARD</BuyerPartID>
     </ItemID>
     <ItemDetail>
     <UnitPrice>
     <Money currency="EUR">50.0</Money>
     </UnitPrice>
     <Description xml:lang="en">Standard Material</Description>
     <UnitOfMeasure>PCE</UnitOfMeasure>
     <PriceBasisQuantity quantity="1.0" conversionFactor="1">
     <UnitOfMeasure>PCE</UnitOfMeasure>
     </PriceBasisQuantity>
     <Classification domain="not available">Material group 1</Classification>
     <Extrinsic name="extLineNumber">10</Extrinsic>
     </ItemDetail>
     <ControlKeys>
     <OCInstruction value="notAllowed"/>
     <ASNInstruction value="notAllowed"/>
     <InvoiceInstruction value="isNotERS" verificationType="goodsReceipt"/>
     </ControlKeys>
     <ScheduleLine quantity="10.0" requestedDeliveryDate="2019-03-15T12:00:00+01:00" lineNumber="1">
     <UnitOfMeasure>PCE</UnitOfMeasure>
     </ScheduleLine>
     </ItemOut>
     </OrderRequest>
    </Request>
    
    会社間在庫転送オーダー

    以下の例は、「会社間」在庫転送オーダーを示しています。これにより、1 つのプラントから異なる会社コードの別のプラントに在庫が転送されます。

    <Request deploymentMode="production">
     <OrderRequest>
     <OrderRequestHeader orderID="4500030515" orderDate="2019-03-13T12:00:00+01:00" orderType="stockTransport" type="new" orderVersion="1">
     <Total>
     <Money currency="EUR">500.0</Money>
     </Total>
     <ShipTo>
     <Address isoCountryCode="DE" addressID="0001" addressIDDomain="buyerLocationID">
     <Name xml:lang="en">Werk 0001</Name>
     <PostalAddress name="default">
     <Street>Hasso-Plattner-Ring 7</Street>
     <City>Walldorf</City>
     <PostalCode>69190</PostalCode>
     <Country isoCountryCode="DE"/>
     </PostalAddress>
     </Address>
     <IdReference identifier="0001" domain="buyerLocationID"/>
     </ShipTo>
     <BillTo>
     <Address isoCountryCode="DE" addressID="CUST_0123" addressIDDomain="supplierID">
     <Name xml:lang="de">SAP A.G.</Name>
     <PostalAddress name="SAP AG">
     <Street>Hasso-Plattner-Ring 7</Street>
     <City>Walldorf</City>
     <PostalCode>69190</PostalCode>
     <Country isoCountryCode="DE"/>
     </PostalAddress>
     </Address>
     <IdReference identifier="CUST_0123" domain="supplierID"/>
     <IdReference identifier="0001" domain="buyerID"/>
     </BillTo>
     <LegalEntity>
     <IdReference identifier="0001" domain="CompanyCode">
     <Description xml:lang="en">SAP A.G.</Description>
     </IdReference>
     </LegalEntity>
     <OrganizationalUnit>
     <IdReference identifier="0001" domain="PurchasingOrganization">
     <Description xml:lang="en">Einkaufsorg. 0001</Description>
     </IdReference>
     </OrganizationalUnit>
     <PaymentTerm payInNumberOfDays="14">
     <Discount>
     <DiscountPercent percent="3.000"/>
     </Discount>
     </PaymentTerm>
     <PaymentTerm payInNumberOfDays="20">
     <Discount>
     <DiscountPercent percent="2.000"/>
     </Discount>
     </PaymentTerm>
     <PaymentTerm payInNumberOfDays="30">
     <Discount>
     <DiscountPercent percent="0.00"/>
     </Discount>
     </PaymentTerm>
     <Contact role="supplierCorporate" addressID="100000" addressIDDomain="buyerID">
     <Name xml:lang="en">Großhändler THEURER</Name>
     <PostalAddress>
     <Street>Wasserturm Straße 121</Street>
     <City>Mannheim</City>
     <PostalCode>68059</PostalCode>
     <Country isoCountryCode="DE"/>
     </PostalAddress>
     <Email name="default">100000@sap.com</Email>
     <IdReference identifier="100000" domain="buyerID"/>
     </Contact>
     <TermsOfDelivery>
     <TermsOfDeliveryCode value="TransportCondition"/>
     <ShippingPaymentMethod value="Other"/>
     <TransportTerms value="EXW">Ex Works</TransportTerms>
     <Address>
     <Name xml:lang="en">Walldoof</Name>
     </Address>
     </TermsOfDelivery>
     <OrderRequestHeaderIndustry>
     <ExternalDocumentType documentType="NB">
     <Description xml:lang="en">Standard PO</Description>
     </ExternalDocumentType>
     </OrderRequestHeaderIndustry>
     </OrderRequestHeader>
     <ItemOut quantity="10.0" lineNumber="10" requestedDeliveryDate="2019-03-15T12:00:00+01:00" itemCategory ="stockTransfer" stockTransferType="inter">
     <ItemID>
     <SupplierPartID/>
     <BuyerPartID>STANDARD</BuyerPartID>
     </ItemID>
     <ItemDetail>
     <UnitPrice>
     <Money currency="EUR">50.0</Money>
     </UnitPrice>
     <Description xml:lang="en">Standard Material</Description>
     <UnitOfMeasure>PCE</UnitOfMeasure>
     <PriceBasisQuantity quantity="1.0" conversionFactor="1">
     <UnitOfMeasure>PCE</UnitOfMeasure>
     </PriceBasisQuantity>
     <Classification domain="not available">Material group 1</Classification>
     <Extrinsic name="extLineNumber">10</Extrinsic>
     </ItemDetail>
     <ControlKeys>
     <OCInstruction value="notAllowed"/>
     <ASNInstruction value="notAllowed"/>
     <InvoiceInstruction value="isNotERS" verificationType="goodsReceipt"/>
     </ControlKeys>
     <ScheduleLine quantity="10.0" requestedDeliveryDate="2019-03-15T12:00:00+01:00" lineNumber="1">
     <UnitOfMeasure>PCE</UnitOfMeasure>
     </ScheduleLine>
     </ItemOut>
     </OrderRequest>
    </Request>
    

    7.3 OrderRequest への Response

    このドキュメントは、同期式 Request/Response トランザクションの Response 部分です。OrderRequest ドキュメントへの Response の例を次に示します。

    <cXML payloadID="9949494" xml:lang="en" timestamp="1999-03-12T18:39:09-08:00">
     <Response>
     <Status code="200" text="OK"/>
     </Response>
    </cXML>
    

    上記のように、この Response は単純明快です。この場合、申請者に返送する必要があるデータは、Response のStatus 部分のみであるため、「OrderResponse」と名付けられた実際の要素は存在しません。この Response では、HTTP 接続のリモート部分によってその OrderRequest が正常に構文解析され処理されたことを申請者に通知しています。出荷可能な品目やバックオーダーが必要な品目などといった、オーダーレベルの確認応答は通知しません。

    7.4 注文書添付ファイルの受け入れ

    多くの場合、バイヤーは注文書の内容を明確にするために、補足メモ、図面、または FAX を添付する必要があります。バイヤーは、MIME (Multipurpose Internet Mail Extensions) を使用して、cXML 注文書に任意の種類のファイルを添付できます。cXML には、(電子メールまたは FAX の cXML ドキュメントが入っている) 1 つのマルチパート MIME エンベロープ内で送信される外部 MIME パートへの参照のみが含まれます。ネットワークハブは、添付ファイルを受信して、それらをサプライヤに転送するか、あるいはオンラインで入手できるよう保持することができます。



    ← cXML リファレンスガイド 目次へ戻る

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

    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” のいずれかのノードが含まれます。たとえば、次の例には、コピーノードとルーターノードの両方のノードが含まれています。

    <Path>
     <Node type="copy">
     <Credential domain="NetworkId">
     <Identity>AN01000000111</Identity>
     </Credential>
     </Node>
     <Node type="route">
     <Credential domain="NetworkId">
     <Identity>AN01000000233</Identity>
     </Credential>
     </Node>
    </Path>
    

    8.2.2 ルーターノード

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

    8.2.2.1 OriginalDocument

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

    8.2.2.2 DocumentReference

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

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

    8.2.3 コピーノード

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

    <Header>
     <From>
     <Credential domain="NetworkID">
     <Identity>AN990000000168</Identity>
     </Credential>
     </From>
     <To>
     <Credential domain="NetworkID">
     <Identity>AN990000000169</Identity>
     </Credential>
     </To>
     <Sender>
     <Credential domain="NetworkID">
     <Identity>AN990000000168</Identity>
     <SharedSecret>welcome</SharedSecret>
     </Credential>
     <UserAgent>Ariba Buyer 7.0</UserAgent>
     </Sender>
     <Path>
     <!-- Contract Manufacturer -->
     <Node type="copy">
     <Credential domain="NetworkId">
     <Identity>AN01000000170</Identity>
     </Credential>
     </Node>
     <!-- Component Supplier A -->
     <Node type="copy">
     <Credential domain="NetworkId">
     <Identity>AN01000000171</Identity>
     </Credential>
     </Node>
     <!-- Component Supplier B -->
     <Node type="copy">
     <Credential domain="NetworkId">
     <Identity>AN01000000172</Identity>
     </Credential>
     </Node>
     </Path>
     <!-- Original order to copy -->
     <OriginalDocument payloadID="989280592595-5564367883689744433@10.11.128.149"/>
    </Header>
    

    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 つのノードが含まれます。

    <ItemIn quantity="1">
     <ItemID>
     <SupplierPartID>1234</SupplierPartID>
     </ItemID>
     <Path>
     <Node type="copy">
     <Credential domain="NetworkId">
     <Identity>AN01000000111</Identity>
     </Credential>
     </Node>
     <Node type="route">
     <Credential domain="NetworkId">
     <Identity>AN01000000233</Identity>
     </Credential>
     </Node>
     </Path>
     <ItemDetail>
     <UnitPrice>
     <Money currency="USD">10.23</Money>
     </UnitPrice>
     <Description xml:lang="en">Learn ASP in a Week!</Description>
     <UnitOfMeasure>EA</UnitOfMeasure>
     <Classification domain="SPSC">12345</Classification>
     <ManufacturerPartID>ISBN-23455634</ManufacturerPartID>
     <ManufacturerName>O'Reilly</ManufacturerName>
     </ItemDetail>
    </ItemIn>
    

    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 を送信するノードは購買アプリケーションになります。パス上の最
    初のノードは、マーケットプレイスルーターノードです。

    <Header>
     <From>
     <Credential domain="AribaNetworkUserId">
     <Identity>admin@acme.com</Identity>
     </Credential>
     </From>
     <To>
     <Credential domain="NetworkId" type="marketplace">
     <Identity>AN01000000233</Identity>
     </Credential>
     <Credential domain="DUNS">
     <Identity>942888711</Identity>
     </Credential>
     </To>
     <Sender>
     <Credential domain="NetworkId">
     <Identity>AN01000000001</Identity>
     <SharedSecret>abracadabra</SharedSecret>
     </Credential>
     <UserAgent>Network Hub</UserAgent>
     </Sender>
     <Path>
     <Node type="route">
     <Credential domain="AribaNetworkUserId">
     <Identity>admin@acme.com</Identity>
     </Credential>
     </Node>
     <Node type="copy">
     <Credential domain="NetworkId">
     <Identity>AN01000000111</Identity>
     </Credential>
     </Node>
     <Node type="route">
     <Credential domain="NetworkId">
     <Identity>AN01000000233</Identity>
     </Credential>
     </Node>
     </Path>
     <OriginalDocument payloadID="pay1"/>
    </Header>
    

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

    <Header>
     <From>
     <Credential domain="AribaNetworkUserId">
     <Identity>admin@acme.com</Identity>
     </Credential>
     <Credential domain="NetworkId" type="marketplace">
     <Identity>AN01000000233</Identity>
     </Credential>
     </From>
     <To>
     <Credential domain="NetworkId" type="marketplace">
     <Identity>AN01000000233</Identity>
     </Credential>
     <Credential domain="DUNS">
     <Identity>942888711</Identity>
     </Credential>
     </To>
     <Sender>
     <Credential domain="NetworkId">
     <Identity>AN01000000001</Identity>
     <SharedSecret>abracadabra</SharedSecret>
     </Credential>
     <UserAgent>Network Hub</UserAgent>
     </Sender>
     <Path>
     <Node type="route">
     <Credential domain="AribaNetworkUserId">
     <Identity>admin@acme.com</Identity>
     </Credential>
     </Node>
     <Node type="copy">
     <Credential domain="NetworkId">
     <Identity>AN01000000111</Identity>
     </Credential>
     </Node>
     <Node type="route">
     <Credential domain="NetworkId">
     <Identity>AN01000000233</Identity>
     </Credential>
     </Node>
     </Path>
     <OriginalDocument payloadID="pay1"/>
    </Header>
    

    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 には次の任意設定の属性があります。

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

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

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

    Content-Type: Multipart/Related; boundary=mime-boundary
    [Other headers]
    --mime-boundary
    Content-Type: text/xml; charset=UTF-8
    Content-ID: <111@sendercompany.com>
    [Other headers]
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE cXML SYSTEM "http://xml.cxml.org/schemas/cXML/1.2.031/cXML.dtd">
    <cXML payloadID="123@sendercompany.com"
     timestamp="2016-11-20T23:59:45-07:00">
     <Header>
     <From>
     <Credential domain="AribaNetworkUserId">
     <Identity>sender@sendercompany.com</Identity>
     </Credential>
     </From>
     <To>
     <Credential domain="AribaNetworkUserId">
     <Identity>recipient@recipientcompany.com</Identity>
     </Credential>
     </To>
     <Sender>
     <Credential domain="AribaNetworkUserId">
     <Identity>sender@sendercompany.com</Identity>
     <SharedSecret>abracadabra</SharedSecret>
     </Credential>
     <UserAgent>Sender Application</UserAgent>
     </Sender>
     </Header>
     <Request deploymentMode="production">
    <CopyRequest>
     <cXMLAttachment>
     <Attachment>
     <URL>cid:222@sendercompany.com</URL>
     </Attachment>
     </cXMLAttachment>
     </CopyRequest>
     </Request>
    </cXML>
    --mime-boundary
    Content-Type: text/xml; charset=UTF-8
    Content-ID: <222@sendercompany.com>
    [Other headers]
    [Forwarded cXML]
    --mime-boundary--
    



    ← cXML リファレンスガイド 目次へ戻る

     バイヤーは、cXML 見積依頼書をこれらの見積依頼書をサポートするソーシングアプリケーションに送信できます。ソーシングアプリケーションでは、サプライヤは、見積りを送信することで、見積依頼書を表示して回答できます。ソーシングアプリケーションは、サプライヤによって提出された見積依頼書の見積りを収集し、特定の要件に基づいてそれらをマッチングします。受領した最高の見積りに基づいて、ソーシングアプリケーションは、サプライヤからバイヤーに、受領したすべての見積りまたは落札見積りのみを送信します。

    9.1 見積依頼書の概要

    バイヤーは、QuoteRequest ドキュメントを使用して、ソーシングアプリケーションに見積依頼書を送信できます。QuoteRequest ドキュメントには、見積依頼書の種類やそのほかの詳細に関する情報が含まれます。サプライヤは、QuoteMessage ドキュメントを使用して QuoteRequest に応答します。ソーシングアプリケーションは、QuoteMessage ドキュメントを使用して見積依頼書に応答できます。QuoteMessage ドキュメントには、サプライヤによって提供された見積りに関する詳細情報が含まれます。

    9.1.1 見積り DTD

    cXML 標準では、複数の DTD を使用してパーサー検証のパフォーマンスを最適化します。この章で説明する見積依頼書トランザクションは、Quote.dtd という名前の DTD で定義されます。この DTD は次の URL で取得できます。

    http://xml.cXML.org/schemas/cXML/<バージョン>/Quote.dtd

    9.1.2 見積依頼書ドキュメントの順序

    バイヤーが QuoteRequest ドキュメントを送信すると、ソーシングアプリケーションは QuoteMessage ドキュメントで応答します。

    9.2 見積依頼書

    cXML QuoteRequest ドキュメントは、見積依頼書を表します。これには、バイヤーによってソーシングアプリケーションに送信された見積依頼書の詳細が含まれます。次の例は、QuoteRequest 要素の構造を示しています。

    <QuoteRequest>
     <QuoteRequestHeader>
     header information
     </QuoteRequestHeader>
     <QuoteItemOut>
     QuoteItemOut information
     </QuoteItemOut>
    </QuoteRequest>
    

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

    9.2.1 QuoteRequestHeader

    このヘッダー情報は、サプライヤに送信される見積依頼書の詳細を格納します。QuoteRequestHeader には次の属性があります。

    属性 説明
    requestID (必須) 見積依頼書に対する、バイヤーのシステムからの一意の内部番号。
    requestDate (必須) quoteRequest ドキュメントの日付と時刻。
    type quoteRequest のタイプ。既定値は “new” です。使用可能な値は次のとおりです。
    ● new
    ● update
    ● delete
    openDate (必須) サプライヤが回答するために quoteRequest が有効になる日付。
    closeDate (必須) サプライヤが回答に対して quoteRequest が無効になる日付。
    previewDate サプライヤが quoteRequest を利用できるようになる日付。
    templateName ソーシングアプリケーションで使用されるテンプレート。テンプレートによって、バイヤーとソーシングアプリケーション間で送信された見積依頼書の詳細に関する条件の概要を示すことができます。
    currency (必須) quoteRequest および quoteMessage の通貨。3 文字の ISO 通貨コードにする必要があります。
    xml:lang (必須) quoteRequest および quoteMessage の言語。
    quoteReceivingPreference ソーシングアプリケーションから quoteMessage を受信する方法についてのバイヤーのシステム設定。既定値は、ソーシングアプリケーションによって使用されるテンプレートで設定された値に基づきます。バイヤーがテンプレートで設定された値を上書きする場合は、この属性で必要な値を指定する必要があります。使用可能な値は次のとおりです。
    ● winningOnly – 落札された落札見積りがソーシングアプリケーションからバイヤーに送信されます。
    ● finalBidsFromAll – すべての入札が受領されてイベントが終了した後でのみ、見積りがバイヤーからソーシングアプリケーションに送信されます。
    ● all – サプライヤが入札を提出するとすぐに、見積りがバイヤーからソーシングアプリケーションに送信されます。ソーシングアプリケーションでは、見積りの送信のためにイベントの終了は待機されません。

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

    要素 説明
    Name QuoteRequest の名前。
    SupplierSelector QuoteRequest への回答時のサプライヤの選択方法を定義します。「SupplierSelector [205 ページ]」を参照してください。
    Total QuoteRequest における明細の合計金額。
    Description QuoteRequest の説明。
    ShipTo QuoteRequest における明細の納入先情報。この情報は、サプライヤの営業地域を決定するために使用されます。
    Contact サプライヤの連絡先情報。複数の Contact 要素を指定できます。
    Comments バイヤーは、QuoteRequest でコメントおよび添付ファイルを送信できます。
    QuoteHeaderInfo ヘッダーに関連付けられた見積明細を表します。「QuoteHeaderInfo [206 ページ]」を参照してください。
    Extrinsic この QuoteRequest に関連する追加情報が含まれます。「Extrinsic [84 ページ]」を参照してください。
    9.2.1.1 SupplierSelector

    QuoteRequest への応答時のサプライヤの選択方法を定義します。これは任意設定のフィールドです。SupplierSelector 要素には以下の属性があります。

    属性 説明
    matchingType quoteRequest に対して、サプライヤが参加依頼される方法を指定します。使用可能な値は次のとおりです。
    ● invitationOnly – 参加依頼済みサプライヤのみ。イベントに参加できるサプライヤは、OrganizationID 要素で指定されます。
    ● approvedVendorOnly – 承認されたサプライヤ一覧からのサプライヤ。ただし、ソーシングアプリケーションでは、商品と地域のマッチングルールに基づいて、入札可能なサプライヤがフィルタされることがあります。
    ● public – 任意の公開サプライヤ。このサプライヤは、承認されたサプライヤ一覧に存在する場合もあります。ただし、ソーシングアプリケーションでは、商品と地域のマッチングルールに基づいて、入札可能なサプライヤがフィルタされることがあります。

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

    要素 説明
    SupplierInvitation サプライヤが参加依頼される方法を定義します。複数の SupplierInvitation 要素を指定できます。SupplierInvitation 要素には以下の属性があります。

    属性 説明
    supplierStatus バイヤーのシステムにおけるサプライヤの状況。使用可能な値は次のとおりです。
    ● approved – このサプライヤは、バイヤーのシステムに存在し、バイヤーによって承認されています。既定値は “approved” です。
    ● contracted – このサプライヤは、バイヤーのシステムで承認されたサプライヤであり、関連付けられた契約 (主契約) があります。バイヤーは、MasterAgreementIDInfo を指定できます。
    OrganizationID サプライヤの一意の識別子。この要素は、入札への参加を依頼するサプライヤを指定するためにバイヤーによって使用されます。
    Correspondent この要素は、サプライヤの連絡先情報を格納し、サプライヤの識別と連絡に使用されます。「Correspondent [31 ページ]」を参照してください。
    MasterAgreementIDinfo 契約またはリリースオーダーの主契約に対応するバイヤー ID 番号です。この要素は IdReference 要素によって強化されます。
    Extrinsic この SupplierSelector に関連する追加情報が含まれます。「Extrinsic [84 ページ]」を参照してください。
    [/su_table]
    9.2.1.2 QuoteHeaderInfo

    QuoteHeaderInfo 要素は、ヘッダーに関連付けられた見積明細を表します。以下の要素が含まれます。

    要素 説明
    LegalEntity 外部システム内の法人です。IdReference 要素が含まれます。
    OrganizationalUnit 外部システム内の発注ユニットまたは発注グループを識別します。IdReference 要素が含まれます。
    PaymentTerms PaymentProposalRequest ドキュメントの支払条件を定義します。
    FollowUpDocument QuoteMessage 応答をフォローアップする方法についてヒントを提供します。「FollowUpDocument」を参照してください。
    DocumentReference 応答で送信された以前の QuoteMessage のペイロード ID が含まれます。
    Extrinsic このオブジェクトに関連するすべての追加情報が含まれます。

    9.2.2 QuoteItemOut

    QuoteRequest に送信された明細の詳細を格納します。QuoteItemOut 要素には以下の属性が含まれます。

    属性 説明
    quantity (必須) 品目数。
    lineNumber QuoteRequest における品目の明細の位置 (1 から始まる)。”new” および “update”タイプとして、ドキュメント内の明細間の参照を維持するために使用されます。
    parentLineNumber QuoteRequest におけるこの明細の親の位置 (1 から始まる)。ドキュメント内の明細間の階層参照を維持するために使用されます。
    requestedDeliveryDate 品目に対して要求される配達日。
    itemClassification 現在の明細が “material” であるか、”service” であるかを指定します。
    itemType 品目の種類を指定します。使用可能な値は次のとおりです。
    ● composite – 品目グループを識別します。
    ● item – 独立した明細を識別します。
    ● lean – 明細で予定されている子品目がないことを示します。
    serviceLineType サービス明細の種類を表します。使用可能な値は次のとおりです。
    ● standard – 標準サービス。
    ● blanket – 数量を指定しない包括サービス。これは総額として決済されます。
    ● contingency – オーダーを実行するために必要とは限らないサービス。
    ● openquantity – 入札者が特定の部分サービスの数量を提供するよう販売先が要求するサービス。
    ● information – この明細の種類はサービスを記述せず、情報提供のみを目的としています。

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

    要素 説明
    ItemID 品目の一意の ID が指定されます。「ItemID」を参照してください。
    ItemDetail (必須) 購買アプリケーションでユーザーに提示される品目に関する記述的な情報が含まれます。「ItemDetail」を参照してください。
    ShipTo 品目の出荷先住所です。ShipTo には、4 つの要素 (AddressaCarrierIdentifier、TransportInformation、および IdReference) が含まれます。
    Shipping 出荷の輸送に関する追加情報が含まれます。
    Tax 税情報が含まれます。
    SpendDetail 支出詳細情報が取得されます。「SpendDetail」を参照してください。
    Total オーダーの品目の合計金額が含まれます (税および出荷費用を除く)。「合計」を参照してください。
    Table Table
    TermsOfDelivery 出荷通知に対する配達条件が指定されます。「TermsOfDelivery」を参照してください。
    ReferenceDocumentInfo 参照されるドキュメントに関する情報が含まれます。「ReferenceDocumentInfo」を参照してください。
    Contact サプライヤの連絡先情報です。複数の Contact 要素を指定できます。「Contact」を参照してください。
    Comments この見積依頼書 (RFQ) 明細に関連付けられているコメントが含まれます。Comments 要素には、外部ファイルを含めるために Attachment 要素を含めることができます。
    Alternative サービス仕様明細の代替オプションを表します。「Alternative」を参照してください。
    SupplierSelector 見積依頼書 (RFQ) に回答するサプライヤの選択方法を定義します。「SupplierSelector」を参照してください。
    9.2.2.1 Alternative

    サービス仕様明細の代替オプションを表します。代替が指定されている場合は、1 つ基本明細との 1 つ以上の代替明細で構成されます。Alternative 要素には以下の属性が含まれます。

    属性 説明
    alternativeType (必須) サービス明細の代替の種類。使用可能な値は次のとおりです。
    ● noAlternative – 代替方法で実行できないサービスを記述します。
    ● basicLine – 代替方法で実行できるサービスを記述します。基本明細ごとに 1 つまたは複数の代替明細があります。基本明細の金額は、サービス仕様の合計金額に含まれます。
    ● alternativeLine – 関連付けられた基本明細で設定された方法とは異なるサービスの実行および作業の実行方法を記述します。代替明細の金額は、サービス仕様の合計金額には含まれません。例: フローリングを新しくする場合は、寄木張りフローリングに対して 1 つのサービス明細と、セラミックタイルに対して 1 つの代替明細を入力できます。
    basicLineNumber 代替の種類が alternativeLine に設定されている場合、代替の種類が basicLine として設定されているサービス明細の明細番号がここで設定されます。これにより、このサービス明細はどのサービス明細の代替であるかを識別できます。

    以下に Alternative の例を示します。

    <Alternative alternativeType="alternativeLine" basicLineNumber="0000200020"/>
    
    9.2.2.2 価格設定条件の指定

    QuoteRequest または ContractRequest 内に含まれる明細の UnitPrice を指定することができます。UnitPrice 要素には、さまざまなコスト項目の値 (Price、Discount、Surcharge など) を有効期間および基準次元に従って提供できる任意の PricingConditions 要素です。

    価格設定条件の例

    以下の例は、価格設定条件を含む QuoteRequest を示しています。

    <QuoteRequest>
     <QuoteRequestHeader closeDate="" currency="" openDate="" previewDate="" quoteReceivingPreference="winningOnly" requestDate="" requestID="" templateName="" type="new" xml:lang="EN">
     <Name xml:lang="EN">Name</Name>
     <SupplierSelector matchingType="invitationOnly" />
     <Total>
     <Money alternateAmount="" alternateCurrency="" currency="">Money</Money>
     </Total>
     <Description type="" xml:lang="EN" />
     <ShipTo>
     <Address addressID="" addressIDDomain="" isoCountryCode="">
     <Name xml:lang="EN">Name</Name>
     </Address>
     </ShipTo>
     <Contact addressID="" addressIDDomain="" role="nmtoken">
     <Name xml:lang="EN">Name</Name>
     </Contact>
     <Comments type="" xml:lang="EN" />
     <QuoteHeaderInfo />
     <Extrinsic name="" />
     </QuoteRequestHeader>
     <QuoteItemOut itemClassification="material" itemType="composite" lineNumber="" parentLineNumber="" quantity="" requestedDeliveryDate="" serviceLineType="standard">
     <ItemID>
     <SupplierPartID revisionID="">SupplierPartID</SupplierPartID>
     </ItemID>
     <ItemDetail>
     <UnitPrice>
     <Money alternateAmount="" alternateCurrency="" currency="">Money</Money>
     <PricingConditions>
     <ValidityPeriods>
     <!--Period Q1-->
     <ValidityPeriod from='01.01.2019' to='31.03.2019'>
     <ConditionTypes>
     <!--Price for Q1-->
     <ConditionType name='Price'>
     <CostTermValue >
     <Money currency="USD">120</Money>
     </CostTermValue>
     <Scales scaleType="From">
     <Scale from ='0'>
     <CostTermValue>
     <Money currency='USD'>120</Money>
     </CostTermValue>
     </Scale>
     <Scale from ='100'>
     <CostTermValue>
     <Money currency='USD'>110</Money>
     </CostTermValue>
     </Scale>
     <Scale from ='500'>
     <CostTermValue>
     <Money currency='USD'>100</Money>
     </CostTermValue>
     </Scale>
     </Scales>
     </ConditionType>
     <!--Discount for Q1-->
     <ConditionType name='Discount'>
     <CostTermValue >
     <Money currency='USD'>-5</Money>
     </CostTermValue>
     <Scales scaleType="From">
     <Scale from ='0'>
     <CostTermValue>
     <Money currency='USD'>-20</Money>
     </CostTermValue>
     </Scale>
     <Scale from ='100'>
     <CostTermValue>
     <Money currency='USD'>-15</Money>
     </CostTermValue>
     </Scale>
     <Scale from ='500'>
     <CostTermValue>
     <Money currency='USD'>-10</Money>
     </CostTermValue>
     </Scale>
     </Scales>
     </ConditionType>
     </ConditionTypes>
     </ValidityPeriod>
     <!--Period Q2--> 
     <ValidityPeriod from='01.04.2019' to='30.06.2019'>
     <ConditionTypes>
     <!--Price for Q2-->
     <ConditionType name='Price'>
     <CostTermValue >
     <Money currency="USD">125</Money>
     </CostTermValue>
     <Scales scaleType="From">
     <Scale from ='0'>
     <CostTermValue>
     <Money currency='USD'>125</Money>
     </CostTermValue>
     </Scale>
     <Scale from ='100'>
     <CostTermValue>
     <Money currency='USD'>115</Money>
     </CostTermValue>
     </Scale>
     <Scale from ='500'>
     <CostTermValue>
     <Money currency='USD'>105</Money>
     </CostTermValue>
     </Scale>
     </Scales>
     </ConditionType>
     <!--Surcharge for Q2-->
     <ConditionType name='Discount'>
     <CostTermValue >
     <Money currency='USD'>5</Money>
     </CostTermValue>
     <Scales scaleType="From">
     <Scale from ='0'>
     <CostTermValue>
     <Money currency='USD'>-10</Money>
     </CostTermValue>
     </Scale>
     <Scale from ='100'>
     <CostTermValue>
     <Money currency='USD'>-5</Money>
     </CostTermValue>
     </Scale>
     <Scale from ='500'>
     <CostTermValue>
     <Money currency='USD'>-15</Money>
     </CostTermValue>
     </Scale>
     </Scales>
     </ConditionType>
     </ConditionTypes>
     </ValidityPeriod>
     </ValidityPeriods>
     </PricingConditions>
     </UnitPrice>
     <Description type="" xml:lang="EN" />
     <UnitOfMeasure>UnitOfMeasure</UnitOfMeasure>
     <Classification code="" domain="">Classification</Classification>
     </ItemDetail>
     <ShipTo>
     <Address addressID="" addressIDDomain="" isoCountryCode="">
     <Name xml:lang="EN">Name</Name>
     </Address>
     </ShipTo>
     <Shipping tracking="" trackingDomain="" trackingId="">
     <Money alternateAmount="" alternateCurrency="" currency="">Money</Money>
     <Description type="" xml:lang="EN" />
     </Shipping>
     <Tax>
     <Money alternateAmount="" alternateCurrency="" currency="">Money</Money>
     <Description type="" xml:lang="EN" />
     </Tax>
     <SpendDetail>
     <TravelDetail confirmationNumber="" pnrLocator="" quoteExpirationTime="">
     <AirDetail>
     <TripType type="round" />
     <AirLeg arrivalTime="" departureTime="" equipment="" flightNumber="" seatNumber="" seatType="window" stops="" travelSegment="" upgrade="yes">
     <Vendor preferred="yes">
     <Address addressID="" addressIDDomain="" isoCountryCode="">
     <Name xml:lang="EN">Name</Name>
     </Address>
     </Vendor>
     <AirLegOrigin>
     <Airport airportCode="" />
     </AirLegOrigin>
     <AirLegDestination>
     <Airport airportCode="" />
     </AirLegDestination>
     </AirLeg>
     </AirDetail>
     </TravelDetail>
     </SpendDetail>
     <Total>
     <Money alternateAmount="" alternateCurrency="" currency="">Money</Money>
     </Total>
     <TermsOfDelivery>
     <TermsOfDeliveryCode value="">TermsOfDeliveryCode</TermsOfDeliveryCode>
     <ShippingPaymentMethod value="">ShippingPaymentMethod
     </ShippingPaymentMethod>
     </TermsOfDelivery>
     <ReferenceDocumentInfo lineNumber="" scheduleLineNumber="" status="created" />
     <Contact addressID="" addressIDDomain="" role="nmtoken">
     <Name xml:lang="EN">Name</Name>
     </Contact>
     <Comments type="" xml:lang="EN" />
     <Alternative alternativeType="noAlternative" basicLineNumber="" />
     <SupplierSelector matchingType="invitationOnly" />
     </QuoteItemOut>
    </QuoteRequest>
    
    9.2.2.2.1 UnitPrice

    品目の単位あたりの価格。以下の要素が含まれます。

    要素 説明
    Money (必須) Modifications 適用後の最終金額が含まれます。
    Modifications 明細レベルで適用可能な値引きおよび手数料の詳細が含まれます。
    PricingConditions 有効期間および任意の基準を含む費用要素を表す価格設定条件。「PricingConditions」を参照してください。
    9.2.2.2.2 PricingConditions

    特定の明細に対する価格設定条件のオブジェクトを示します。以下の要素が含まれます。

    要素 説明
    ValidityPeriods (必須) 有効期間の一覧を示します。「ValidityPeriod」を参照してください。
    9.2.2.2.3 ValidityPeriods

    有効期間の一覧を示します。以下の要素が含まれます。

    要素 説明
    ValidityPeriod (必須) 価格設定条件の有効期間を示します。「ValidityPeriod」を参照してください。
    9.2.2.2.4 ValidityPeriod

    価格設定条件の有効期間を示します。この要素には、次の属性があります。

    属性 説明
    from (必須) 有効期間の開始日。
    to (必須) 有効期間の終了日。

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

    要素 説明
    ConditionTypes (必須) 条件の種類の一覧を示します。
    9.2.2.2.5 ConditionTypes

    条件の種類の一覧を示します。以下の要素が含まれます。

    要素 説明
    ConditionType (必須) 価格設定条件の種類を示します。「ConditionType」を参照してください。
    9.2.2.2.6 ConditionType

    価格設定条件の種類を示します。ConditionType には、基準が指定されていない場合に使用されるコスト項目の初期値を設定することができます。基準が指定されている場合は、基準に提供されるコスト項目の値が使用されます。ConditionType には次の属性があります。

    属性 説明
    name (必須) 条件の種類の名前。例: Price、Surcharge。

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

    要素 説明
    CostTermValue 価格設定条件のコスト項目を示します。「CostTermValue」を参照してください。
    Scales 価格設定条件の基準ベクトルを示します。「Scale」を参照してください。
    9.2.2.2.7 CostTermValue

    価格設定条件のコスト項目を示します。Money または Percentage 値が含まれます。

    9.2.2.2.8 Scales

    価格設定条件の基準ベクトルを示します。Scales には以下の属性があります。

    属性 説明
    scaleType (必須) 有効期間の基準の種類を表します。使用可能な値は次のとおりです。
    ● From
    ● To
    ● Graduated
    scaleBasis 基準が何に基づくかを示す文字列です。初期値は “quantity” です。

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

    要素 説明
    Scale (必須) 数量基準を表します。「Scale」を参照してください。
    9.2.2.2.9 Scale

    数量基準を表します。1 つの基準に複数のコスト項目を設定することができます。

    注記 Scales 要素によって、基準の種類を指定します。

    Scale には以下の属性があります。

    属性 説明
    from 基準の下限値。
    to 基準の上限値。

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

    要素 説明
    CostTermValue (必須) 価格設定条件のコスト項目を示します。「CostTermValue」を参照してください。

    基準に必要な属性は、選択した基準の種類によって異なります。

    基準の種類 必要とされる基準属性
    From from
    To to
    Graduated from, to
    例: From 基準
    <Scale from='0'>
    <Scale from='1000'>
    <Scale from='5000'>
    

    上の例では、3 つの基準 (0 から、1000 から、5000 から) が使用されています。

    例: To 基準
    <Scale to='100'>
    <Scale to='1000'>
    <Scale to='5000'>
    

    上の例では、3 つの基準 (100 まで、1000 まで、5000 まで) が使用されています。

    例: Graduated 基準
    <Scale from='0' to='100'>
    <Scale from='101' to='200'>
    

    上の例は、2 つの基準 (0 から 100 まで、101 から 200 まで) が使用されています。

    9.3 QuoteMessage

    サプライヤは、見積りを送信することで見積依頼書 (QuoteRequest) に応答することができます。ソーシングアプリケーションは、QuoteMessages を使用してこれらの見積りをバイヤーに送信します。

    9.3.1 QuoteMessageHeader

    この要素は、バイヤーに送信される quoteMessage のヘッダー詳細を格納します。QuoteMessageHeader には次の属性があります。

    属性 説明
    type (必須) quoteMessage の種類。使用可能な値は次のとおりです。
    ● accept
    ● reject
    ● update
    ● final
    ● award
    quoteID (必須) 見積りの一意の ID。
    quoteDate (必須) 見積りが提出された日付。
    currency (必須) quoteRequest および quoteMessage の通貨。3 文字の ISO 通貨コードにする必要があります。
    xml:lang (必須) quoteRequest および quoteMessage の言語。

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

    要素 説明
    OrganizationID (必須) サプライヤの一意の識別子。
    Total (必須) QuoteMessage における明細の合計金額。
    ShipTo QuoteMessage における明細の納入先住所。この情報は、サプライヤの営業地域を決定するために使用されます。
    QuoteRequestReference QuoteRequest ID と日付に関する詳細を格納します。「QuoteRequestReference」を参照してください。
    Comments この QuoteMessage に関連するコメントが含まれます。「Comments [125ページ]」を参照してください。
    QuoteHeaderInfo ヘッダに関連付けられた見積明細を表します。「QuoteHeaderInfo」を参照してください。
    SupplierProductionFacilityRelations サプライヤの生産設備とその生産設備の役割間に存在する関係を定義します。「SupplierProductionFacilityRelations [281 ページ]」を参照してください。
    Extrinsic この QuoteMessage に関連する追加情報が含まれます。「Extrinsic [84 ページ]」を参照してください。
    9.3.1.1 QuoteRequestReference

    これは任意設定のフィールドです。QuoteRequest ID と日付に関する詳細を格納します。QuoteRequestReference には次の属性があります。

    属性 説明
    requestID (必須) 見積依頼書に対する、バイヤーのシステムからの一意の内部番号。
    requestDate (必須) quoteRequest ドキュメントの日付と時刻。

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

    ドキュメント参照

    DocumentReference 要素は、タイプが “update” または “delete” である場合にのみ一覧表示されます。この場合、DocumentReference は、QuoteRequest の最新の quoteRequest を参照します。たとえば、QuoteRequest を作成し、更新してから削除する場合、最終ドキュメントには、type=”update” のQuoteRequest を参照する DocumentReference が含まれています。これにより、そのドキュメントは、元の(type=”new”) quoteRequest ドキュメントを参照します。この要素は任意設定です。

    9.3.2 QuoteItemIn

    QuoteItemIn 要素には以下の属性が含まれます。

    属性 説明
    type (必須) quoteMessage の種類。使用可能な値は次のとおりです。
    ● accept
    ● reject
    ● update
    ● final
    ● award
    quantity (必須) 品目数。
    lineNumber QuoteRequest における品目の明細の位置 (1 から始まる)。”new” および”update” タイプとして、ドキュメント内の明細間の参照を維持するために使用されます。
    parentLineNumber QuoteRequest におけるこの品目の親の位置 (1 から始まる)。ドキュメント内の明細間の階層参照を維持するために使用されます。
    requestedDeliveryDate 品目に対して要求される配達日。
    rank 見積りの順位。
    itemClassification 現在の明細が “material” であるか、”service” であるかを指定します。
    itemType 品目の種類を指定します。使用可能な値は次のとおりです。
    ● composite – 品目グループを識別します。
    ● item – 独立した明細を識別します。
    ● lean – 明細で予定されている子品目がないことを示します。
    serviceLineType サービス明細の種類を表します。使用可能な値は次のとおりです。
    ● standard – 標準サービス。
    ● blanket – 数量を指定しない包括サービス。これは総額として決済されます。
    ● contingency – オーダーを実行するために必要とは限らないサービス。
    ● openquantity – 入札者が特定の部分サービスの数量を提供するよう販売先が要求するサービス。
    ● information – この明細の種類はサービスを記述せず、情報提供のみを目的としています。

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

    要素 説明
    ItemID 品目の一意の ID が指定されます。「ItemID [91 ページ]」を参照してください。
    ItemDetail (必須) 購買アプリケーションでユーザーに提示される品目に関する記述的な情報が含まれます。「ItemDetail [92 ページ]」を参照してください。
    ShipTo 品目の出荷先住所です。
    Shipping オーダーの出荷費用が含まれます。
    Tax 税に関する情報。
    SpendDetail 支出詳細情報が取得されます。「SpendDetail [146 ページ]」を参照してください。
    Total 見積りの品目の合計金額が含まれます (税および出荷費用を除く)。
    TermsOfDelivery 国際商工会議所によって定義された任意の出荷条件 (インコタームズ)。「TermsOfDelivery [131 ページ]」を参照してください。
    ReferenceDocumentInfo この明細の任意の参照ドキュメント情報。たとえば、外部システムの購入申請または見積依頼書 (RFQ) です。「ReferenceDocumentInfo [134 ページ]」を参照してください。
    Contact サプライヤの連絡先情報です。複数の Contact 要素を指定できます。
    Comments このオブジェクトに関連するコメントが含まれます。
    Alternative サービス仕様明細の代替オプションを表します。代替が指定されている場合は、1 つの基本明細と 1 つ以上の代替明細で構成されています。「Alternative」を参照してください。
    SupplierProductionFacilityRelations サプライヤの生産設備とその生産設備の役割間に存在する関係を定義します。「SupplierProductionFacilityRelations [281 ページ]」を参照してください。
    Extrinsic 契約品目に関連する追加情報が含まれます。



    ← cXML リファレンスガイド 目次へ戻る

     バイヤー企業は cXML 支払ドキュメントを利用して提供された製品やサービスに対してサプライヤに支払いをします。cXML の支払ドキュメントを利用すると支払予定情報にただちにアクセスできるため、買掛金と売掛金についてより正確な予測と計画を立てることができます。

    ページ内の目次
    10.1 支払いの概要

    10.1.1 PaymentRemittance DTD
    10.1.2 支払ドキュメントの流れ

    10.2 PaymentProposalRequest

    10.2.1 PayableInfo
    10.2.1.1 PayableInvoiceInfo
    10.2.1.2 PayableOrderInfo
    10.2.1.3 PayableMasterAgreementInfo
    10.2.2 PaymentMethod
    10.2.2.1 説明
    10.2.3 PaymentPartner
    10.2.3.1 Contact
    10.2.3.2 IdReference
    10.2.3.3 P カード
    10.2.3.4 NatureOfBusiness
    10.2.3.5 IncorporationType
    10.2.3.6 AccountCurrency
    10.2.4 PaymentTerms
    10.2.5 DiscountBasis
    10.2.6 TaxAdjustment
    10.2.6.1 TaxAdjustmentDetail
    10.2.7 NetAmount

    10.3 PaymentRemittanceRequest

    10.3.1 PaymentRemittanceRequestHeader
    10.3.1.1 PaymentReferenceInfo
    10.3.1.2 PaymentPurpose
    10.3.2 PaymentRemittanceSummary
    10.3.2.1 NetAmount
    10.3.2.2 GrossAmount
    10.3.2.3 DiscountAmount
    10.3.2.4 AdjustmentAmount
    10.3.3 RemittanceDetail
    10.3.3.1 PayableInfo
    10.3.3.2 NetAmount
    10.3.3.3 GrossAmount
    10.3.3.4 DiscountAmount
    10.3.3.5 AdjustmentAmount

    10.4 PaymentBatchRequest

    10.4.1 PaymentBatchRequestHeader
    10.4.2 PaymentBatchSummary
    10.4.2.1 ControlSum
    10.4.2.2 NumberOfPayments
    10.4.3 PaymentRemittanceRequest

    10.5 PaymentRemittanceStatusUpdateRequest

    10.5.1 DocumentReference
    10.5.2 PaymentRemittanceStatus
    10.5.2.1 PaymentRemittanceStatusDetail
    10.5.2.2 Extrinsic

    10.6 支払ドキュメントの例

    10.6.1 PaymentProposalRequest の例
    10.6.2 PaymentRemittanceRequest の例
    10.6.3 PaymentRemittanceStatusUpdateRequest の例

    10.7 TradeRequest

    10.7.1 TradeRequestHeader
    10.7.2 TradeRequestSummary
    10.7.3 TradeItem

    10.8 PaymentReceiptConfirmationRequest

    10.8.1 PaymentReceiptConfirmationRequestHeader
    10.8.2 PaymentReceiptDetails
    10.8.2.1 PaymentReceiptItem
    10.8.2.1.1 PaymentDetails
    10.8.2.1.1.1 PaymentAmount
    10.8.2.1.1.2 PreviousBalance
    10.8.2.1.1.3 PresentBalance
    10.8.3 PaymentReceiptSummary

    10.9 ChargeFileRequest

    10.9.1 ChargeFileRequestHeader
    10.9.1.1 ProviderName
    10.9.2 ChargeFileDetails
    10.9.2.1 ChargeFile
    10.9.2.1.1 NumberOfCharges

    10.1 支払いの概要

    cXML の支払予定および送金通知ドキュメントを使用することで、支払処理が自動化されます。取引先は、それらのドキュメントを通じて支払いの処理や追跡を行います。cXML による支払処理には、支払予定 (支払計画)、割引、支払ドキュメントの作成と送付 (支払いが行われる場所は関係ありません)、および支払いの受領確認が含まれます。PaymentProposalRequest ドキュメントは、支払予定です。これによって、バイヤー企業は支払期限と割引を指定することができます。PaymentRemittance ドキュメントには、標準の請求書、クレジットメモ、およびデビットメモなどを含む、多種多様な業務のシナリオに応じた支払取引の詳細が表示されます。支払いが行われるときには、支払いを行う組織がそれに関連した送金通知ドキュメントも作成します。送金通知とは、完了した支払いの詳細を記載した内容確認のための書類です。一般的な送金通知には、使用された支払方法、銀行情報、割引金額、支払金額、および支払いに含まれる支払処理のリストが含まれます。

    10.1.1 PaymentRemittance DTD

    cXML 標準では、複数の DTD を使用してパーサーの検証のパフォーマンスを最適化します。この章で説明する支払取引は、PaymentRemittance.dtd という名前の DTD で定義されます。この DTD は次の場所で入手できます。

    http://xml.cXML.org/schemas/cXML//PaymentRemittance.dtd

    10.1.2 支払ドキュメントの流れ

    購買アプリケーションから PaymentProposalRequest および PaymentRemittanceRequest ドキュメントが送信され、サプライヤが一般的な Response ドキュメントを返信します。支払取引の状況レベルが更新されると、購買アプリケーションから PaymentRemittanceStatusUpdateRequest ドキュメントが送信されます。これらのドキュメントはすべて、認証とルーティングのために商取引ネットワークハブを経由します。

    10.2 PaymentProposalRequest

    cXML の PaymentProposalRequest ドキュメントは、支払予定を表します。このドキュメントには、支払金額と支払日がリストされています。これは、参照用として使用される場合もあれば、支払処理を開始するために使用される場合もあります。バイヤー企業が支払予定をネットワークハブに送信すると、ただちにサプライヤに転送されるか、またはネットワークハブが支払日まで保存することができます。PaymentProposalRequest には次の属性があります。

    属性 説明
    paymentProposalID
    (必須)
    バイヤーが生成する支払予定の識別子です。
    operation
    (必須)
    実行する操作を定義します。使用可能な値は次のとおりです。
    ● new – 新しい支払予定を作成します。
    ● update – paymentProposalID によって識別される既存の支払予定を更新します。
    ● delete – paymentProposalID によって識別される既存の支払予定をキャンセルします。PaymentProposalRequest の任意設定の属性およびサブ要素はすべて無視されます。
    ● hold – paymentProposalID によって識別される既存の支払予定を保留します。 PaymentProposalRequest の任意設定の属性およびサブ要素はすべて無視されます。
    isNetworkPayment この支払予定をネットワークハブを通じて支払う場合は、「yes」に設定します。初期値は、”no” です。
    paymentDate 銀行が支払いを開始する日付です。
    companyCode この支払予定のバイヤーの支払会社コードです。

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

    要素 説明
    PayableInfo
    (必須)
    支払処理対象ドキュメント (請求書、オーダー、契約など) への参照を指定します。「PayableInfo」を参照してください。
    PaymentMethod 支払方法を指定します。isNetworkPayment を “yes” に設定している場合は、指定する必要があります。「PaymentMethod」を参照してください。
    PaymentPartner 支払元、支払先、振込元の銀行、振込先の銀行、および送金先など、支払いに関連するすべてのパートナーを指定します。「PaymentPartner」を参照してください。
    PaymentTerms PaymentProposalRequest ドキュメントの支払条件を定義します。「PaymentTerms」を参照してください。
    GrossAmount 総額支払金額。
    DiscountBasis 支払処理の割引基準を定義します。「DiscountBasis」を参照してください。
    DiscountAmount 割引金額。
    AdjustmentAmount さまざまな調整金額の合計です。調整金額は正の場合も負の場合もあります。正の場合は支払金額が減少し、負の場合は支払金額が増加します (支払遅延金や違約金など)。
    Tax 支払処理の税を定義します。「」を参照してください。
    TaxAdjustment 支払処理の税調整を定義します。「TaxAdjustment」を参照してください。
    NetAmount 正味金額を定義します。「NetAmount」を参照してください。
    Comments このオブジェクトに関連するコメントが含まれます。
    Extrinsic このオブジェクトに関連するすべての追加情報が含まれます。

    次の例は、PaymentProposalRequest 要素を示しています。

    <Request>
     <PaymentProposalRequest paymentProposalID="6300002495" operation="new" paymentDate="2021-06-30T23:39:55+05:30">
     <PayableInfo>
     <PayableInvoiceInfo>
     <InvoiceIDInfo invoiceID="INV2490" invoiceDate="2021-05-01T23:39:55+05:30"/>
     </PayableInvoiceInfo>
     </PayableInfo>
     <PaymentMethod type="other">
     <Description xml:lang="EN">
     <ShortName>other</ShortName>
     </Description>
     </PaymentMethod>
     <PaymentPartner>
     ……
     </PaymentPartner>
     <PaymentTerms paymentTermCode="Z210A"></PaymentTerms>
     <GrossAmount>
     <Money currency="CAD">1120.0</Money>
     </GrossAmount>
     <DiscountBasis>
     <Money currency="CAD">1000.0</Money>
     </DiscountBasis>
     <DiscountPercent percent="10.134"/>
     <DiscountAmount>
     <Money currency="CAD">20.0</Money>
     </DiscountAmount>
     <Tax>
     <Money currency="CAD">120.0</Money>
     <Description xml:lang="EN"/>
     <TaxDetail category="gst">
     <TaxAmount>
     <Money currency="CAD">50.0</Money>
     </TaxAmount>
     <TaxLocation xml:lang="EN">CA</TaxLocation>
     </TaxDetail>
     <TaxDetail category="pst">
     <TaxAmount>
     <Money currency="CAD">70.0</Money>
     </TaxAmount>
     <TaxLocation xml:lang="EN">CA-BC</TaxLocation>
     </TaxDetail>
     </Tax>
     <NetAmount>
     <Money currency="CAD">1100</Money>
     </NetAmount>
     <Extrinsic name="immediatepay"/>
     <Extrinsic name="Ariba.relaxedOperationCheck"/>
     <Extrinsic name="organizationUnit">4500</Extrinsic>
     </PaymentProposalRequest>
    </Request>
    

    10.2.1 PayableInfo

    請求書、オーダー、または契約といった、支払処理対象ドキュメントの参照情報です。PayableInfo はバイヤーとサプライヤの両方で認識されています。たとえば、請求書の PayableInfo は PayableInvoiceInfo です。次の例では、PaymentRemittance.dtd からの PayableInfo の要素宣言を示しています。

    <!ELEMENT PayableInfo (PayableInvoiceInfo | PayableOrderInfo | PayableMasterAgreementInfo)>
    

    次の例は、最小限の有効な PayableInfo 要素の構造を示しています。

    <PayableInfo>
     <PayableInvoiceInfo>
     <InvoiceIDReference or InvoiceIDInfo>
     .....
     </InvoiceIDReference or InvoiceIDInfo>
     </PayableInvoiceInfo>
    </PayableInfo>
    

    次の例は、任意設定の PayableOrderInfo を含む PayableInfo 要素の構造を示しています。

    <PayableInfo>
     <PayableInvoiceInfo>
     <InvoiceIDReference or InvoiceIDInfo>
     <PayableOrderInfo>
     <OrderIDInfo>
     .....
     </OrderIDInfo>
     </PayableOrderInfo>
     </InvoiceIDReference or InvoiceIDInfo>
     </PayableInvoiceInfo>
    </PayableInfo>
    

    PayableInfo には属性がありません。

    10.2.1.1 PayableInvoiceInfo

    支払いをする請求書への参照情報です。PayableInvoiceInfo には InvoiceReference または InvoiceIDInfo を含める必要があり、PayableOrderInfo または PayableMasterAgreementInfo が含まれる可能性があります。

    InvoiceReference

    以前の InvoiceDetailRequest ドキュメントを明確に参照できるようにします。InvoiceReference はInvoiceDetailRequest メッセージからコピーされます。

    InvoiceIDInfo

    サプライヤのシステムで認識されている請求書の ID を定義します。InvoiceIDInfo は、以下の 2 つの属性を含んでいます。

    属性 説明
    invoiceID
    (必須)
    サプライヤのシステムで認識されている請求書の ID
    invoiceDate 請求書の日付
    10.2.1.2 PayableOrderInfo

    オーダーに関連する補足情報です。例えば、統合された請求書に対する支払いには関連するオーダー情報が含まれる場合があります。支払われたオーダーに関連した支払処理の情報を定義します。 PayableOrderInfo には属性がありません。

    OrderReference

    支払いをするオーダーへの参照情報です。

    OrderIDInfo

    調達アプリケーションによって割り当てられたオーダー ID です。

    10.2.1.3 PayableMasterAgreementInfo

    契約に関連した補足情報です。例えば、統合された請求書に対する支払いには関連する契約の情報が含まれる場合があります。支払いをする契約に関連した支払処理の情報を定義します。

    10.2.2 PaymentMethod

    支払方法です。isNetworkPayment を true に設定している場合は、指定する必要があります。バイヤー企業は、この要素を使用して支払方法を識別します。PaymentMethod には、以下の 1 つの属性があります。

    属性 説明
    type
    (必須)
    支払方法の種類です。使用可能な値は、次のとおりです。
    ● ach – Automated Clearing House (資金決済機構)
    ● cash – 現金払い
    ● check – 小切手支払い
    ● creditCard – クレジットカードまたは P カードによる支払い
    ● debitCard – デビットカードによる支払い
    ● draft – 書面による支払指示 (第二者から第三者に支払われるように指示します)
    ● wire – 振込
    ● other – cXML に定義されていないその他の支払方法
    10.2.2.1 説明

    支払方法の説明です。種類が “other” に設定されている場合は、Description が必須です。Description にある ShortName 要素は、支払方法の名前を示す必要があります。

    ShortName

    Description 全体よりも少ない字数で支払方法を説明する短い文字列です。使用できるスペースが限られている場合は、ShortName 要素を使用します。たとえば、要素の表では ShortName が表示される場合があります。リンクされた「詳細」ビューで、Description が表示されます。ShortName が指定されていない場合は、ユーザーインターフェイスで Description の一部が切り捨てられます。この要素は Description 要素の内部のみで使用されるので xml:lang 属性は必要ありません。ShortName で使用する言語は、ShortName を含む Description 要素の言語と一致している必要があります。

    10.2.3 PaymentPartner

    支払元、支払先、振込元の銀行、振込先の銀行、および送金先など、支払いに関連するすべてのパートナーを指定します。使用する支払方法によっては、支払相手の数も指定する必要があります。PaymentPartner には属性がありません。PaymentPartner には以下の要素が含まれます。

    要素 説明
    Contact
    (必須)
    支払相手の連絡先情報が含まれます。「Contact」を参照してください。
    IdReference 支払相手の一意の ID 参照が含まれます。「IdReference」を参照してください。
    PCard P カード情報を指定します。「P カード」を参照してください。
    NatureOfBusiness 会社が属している業種または業界を指定します。「NatureOfBusiness」を参照してください。
    IncorporationType 会社の種類を指定します。「IncorporationType」を参照してください。
    AccountCurrency 支払相手に使用された口座通貨を示します。「AccountCurrency」を参照してください。
    10.2.3.1 Contact

    支払相手の連絡先情報。Contact には次の属性があります。

    属性 説明
    role 支払相手の役割です。使用可能な値は次のとおりです。
    ● payer – この取引の支払元。
    ● payee – 支払いの受領者。
    ● originatingBank – 支払いの振込元銀行。この属性は、銀行振込の場合に必須です。
    ● receivingBank – 支払いの振込先銀行。この属性は、銀行振込の場合に必須です。
    ● originatingCorrespondentBank – (任意設定) 支払いを保持して振込先銀行または振込先取引銀行に支払いを転送する銀行。
    ● receivingCorrespondentBank – (任意設定) 支払いを受け取って振込先銀行に支払いを転送する銀行。
    ● intermediaryBank – (任意設定) 仲介銀行。
    ● payeeContact – (任意設定) サプライヤ連絡先の名前。
    ● remitTo – (任意設定) サプライヤの送金先住所。この role 値では、IdReference と PCard 要素は省略できます。
    addressID 住所の ID です。addressID では、ID 照会を必要とする場合の住所コードがサポートされます。
    addressIDDomain 住所 ID を付与する責任がある機関または組織を指定するコードです。たとえば、DUNS や ILN です。このコードは、addressID 属性に値がある場合に必須です。

    payer および payee の役割を持つ Contact 要素は、常に必須です。支払方法に銀行振込が指定されている場合は、Contact 要素に originatingBank と receivingBank の役割が必須です。isNetworkPayment が true の場合は、remitTo の役割を指定する必要があります。Contact role が payee の場合、Contact の下の名前はサプライヤ組織名です。Contact role が payeeContact の場合、Contact の下の名前はサプライヤ連絡先名です。

    10.2.3.2 IdReference

    銀行口座 ID、銀行 ID、および銀行の支店 ID (任意設定) などの支払相手の一意の識別参照を定義します。IdReference は、電子支払いに関係するすべての取引に必要です。この要素を指定しなくてもよいのは、小切手や現金などの電子支払い以外の方法の場合のみです。IdReference には次の属性があります。

    属性 説明
    identifier
    (必須)
    domain 内にある IdReference の一意の識別子です。
    domain
    (必須)
    IdReference の domain です。使用可能な値は次のとおりです。
    ● bankRoutingID – この支払相手の銀行のルーティング ID
    ● accountReceivableID – 支払先の売掛金勘定または部門の ID
    ● bankAccountID – この支払相手の銀行口座 ID
    ● ibanID – ISO 13616 で指定されている、この支払相手の国際銀行口座番号 (International Bank Account Number)
    ● abaRoutingNumber – この支払相手の銀行の ABA 番号 (American Banking Association の 9 桁のルーティング送金番号)
    ● bankNationalID – 国に固有の銀行コード。このコードで、Contact に指定された国内の銀行を一意に識別できる必要があります。
    ● isoBicID – ISO 9362 で指定されている ISO BIC ID (Bank Identifier Code)。Bank Identifier Code (BIC) は世界共通の金融機関識別方法です。BIC は 8 文字または 11 文字のコードで、銀行コード (4 文字)、国コード (2 文字)、所在地コード (2 文字) および支店コード (任意設定、3 文字) で構成されています。
    ● swiftID – SWIFT (Society for Worldwide Interbank Financial Telecommunications) の ID (識別番号)
    ● bankBranchID – 銀行の支店の識別番号
    ● companyRegistrationNumber – 支払相手の会社の登録番号。

    銀行口座 ID は次のように指定します。

    説明
    identifier ドメイン内にある IdReference の一意の識別子です。
    domain 口座 ID のドメインです。使用可能な値は次のとおりです。
    ● abaRoutingNumber – ABA (American Banking Association) ルーティング番号
    ● swiftID – SWIFT (Society for Worldwide Interbank Financial Telecommunications) の ID (識別番号)
    ● chipsID – CHIPS (Clearing House Interbank Payment System) の ID (識別番号)
    ● isoBicID – ISO 9362 で指定されている ISO BIC ID (Bank Identifier Code)。Bank Identifier Code (BIC) は世界共通の金融機関識別方法です。BIC は 8 文字または 11 文字のコードで、銀行コード (4 文字)、国コード (2 文字)、所在地コード (2 文字) および支店コード (任意設定、3 文字) で構成されています。
    ● bankNationalID – 上記のどの銀行識別方法も適用できない場合は、bankNationalID を使用してその国に固有の銀行コードを指定します。このコードで、Contact に指定された国内の銀行を一意に識別できる必要があります。

    銀行の支店 ID は、必要に応じて次のように指定します。

    説明
    bankBranchID 銀行の支店 ID です。

    以下の表は、Contact および IdReference に有効な role 値と domain 値の一部の組み合わせを示しています。

    Contact@role IdReference@domain
    payer bankAccountID
    ibanID
    payee bankAccountID
    ibanID
    originatingBank abaRoutingNumber
    bankNationalID
    isoBicID
    swiftID
    bankBranchID (optional)
    receivingBank abaRoutingNumber
    bankNationalID
    isoBicID
    swiftID
    bankBranchID (optional)
    originatingCorrespondentBank abaRoutingNumber
    isoBicID
    swiftID
    receivingCorrespondentBank abaRoutingNumber
    isoBicID
    swiftID
    intermediaryBank abaRoutingNumber
    isoBicID
    swiftID
    Creator

    この IdReference の作成者 (United Parcel Service や Bank of America など) です。

    Description

    IdReference のテキスト形式の説明です。これは、受信者が Creator の値をすぐに理解できない場合に特に役立ちます。

    10.2.3.3 P カード

    カード番号や有効期限といった、P カードの情報を指定します。この要素を使用すると、バイヤー企業は請求書の承認後に P カードに請求することができます。P カードを指定した場合は、role=”payer” が設定された Contact を使用します。

    10.2.3.4 NatureOfBusiness

    会社が属している事業体または業界を指定します。会社の事業内容を説明します。データの種類は文字列であり、最大255 文字の任意の文字を使用できます。NatureOfBusiness の例を次に示します。

    <NatureOfBusiness>Manufacturing business</NatureOfBusiness>
    
    10.2.3.5 IncorporationType

    会社の種類を指定します。データの種類は文字列であり、最大 255 文字の任意の文字を使用できます。IncorporationType の例を次に示します。

    <IncorporationType>Corporation</IncorporationType>
    
    10.2.3.6 AccountCurrency

    支払相手に使用された口座通貨を示します。この要素には、次の属性があります。

    属性 説明
    code
    (必須)
    3 文字の ISO 4217 通貨コードを指定します。

    AccountCurrency の例については、「PaymentBatchRequest」を参照してください。

    10.2.4 PaymentTerms

    PaymentProposalRequest ドキュメントの支払条件を定義します。この要素には、次の属性があります。

    属性 説明
    paymentTermCode
    (必須)
    バイヤーのシステムで定義された支払条件コードです。

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

    要素 説明
    PaymentTerm 請求書またはオーダーの支払条件が定義されます。支払条件には、支払期間 (割引なし) または割引適用期間 (割引あり) を指定できます。「PaymentTerm」を参照してください。
    Description 支払条件の説明が含まれます。
    Extrinsic このオブジェクトに関連するすべての追加情報が含まれます。

    10.2.5 DiscountBasis

    DiscountBasis では、支払処理の割引基準が定義されます。以下の要素が含まれます。

    要素 説明
    Money
    (必須)
    割引基準の金額です。

    10.2.6 TaxAdjustment

    TaxAdjustment では、支払処理の税調整が定義されます。以下の要素が含まれます。

    要素 説明
    Money
    (必須)
    支払処理時に行われた合計税調整が記述されます。
    TaxAdjustmentDetail カテゴリおよび地域で行われた調整の詳細が定義されます。

    注記
    この要素は cXML 1.2.042 の PaymentProposalRequest ドキュメントで非推奨になりました。Tax.TaxAdjustmentAmount を代わりに使用してください。「」を参照してください。

    10.2.6.1 TaxAdjustmentDetail

    TaxAdjustmentDetail では、カテゴリおよび地域で行われた調整の詳細が定義されます。この要素には、次の属性があります。

    属性 説明
    category
    (必須)
    税調整カテゴリについて説明する文字列です。
    region 税調整が発生した地域について説明する文字列です。

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

    要素 説明
    Money
    (必須)
    特定のカテゴリまたは地域の支払処理で行われた税調整の金額です。

    注記
    この要素は cXML 1.2.042 の PaymentProposalRequest ドキュメントで非推奨になりました。TaxDetail.TaxAdjustmentAmount を代わりに使用してください。「TaxDetail」を参照してください。

    10.2.7 NetAmount

    正味金額。

    NetAmount = GrossAmount – DiscountAmount – AdjustAmount

    NetAmount が負である場合は、バイヤーに対する貸方を示します。この場合、ProposalID、operation、PayableInfo、および NetAmount を除く、PaymentProposalRequest のその他の属性およびサブ要素はすべて無視されます。

    10.3 PaymentRemittanceRequest

    PaymentRemittanceRequest ドキュメントは、支払いまたは送金のための送金詳細通知に相当します。次の例は、PaymentRemittanceRequest 要素の構造を示しています。

    <PaymentRemittanceRequest>
     <PaymentRemittanceRequestHeader>
     <PaymentMethod/>
     <PaymentPartner/>
     <PaymentReferenceInfo/>
     <PaymentPurpose/>
     <Comments/>
     <Extrinsic/>
     </PaymentRemittanceRequestHeader>
     <PaymentRemittanceSummary>
     <NetAmount/>
     <GrossAmount/>
     <DiscountAmount/>
     <AdjustmentAmount/>
     </PaymentRemittanceSummary>
     <RemittanceDetail>
     <PayableInfo/>
     <NetAmount/>
     <GrossAmount/>
     <DiscountAmount/>
     <AdjustmentAmount/>
     <Comments/>
     <Extrinsic/>
     </RemittanceDetail>
    </PaymentRemittanceRequest>
    

    PaymentRemittanceRequest には属性がありません。請求書用の PaymentRemittanceRequest の例については、「PaymentRemittanceRequest Example」を参照してください。

    10.3.1 PaymentRemittanceRequestHeader

    PaymentRemittanceRequestHeader 要素では、支払いまたは送金全体に適用するヘッダー情報が定義されます。次の例は、PaymentRemittanceRequestHeader の構造を示しています。

    <PaymentRemittanceRequestHeader>
     <PaymentMethod>
     <Description>
     <ShortName/>
     </Description>
     </PaymentMethod>
     <PaymentPartner>
     <Contact/>
     <IdReference/>
     <PCard/>
     </PaymentPartner>
     <PaymentReferenceInfo>
     <PaymentReference/>
     <DocumentReference/>
     </PaymentReferenceInfo>
     <PaymentPurpose/>
     <Comments/>
     <Extrinsic/>
    </PaymentRemittanceRequestHeader>
    

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

    属性 説明
    paymentRemittanceID
    (必須)
    この PaymentRemittance の一意の識別子です。バイヤー企業側のシステムで生成されます。
    paymentDate
    (必須)
    この支払取引または送金取引が作成された日時です。paymentDate は、実際のPaymentRemittanceRequest のタイムスタンプよりも前である必要があります。
    isPayment この要求が支払い目的のものか、単に送金通知なのかを示します。要求が支払い目的のものであれば、属性に “yes” を設定します。isPayment = yes が設定された PaymentRemittanceRequest には送金通知情報を含めることができます。
    isPayment が指定されていない場合、ドキュメントは送金通知とみなされます。
    paymentReferenceNumber 支払取引参照番号または支払識別番号を示します。例えば、小切手による支払いの場合は、paymentReferenceNumber は小切手番号に、電子支払いの場合は、電子参照番号または確認番号になります。
    status 支払送金の状況です。使用可能な値は “new” (通常の設定) または “void” です。
    companyCode バイヤーの会社コードです。

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

    要素 説明
    PaymentMethod
    (必須)
    支払方法を識別します。「PaymentMethod」を参照してください。
    PaymentPartner
    (必須)
    支払いに関連する組織を識別します。「PaymentPartner」を参照してください。
    PaymentReferenceInfo バイヤー企業によって行われた、以前の支払いの ID を定義します。「PaymentReferenceInfo」を参照してください。
    Comments この支払送金に関連付けられているコメントが含まれます。外部ファイルを含めるために Attachment 要素を含めることができます。
    Extrinsic このオブジェクトに関連する追加情報が含まれます。PaymentRemittanceRequestの情報を複製することはできません。
    10.3.1.1 PaymentReferenceInfo

    バイヤー企業によって行われた、以前の支払いの ID を定義します。バイヤー企業のシステムで行われた支払いを、この
    ID で一意に識別できる必要があります。PaymentReferenceInfo には属性がありません。

    PaymentReference

    以前の PaymentRemittanceRequest への参照。以前の支払いが cXML を使用して行われた場合は、この要素は必須です。PaymentReference には次の属性があります。

    属性 説明
    paymentRemittanceID 依頼の paymentRemittanceID。
    注記
    小切手番号などの取引識別番号は使用しないでください。
    paymentDate 支払日

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

    ● DocumentReference

    PaymentReference の DocumentReference 要素は、payloadID 属性が含まれています。これは、以前のPaymentRemittanceRequest を参照しています。DocumentReference には次の属性があります。

    属性 説明
    payloadID
    (必須)
    以前の PaymentRemittanceRequest の一意の識別子。payloadID は、PaymentRemittanceRequest の cXML 要素から直接コピーされます。
    PaymentIDInfo

    PaymentReference の PaymentIDInfo は、バイヤー企業のシステムにおけるこの支払いに対する一意の識別子を参照しています。PaymentIDInfo は、paymentRemittanceID および paymentDate 属性が含まれています。PaymentIDInfo には次の属性があります。

    属性 説明
    paymentRemittanceID
    (必須)
    依頼の paymentRemittanceID。
    注記
    小切手番号などの取引識別番号は使用しないでください。
    paymentDate 支払日
    10.3.1.2 PaymentPurpose

    たとえば、医療費の精算、給与などの支払いの目的を示します。この要素には、次の属性があります。

    属性 説明
    code
    (必須)
    支払い目的を表すコード。これは、支払い目的の国固有のコードである可能性があります。値 “other” は、代わりにフリーテキストの支払い目的が提供されることを示します。

    PaymentPurpose の例については、「PaymentBatchRequest」を参照してください。

    10.3.2 PaymentRemittanceSummary

    PaymentRemittanceSummary 要素では、PaymentRemittanceRequest の概要情報が定義されます。PaymentRemittanceSummary 要素にある各金額は、通貨と固定の金額で示されます。PaymentRemittanceSummary には属性がありません。

    10.3.2.1 NetAmount

    NetAmount 要素には、正味支払金額の合計が定義されます。NetAmount は次の式を満たしている必要があります。

    NetAmount = GrossAmount – DiscountAmount – AdjustmentAmount

    10.3.2.2 GrossAmount

    総額合計です。

    10.3.2.3 DiscountAmount

    割引金額合計です。

    10.3.2.4 AdjustmentAmount

    調整金額の合計です。

    10.3.3 RemittanceDetail

    RemittanceDetail 要素では、支払済みの特定の支払処理に関する送金の詳細が定義されます。RemittanceDetail 要素にある各金額は、通貨を伴うフラットな金額で表示されます。

    <RemittanceDetail>
     <PayableInfo/>
     <NetAmount/>
     <GrossAmount/>
     <DiscountAmount/>
     <AdjustmentAmount/>
     <Comments/>
     <Extrinsic/>
    </RemittanceDetail>
    

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

    属性 説明
    lineNumber
    (必須)
    関連する支払処理の明細番号です。
    referenceDocumentNumber 送金の詳細を表す外部ドキュメント番号 (文字列) です。
    paymentProposalID この請求書に関連する支払予定識別子 (文字列) です。

    以下に RemittanceDetail の例を示します。

    <RemittanceDetail lineNumber="1" referenceDocumentNumber="R0001"
     paymentProposalID="1234">
     <PayableInfo>
     <PayableInvoiceInfo>
     <InvoiceIDInfo invoiceDate="2015-11-02T12:00:01-08:00" invoiceID="i1003"></InvoiceIDInfo>
     </PayableInvoiceInfo>
     </PayableInfo>
     <NetAmount>
     <Money currency="USD">1000.00</Money>
     </NetAmount>
     <GrossAmount>
     <Money currency="USD">1000.00</Money>
     </GrossAmount>
     <DiscountAmount>
     <Money currency="USD">0.00</Money>
     </DiscountAmount>
     <AdjustmentAmount>
     <Money currency="USD">0.00</Money>
     <Modifications>
     <Modification>
     <AdditionalDeduction type="withholdingTax">
     <DeductionAmount>
     <Money currency="USD">200.00</Money>
     </DeductionAmount>
     </AdditionalDeduction>
     </Modification>
     </Modifications>
     </AdjustmentAmount>
    </RemittanceDetail>
    
    10.3.3.1 PayableInfo

    請求書、オーダー、または契約といった、支払処理対象ドキュメントの参照情報です。「PayableInfo」を参照してください。

    PayableInvoiceInfo

    支払いをする請求書の参照情報です。PayableInvoiceInfo には InvoiceReference または InvoiceIDInfoを含める必要があり、PayableOrderInfo または PayableMasterAgreementInfo が含まれる可能性があります。PayableInvoiceInfo には以下の要素が含まれます。

    要素 説明
    InvoiceReference 以前の InvoiceDetailRequest ドキュメントを明確に参照できるようにします。InvoiceReference は InvoiceDetailRequest メッセージからコピーされます。
    InvoiceIDInfo サプライヤのシステムで認識されている請求書の ID を定義します。InvoiceIDInfo には、以下の 2 つの属性があります。

    属性 説明
    invoiceID
    (必須)
    サプライヤのシステムで認識されている請求書の ID
    invoiceDate invoiceDate 請求書の日付
    PayableOrderInfo

    オーダーに関連する補足情報です。例えば、統合された請求書に対する支払いには関連するオーダー情報が含まれる場合があります。支払われたオーダーに関連した支払処理の情報を定義します。PayableOrderInfo には属性がありません。以下の要素が含まれます。

    要素 説明
    OrderReference 支払いをするオーダーの参照情報です。
    OrderIDInfo 購買アプリケーションによって割り当てられたオーダー ID です。
    PayableMasterAgreementInfo

    契約に関連した補足情報です。例えば、統合された請求書に対する支払いには関連する契約の情報が含まれる場合があります。支払いをする契約に関連した支払処理の情報を定義します。

    10.3.3.2 NetAmount

    この支払処理の詳細レベルの正味金額です。次の式で表されます。

    NetAmount = GrossAmount – DiscountAmount – AdjustmentAmount

    10.3.3.3 GrossAmount

    この支払処理の詳細レベルの支払いの総計です。

    10.3.3.4 DiscountAmount

    この支払処理の詳細レベルの割引情報です。

    10.3.3.5 AdjustmentAmount

    この支払処理に対するさまざまな調整金額の合計です (ある場合のみ)。調整金額は正の場合も負の場合もあります。正の場合は支払金額が減少し、負の場合は支払金額が増加します。たとえば、負の AdjustmentAmount で、支払遅延金やその他の違約金を表す場合があります。AdjustmentAmount には次の属性があります。

    属性 説明
    type 調整金額の種類 (“withholdingTax” など) です。

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

    要素 説明
    Money この支払処理をドル (またはその他の通貨) による金額で調整します。Modifications 要素内に複数の Modification 要素が含まれている場合は、Money = (すべてのAdditionalDeduction の合計) – (すべての AdditionalCost の合計) です。
    Description 調整をする理由です。
    Modifications AdjustmentAmount の詳細です。複数の Modification 要素を含めることができます。

    以下の例は、PaymentRemittanceRequest ドキュメントの AdjustmentAmount 要素と Comments 要素を示しています。控除の 1 つは、源泉徴収税 (type=”withholdingTax”) です。これは、支払明細の源泉徴収税額を示します。

    <AdjustmentAmount>
     <Money currency="USD">110.00</Money>
     <Modifications>
     <Modification>
     <AdditionalDeduction type="withholdingTax">
     <DeductionAmount>
     <Money currency="USD">95.00</Money>
     </DeductionAmount>
     </AdditionalDeduction>
     </Modification>
     <Modification>
     <AdditionalDeduction type="other">
     <DeductionAmount>
     <Money currency="USD">15.00</Money>
     </DeductionAmount>
     </AdditionalDeduction>
     </Modification>
     </Modifications>
    </AdjustmentAmount>
    <Comments>Tax Withheld</Comments>
    

    10.4 PaymentBatchRequest

    PaymentBatchRequest ドキュメントでは、バッチに含まれる支払バッチおよび支払送金が指定されます。次の例は、PaymentBatchRequest の構造を示しています。

    <PaymentBatchRequest>
     <PaymentBatchRequestHeader>
     <PaymentMethod/>
     <Extrinsic/>
     </PaymentBatchRequestHeader>
     <PaymentBatchSummary>
     <ControlSum/>
     <NumberOfPayments/>
     </PaymentBatchSummary>
     <PaymentRemittanceRequest>
     <PaymentRemittanceRequestHeader/>
     <PaymentRemittanceSummary/>
     <RemittanceDetail/>
     </PaymentRemittanceRequest>
    </PaymentBatchRequest>
    

    PaymentBatchRequest には属性がありません。以下に PaymentBatchRequest の例を示します。

    <Request deploymentMode="production">
     <PaymentBatchRequest>
     <PaymentBatchRequestHeader batchID="2016043001AP" paymentDate="2016-06-06T15:25:51-08:00" creationDate="2016-05-01T15:25:51-08:00">
     <PaymentMethod type="other">
     <Description xml:lang="en-US">
     <ShortName>aribapay</ShortName>
     </Description>
     </PaymentMethod>
     </PaymentBatchRequestHeader>
     <PaymentBatchSummary>
     <ControlSum>1000</ControlSum>
     <NumberOfPayments>1</NumberOfPayments>
     </PaymentBatchSummary>
     <PaymentRemittanceRequest>
     <PaymentRemittanceRequestHeader paymentReferenceNumber="p1003" paymentRemittanceID="4000009112" status="new" companyCode="12000" paymentDate="2016-06-02T12:00:01-08:00">
     <PaymentMethod type="other">
     <Description xml:lang="en-US">
     <ShortName>aribapay</ShortName>
     </Description>
     </PaymentMethod>
     <PaymentPartner>
     <Contact role="payer">
     <Name xml:lang="en">b11@company.com</Name>
     <PostalAddress>
     <Street>123 Main Street</Street>
     <City>Sunnyvale</City>
     <State isoStateCode="US-CA">CA</State>
     <PostalCode>94089</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     </PostalAddress>
     </Contact>
     <IdReference domain="bankAccountID" identifier="214109887"></IdReference>
     <AccountCurrency code="USD"/>
     </PaymentPartner>
     <PaymentPartner>
     <Contact role="payee">
     <Name xml:lang="en">s11@company.com</Name>
     <PostalAddress>
     <Street>601 108th Ave NE</Street>
     <City>Bellevue</City>
     <State isoStateCode="US-WA">WA</State>
     <PostalCode>98004</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     </PostalAddress>
     </Contact>
     <IdReference domain="NetworkID" identifier="AN02001670305"/>
     <IdReference domain="VendorID" identifier="1000"/>
     <IdReference domain="bankAccountID" identifier="393848477"></IdReference>
     <AccountCurrency code="USD"/>
     </PaymentPartner>
     <PaymentPartner>
     <Contact role="originatingBank">
     <Name xml:lang="en">OBank</Name>
     <PostalAddress>
     <Street>691 Random Ave</Street>
     <City>Sunnyvale</City>
     <State isoStateCode="US-CA">CA</State>
     <PostalCode>94300</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     </PostalAddress>
     </Contact>
     <IdReference domain="abaRoutingNumber" identifier="121000358"/>
     <IdReference domain="accountType" identifier="checking"/>
     <AccountCurrency code="USD"/>
     </PaymentPartner>
     <PaymentPartner>
     <Contact role="receivingBank">
     <Name xml:lang="en">RBank</Name>
     </Contact>
     <IdReference domain="abaRoutingNumber" identifier="121000358"/>
     <IdReference domain="accountType" identifier="Checking"/>
     <AccountCurrency code="USD"/>
     </PaymentPartner>
     <PaymentPurpose code="other">Salary for February 2020</PaymentPurpose>
     </PaymentRemittanceRequestHeader>
     <PaymentRemittanceSummary>
     <NetAmount><Money currency="USD">1000.00</Money></NetAmount>
     <GrossAmount><Money currency="USD">1000.00</Money></GrossAmount>
     <DiscountAmount><Money currency="USD">0.00</Money></DiscountAmount>
     <AdjustmentAmount>
     <Money currency="USD">0.00</Money>
     </AdjustmentAmount>
     </PaymentRemittanceSummary>
     <RemittanceDetail lineNumber="1" referenceDocumentNumber="R0001" paymentProposalID="1234">
     <PayableInfo>
     <PayableInvoiceInfo>
     <InvoiceIDInfo invoiceDate="2015-11-02T12:00:01-08:00" invoiceID="i1003"></InvoiceIDInfo>
     </PayableInvoiceInfo>
     </PayableInfo>
     <NetAmount><Money currency="USD">1000.00</Money></NetAmount>
     <GrossAmount><Money currency="USD">1000.00</Money></GrossAmount>
     <DiscountAmount><Money currency="USD">0.00</Money></DiscountAmount>
     <AdjustmentAmount><Money currency="USD">0.00</Money>
     <Modifications>
     <Modification>
     <AdditionalDeduction type="withholdingTax">
     <DeductionAmount>
     <Money currency="USD">200.00</Money>
     </DeductionAmount>
     </AdditionalDeduction>
     </Modification>
     </Modifications>
     </AdjustmentAmount>
     </RemittanceDetail>
     </PaymentRemittanceRequest>
     </PaymentBatchRequest>
    </Request>
    

    10.4.1 PaymentBatchRequestHeader

    PaymentBatchRequestHeader 要素では、PaymentBatchRequest のヘッダー情報が定義されます。この要素には、次の属性があります。

    属性 説明
    batchID
    (必須)
    バッチの一意の識別子です。
    paymentDate
    (必須)
    ネットワークハブで支払いが開始される日付です。この日付は、自動支払方法の支払いが保留されるようにバイヤーが設定されている場合にのみ有効です。それ以外の場合は、すぐに支払いが開始されます。
    creationDate
    (必須)
    この支払バッチが作成された日時です。

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

    要素 説明
    PaymentMethod バッチの支払方法です。存在する場合は、個別の支払送金ごとの支払方法が無視されます。「PaymentMethod」を参照してください。
    Extrinsic このオブジェクトに関連するすべての追加情報が含まれます。

    10.4.2 PaymentBatchSummary

    PaymentBatchRequest の概要情報が含まれます。

    10.4.2.1 ControlSum

    バッチの通貨を使用しない合計正味支払金額が含まれます。

    10.4.2.2 NumberOfPayments

    バッチ内の支払送金数が含まれます。

    10.4.3 PaymentRemittanceRequest

    支払いまたは送金に関する送金詳細通知が含まれます。「PaymentRemittanceRequest」を参照してください。

    10.5 PaymentRemittanceStatusUpdateRequest

    PaymentRemittanceStatusUpdateRequest ドキュメントでは、支払送金の状況情報が提供されます。バイヤー企業は、PaymentRemittanceStatusUpdateRequest ドキュメントをサプライヤに送信して、サプライヤに自分の支払処理の状況を通知します。PaymentRemittanceStatus 要素では、Extrinsic 要素がサポートされています。

    次の例は、PaymentRemittanceStatusUpdateRequest 要素の構造を示しています。

    <Request>
     <PaymentRemittanceStatusUpdateRequest>
     <DocumentReference>
     .....
     </DocumentReference>
     <PaymentRemittanceStatus>
     ....
     <Extrinsic name="OriginalSupplierAccountNumber">4232334545</Extrinsic>
     <Extrinsic name="CorrectedSupplierAccountNumber">004232334545</Extrinsic>
     <Extrinsic name="OriginalSupplierBankAbaNumber">121000358</Extrinsic>
     <Extrinsic name="CorrectedSupplierBankAbaNumber">221000358</Extrinsic>
     </PaymentRemittanceStatusUpdateRequest>
     ....
     </PaymentRemittanceStatus>
     </PaymentRemittanceStatusUpdateRequest>
    <Request>
    

    10.5.1 DocumentReference

    DocumentReference 要素は、状況の更新を特定の PaymentRemittanceRequest ドキュメントと関連付ける payloadID が含まれています。DocumentReference では、前回のドキュメントの必須属性が繰り返され、サプライヤで生成された任意設定の識別子が 1 つ追加されます。

    例:

    <DocumentReference payloadID="0c300508b7863dcclb_14999"/>
    

    DocumentReference には要素は含まれませんが、次の属性があります。

    属性 説明
    payloadID
    (必須)
    ドキュメントの一意の識別子。以前の PaymentRemittanceRequest の cXML 要素から直接コピーされます。

    10.5.2 PaymentRemittanceStatus

    既存の PaymentRemittanceRequest で指定される支払取引の状況が定義されます。PaymentRemittanceStatus には次の属性があります。

    属性 説明
    type
    (必須)
    支払取引の状況タイプ。
    paymentReferenceNumber 支払いの一意の番号を示します。たとえば、小切手による支払いの場合、paymentReferenceNumber には小切手番号が使用されます。

    PaymentRemittanceStatus の type 属性に指定できる値は、次のとおりです。

    説明
    paying 支払取引の処理中です。
    paid 支払取引が正常に終了しました。
    failed 支払取引が失敗しました。特定の条件下では、種類が “failed” の PaymentRemittanceは、バイヤー企業が再送信できます。
    canceled 支払取引がキャンセルされました。
    10.5.2.1 PaymentRemittanceStatusDetail

    既存の PaymentremittanceStatusDetail で指定される支払取引状況の詳細が定義されます。PaymentRemittanceStatusDetail には PCDATA 文字列が含まれています。通常、この要素には問題が具体的に説明されています。PaymentRemittanceStatusDetail には次の属性があります。

    属性 説明
    code
    (必須)
    支払プロバイダが提供する支払取引状況コード
    description
    (必須)
    状況コードの説明文 (個別の問題の説明ではありません)
    xml:lang
    (必須)
    テキスト属性および要素の内容で使用される言語
    10.5.2.2 Extrinsic

    Extrinsic 要素リストを使用すると、追加データを挿入できます。これらの要素には、受信側のシステムのワークフローに影響する、事前定義されたキーワードや値を組み込むことができます。
    Extrinsic リスト内の要素に順序の制限はありません。

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

    属性 説明
    name
    (必須)
    データの種類や特性を示すために使用される値です。

    10.6 支払ドキュメントの例

    次の例では、支払ドキュメントについて説明します。

    10.6.1 PaymentProposalRequest の例

    次の支払予定は、ACH 支払用です。

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE cXML SYSTEM "http://xml.cXML.org/schemas/cXML/1.2.014/PaymentRemittance.dtd">
    <cXML payloadID="123@bigbuyer.com" timestamp="2005-04-20T23:59:45-07:00">
     <Header>
     <From>
     <Credential domain=”NetworkId”>
     <Identity>AN99123456789</Identity>
     </Credential>
     </From>
     <To>
     <Credential domain=”NetworkId”>
     <Identity>AN99987654321</Identity>
     </Credential>
     </To>
     <Sender>
     <Credential domain=”NetworkId”>
     <Identity>AN99123456789</Identity>
     <SharedSecret>abracadabra</SharedSecret>
     </Credential>
     <UserAgent>Procurement Application 1.0</UserAgent>
     </Sender>
     </Header>
     <Request>
     <PaymentProposalRequest ProposalID="proposal123" operation="new" paymentDate="2005-07-20T23:59:20-07:00">
     <PayableInfo>
     <PayableInvoiceInfo>
     <InvoiceReference invoiceID="ABC">
     <DocumentReference payloadID="25510.10.81.231"/>
     </InvoiceReference>
     <PayableOrderInfo>
     <OrderReference orderID="DEF">
     <DocumentReference payloadID="25510.10.81.002"/>
     </OrderReference>
     </PayableOrderInfo>
     </PayableInvoiceInfo>
     </PayableInfo>
     <PaymentMethod type="ach"/>
     <Contact role="remitTo" addressID="Billing">
     <Name xml:lang="en">Lisa Dollar</Name>
     <PostalAddress name="billing department">
     <DeliverTo>Lisa Dollar</DeliverTo>
     <Street>100 Castro Street</Street>
     <City>Mountain View</City>
     <State isoStateCode="US-CA">CA</State>
     <PostalCode>95035</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     </PostalAddress>
     <Email name="default">ldollar@workchairs.com</Email>
     <Phone name="work">
     <TelephoneNumber>
     <CountryCode isoCountryCode="US">1</CountryCode>
     <AreaOrCityCode>650</AreaOrCityCode>
     <Number>9990000</Number>
     </TelephoneNumber>
     </Phone>
     </Contact>
     <GrossAmount>
     <Money currency="USD">3000.00</Money>
     </GrossAmount>
     <DiscountAmount>
     <Money currency="USD">160.00</Money>
     </DiscountAmount>
     <AdjustmentAmount>
     <Money currency="USD">30.00</Money>
     </AdjustmentAmount>
     <NetAmount>
     <Money currency="USD">2810.00</Money>
     </NetAmount>
     </PaymentProposalRequest>
     </Request>
    </cXML>
    

    次の支払予定では、割引基準と税額が渡されます。

    <PaymentProposalRequest paymentProposalID="1100000124" operation="new" paymentDate="2016-04-05T11:59:20-07:00">
     <PayableInfo>
     <PayableInvoiceInfo>
     <InvoiceIDInfo invoiceID="INV8291087" invoiceDate="2016-04-01T18:31:35+05:30"></InvoiceIDInfo>
     </PayableInvoiceInfo>
     </PayableInfo>
     <PaymentMethod type="ach"></PaymentMethod>
     <GrossAmount>
     <Money currency="USD">13440</Money>
     </GrossAmount>
     <DiscountBasis>
     <Money currency="USD">12000</Money>
     </DiscountBasis>
     <DiscountAmount>
     <Money currency="USD">1200</Money>
     </DiscountAmount>
     <AdjustmentAmount>
     <Money currency="USD">0</Money>
     </AdjustmentAmount>
     <Tax>
     <Money currency="USD">100</Money>
     <TaxAdjustmentAmount>
     <Money currency="USD">7.00</Money>
     </TaxAdjustmentAmount>
     <Description xml:lang="en">Tax Summary</Description>
     <TaxDetail category="gst" percentageRate="50" purpose="tax">
     <TaxableAmount>
     <Money currency="USD">100</Money>
     </TaxableAmount>
     <TaxAmount>
     <Money currency="USD">50</Money>
     </TaxAmount>
     <TaxLocation xml:lang="en">CA</TaxLocation>
     <TaxAdjustmentAmount>
     <Money currency="USD">3.50</Money>
     </TaxAdjustmentAmount>
     <Description xml:lang="en">Goods and Services Tax</Description>
     </TaxDetail>
     <TaxDetail category="hst" percentageRate="20" purpose="tax">
     <TaxAmount>
     <Money currency="USD">50</Money>
     </TaxAmount>
     <TaxLocation xml:lang="en">CA</TaxLocation>
     <Description xml:lang="en">Services Tax</Description>
     </TaxDetail>
     <TaxDetail category="gst" percentageRate="50" purpose="tax">
     <TaxableAmount>
     <Money currency="USD">100</Money>
     </TaxableAmount>
     <TaxAmount>
     <Money currency="USD">50</Money>
     </TaxAmount>
     <TaxLocation xml:lang="en">CA</TaxLocation>
     <TaxAdjustmentAmount>
     <Money currency="USD">3.50</Money>
     </TaxAdjustmentAmount>
     <Description xml:lang="en">Goods and Services Tax</Description>
     </TaxDetail>
     </Tax>
     <NetAmount>
     <Money currency="USD">12180</Money>
     </NetAmount>
     <Extrinsic name="Scheduling"></Extrinsic>
     <Extrinsic name="Scheduled">yes</Extrinsic>
     <Extrinsic name="immediatepay">yes</Extrinsic>
    </PaymentProposalRequest>
    

    10.6.2 PaymentRemittanceRequest の例

    この例は、最小限の有効な PaymentRemittanceRequest を示しています。

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE cXML SYSTEM "http://xml.cXML.org/schemas/cXML/1.2.014/PaymentRemittance.dtd">
    <cXML xml:lang="en-US" timestamp="2004-03-10T14:20:53-08:00" payloadID="PR-031004-01">
     <Header>
     <From>
     <Credential domain=”NetworkId”>
     <Identity>AN99123456789</Identity>
     </Credential>
     </From>
     <To>
     <Credential domain=”NetworkId”>
     <Identity>AN99987654321</Identity>
     </Credential>
     </To>
     <Sender>
     <Credential domain=”NetworkId”>
     <Identity>AN99123456789</Identity>
     </Credential>
     <UserAgent>Procurement Application 1.0</UserAgent>
     </Sender>
     </Header>
     <Request deploymentMode="production">
     <PaymentRemittanceRequest>
     <PaymentRemittanceRequestHeader paymentDate="2004-10-10T00:00:00-08:00" paymentReferenceNumber="ACH123456789" paymentRemittanceID="PR-031204-01">
     <PaymentMethod type="ach"></PaymentMethod>
     <PaymentPartner>
     <Contact role="payer">
     <Name xml:lang="en">buyer</Name>
     <PostalAddress>
     <Street>100 1st Street</Street>
     <City>Anywhere</City>
     <State isoStateCode="US-CA">CA</State>
     <PostalCode>94089</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     </PostalAddress>
     </Contact>
     </PaymentPartner>
     <PaymentPartner>
     <Contact role="payee">
     <Name xml:lang="en">Supplier</Name>
     <PostalAddress>
     <Street>100 Main Street</Street>
     <City>Anywhere</City>
     <State isoStateCode="US-CA">CA</State>
     <PostalCode>94089</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     </PostalAddress>
     </Contact>
     </PaymentPartner>
     <PaymentPartner>
     <Contact role="originatingBank">
     <Name xml:lang="en">Moose Credit Union</Name>
     <PostalAddress>
     <Street>100 Elk Drive</Street>
     <City>Mooseville</City>
     <State isoStateCode="US-CA">CA</State>
     <PostalCode>94087</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     </PostalAddress>
     </Contact>
     <IdReference domain="abaRoutingNumber" identifier="234567890"></IdReference>
     </PaymentPartner>
     <PaymentPartner>
     <Contact role="receivingBank">
     <Name xml:lang="en">Gold Rush Bank</Name>
     <PostalAddress>
     <Street>100 Bret Harte Road</Street>
     <City>Gold Rush</City>
     <State isoStateCode="US-CA">CA</State>
     <PostalCode>97123</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     </PostalAddress>
     </Contact>
     <IdReference domain="abaRoutingNumber" identifier="678902345"></IdReference>
     </PaymentPartner>
     </PaymentRemittanceRequestHeader>
     <PaymentRemittanceSummary>
     <NetAmount>
     <Money currency="USD">2.00</Money>
     </NetAmount>
     <GrossAmount>
     <Money currency="USD">2.85</Money>
     </GrossAmount>
     <DiscountAmount>
     <Money currency="USD">0.35</Money>
     </DiscountAmount>
     <AdjustmentAmount>
     <Money currency="USD">0.50</Money>
     </AdjustmentAmount>
     </PaymentRemittanceSummary>
     <RemittanceDetail lineNumber="1">
     <PayableInfo>
     <PayableInvoiceInfo>
     <InvoiceIDInfo invoiceID="INV-031204-01">
     </InvoiceIDInfo>
     <PayableOrderInfo>
     <OrderIDInfo orderID="P0-031204-01"></OrderIDInfo>
     </PayableOrderInfo>
     </PayableInvoiceInfo>
     </PayableInfo>
     <NetAmount>
     <Money currency="USD">2.00</Money>
     </NetAmount>
     <GrossAmount>
     <Money currency="USD">2.85</Money>
     </GrossAmount>
     <DiscountAmount>
     <Money currency="USD">0.35</Money>
     </DiscountAmount>
     <AdjustmentAmount>
     <Money currency="USD">0.50</Money>
     </AdjustmentAmount>
     </RemittanceDetail>
     </PaymentRemittanceRequest>
     </Request>
    </cXML>
    

    10.6.3 PaymentRemittanceStatusUpdateRequest の例

    次の例は、バイヤーからサプライヤに送信される PaymentRemittanceStatusUpdateRequest を示しています。

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE cXML SYSTEM "http://xml.cXML.org/schemas/cXML/1.2.014/PaymentRemittance.dtd">
    <cXML payloadID="1068173501644--6417095366782271471@10.10.13.124" timestamp="2003-04-20T23:59:45-07:00">
     <Header>
     <From>
     <Credential domain=”NetworkId”>
     <Identity>AN99123456789</Identity>
     </Credential>
     </From>
     <To>
     <Credential domain=”NetworkId”>
     <Identity>AN99987654321</Identity>
     </Credential>
     </To>
     <Sender>
     <Credential domain=”NetworkId”>
     <Identity>Procurement Application 1.0</Identity>
     </Credential>
     </Sender>
     </Header>
     <Request deploymentMode="production">
     <PaymentRemittanceStatusUpdateRequest>
     <DocumentReference payloadID="1234567890123-1234567890123456789@10.10.10.100">
     </DocumentReference>
     <PaymentRemittanceStatus type="canceled"
     paymentReferenceNumber="PaymentRefNumber">1234</
     </PaymentRemittanceStatus>
     </PaymentRemittanceStatusUpdateRequest>
     </Request>
    </cXML>
    

    10.7 TradeRequest

    サプライチェーンファイナンス TradeItem オブジェクトを作成または更新するための申請を表します。TradeRequest ドキュメントは、サプライチェーンファイナンスのプロバイダの交渉プラットフォームで交渉されるPaymentProposalRequest ドキュメントに関連付けられています。支払予定は、TradeRequestHeader のautoTrade 属性で示されているように、自動的に交渉されるか、または手動で交渉することができます。TradeRequest ドキュメントは、サプライチェーンファイナンスのプロバイダからネットワークハブに移動します。更新されたPaymentProposalRequest ドキュメントは、次にネットワークハブによって生成され、必要に応じてバイヤーとサプライヤに送信されます。
    TradeRequest ドキュメントの基本構造は次のとおりです。

    ● TradeRequestHeader – バイヤー、サプライヤ、およびサードパーティ資金提供者を示します。
    ● TradeRequestSummary – 支払予定の元の値、クレジットと費用、および交渉金額を示します。
    ● TradeItem 要素 – サードパーティ資金提供者に対して交渉された特定の買掛金を示します。

    TradeRequest ドキュメントの例を次に示します。

    <TradeRequest>
     <TradeRequestHeader operation="new" status=”accepted” tradeID="trade200922" tradeDate="2015-09-30T10:43:36-07:00" tradeApprovedDate="2015-09-30T12:43:36-07:00" settlementDate="2015-10-02T10:43:36-07:00" autoTrade="no">
     <PaymentPartner>
     <!—Funder information-->
     <Contact role="payer">
     <Name xml:lang="en">Bank Of America</Name>
     <IdReference domain="financialInstitutionID" identifier="987654321">
     </IdReference>
     </Contact>
     </PaymentPartner>
     <PaymentPartner>
     <!-- supplier information -->
     <Contact role="payee">
     <Name xml:lang="en">Supplier Name</Name>
     </Contact>
     </PaymentPartner>
     <Contact>
     <Name xml:lang = "en">John Smith</Name>
     <Phone> <!—optional -->
     <TelephoneNumber>
     <CountryCode isoCountryCode = "BE">32</CountryCode>
     <AreaOrCityCode/>
     <Number>0477 07 26 41</Number>
     </TelephoneNumber>
     </Phone>
     </Contact>
     <Comments>Optional comments</Comments>
     </TradeRequestHeader>
     <TradeRequestSummary>
     <!— trade level totals -->
     <OriginalAmount> <!— sum of all OriginalAmount of all TradeItems -->
     <Money currency="USD">1000</Money>
     </OriginalAmount>
     <CreditApplied> <!— sum of all credit applied of all TradeItems -->
     <Money currency="USD">100</Money>
     </CreditApplied >
     <FeeAmount> <!-- total fee -->
     <Money currency="USD">20</Money>
     </FeeAmount >
     <Amount > <!-- total projected amount to be paid to supplier -->
     <Money currency="USD">880</Money>
     </Amount >
     </TradeRequestSummary>
     <TradeItem lineNumber=”1” paymentProposalID="PPR910" maturityDate="2015-04-30T10:43:36-07:00">
     <PayableInfo>
     <PayableInvoiceInfo>
     <InvoiceIDInfo invoiceDate="2015-03-30T10:43:36-07:00" invoiceID="330inv1"></InvoiceIDInfo>
     </PayableInvoiceInfo>
     </PayableInfo>
     <OriginalAmount > <!-- payment amount of the original PPR -->
     <Money currency="USD">1000</Money>
     </OriginalAmount >
     <AdjustmentAmount>
     <Money currency="USD">100.00</Money>
     <Modifications>
     <Modification>
     <AdditionalDeduction type="creditApplied">
     <DeductionAmount>
     <Money currency="USD">100.00</Money>
     </DeductionAmount>
     </AdditionalDeduction>
     </Modification>
     </Modifications>
     </AdjustmentAmount>
     <DaysPaidEarly>10</DaysPaidEarly>
     <Amount> <!-- trade amount: GrossAmount - AdjustmentAmount - FeeAmount-->
     <Money currency="USD">900</Money>
     </Amount >
     <!-- fee information, optional and not in credit memo -->
     <FeeAmount>
     <Money currency="USD">15.00</Money> <!-- total fee -->
     <Fee type="serviceProvider">
     <Money currency="USD">5.00</Money>
     </Fee>
     <Fee type="community">
     <Money currency="USD">5.00</Money>
     </Fee>
     <Fee type="funder">
     <Money currency="USD">5.00</Money>
     </Fee>
     </FeeAmount>
     </TradeItem>
     <TradeItem lineNumber="2" paymentProposalID="PPR911" maturityDate="2015-04-30T10:43:36-07:00"> <!-- credit memo -->
     <PayableInfo>
     <PayableInvoiceInfo>
     <InvoiceIDInfo invoiceDate="2015-03-30T10:43:36-07:00" invoiceID="cm123"></InvoiceIDInfo>
     </PayableInvoiceInfo>
     </PayableInfo>
     <OriginalAmount>
     <Money currency="USD">-100</Money>
     </OriginalAmount>
     <AdjustmentAmount>
     <Money currency="USD">-100.00</Money>
     <Modifications>
     <Modification>
     <AdditionalDeduction type="creditApplied">
     <DeductionAmount>
     <Money currency="USD">-100.00</Money>
     </DeductionAmount>
     </AdditionalDeduction>
     </Modification>
     </Modifications>
     </AdjustmentAmount>
     <DaysPaidEarly>0</DaysPaidEarly>
     <Amount>
     <Money currency="USD">0</Money>
     </Amount>
     </TradeItem>
    </TradeRequest>
    

    10.7.1 TradeRequestHeader

    TradeRequest オブジェクトのヘッダー情報が含まれます。この要素には、次の属性があります。

    属性 説明
    operation
    (必須)
    交渉ドキュメントの動作モードです。使用可能な値は “new” または “update” です。
    status
    (必須)
    TradeRequest の状況です。使用可能な値は次のとおりです。
    ● accepted – 資金提供者が交渉依頼を承認しました。
    ● rejected – 資金提供者が交渉依頼を却下しました。資金提供者は、後で状況を”accepted” に更新する場合があります。
    tradeID
    (必須)
    サプライチェーンファイナンスプロバイダシステムの交渉取引の ID です。
    tradeDate 交渉が作成された日時です。
    tradeApprovedDate 交渉が資金提供者によって承認された日時です。
    settlementDate サプライヤの銀行口座で支払いが行われた日時です。
    autoTrade 自動交渉であるのかどうか (“yes” または “no”) を示します。

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

    要素 説明
    PaymentPartner
    (必須)
    支払元と支払先の情報が含まれます。支払元は必須です。複数の PaymentPartner要素を指定できます。「PaymentPartner」を参照してください。
    Contact この TradeRequest を作成したサプライヤユーザーです。
    Comments この TradeRequest に関するテキスト形式のコメントです。
    Extrinsic この支払いに関連する追加情報です。TradeRequest では何も重複しないようにしてください。

    10.7.2 TradeRequestSummary

    TradeRequest オブジェクトの概要情報が含まれます。以下の要素が含まれます。

    要素 説明
    OriginalAmount
    (必須)
    元の正味支払の合計金額です。すべての TradeItem オブジェクトの金額をすべて加算すると、TradeRequestSummary の合計になります。
    CreditApplied 交渉のすべてのクレジットメモの合計金額です。
    FeeAmount
    (必須)
    この早期支払を受け取るためにサプライヤが行う必要がある交渉時に発生するすべての料金の合計が含まれます。これは、TradeItem オブジェクト内のすべての FeeAmount 要素の合計と等しい必要があります。
    Amount
    (必須)
    交渉の合計正味金額です。これは、サプライヤに支払われる見込み金額です。TradeItem オブジェクトの NetAmount 値の合計と等しく、次の式を満たしている必要があります。

    Amount = OriginalAmount – FeeAmount

    10.7.3 TradeItem

    支払予定またはクレジットメモに関する交渉情報が含まれます。この要素には、次の属性があります。

    属性 説明
    lineNumber 関連する支払処理ドキュメントからの交渉項目の明細番号です。
    paymentProposalID
    (必須)
    元の支払予定番号です。
    maturityDate 交渉項目の支払予定の満期です。

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

    要素 説明
    PayableInfo
    (必須)
    請求書、オーダー、または契約といった、支払処理対象ドキュメントの参照情報です。
    OriginalAmount
    (必須)
    この支払の元の金額です。クレジットメモ品目の場合、この金額は負です。
    AdjustmentAmount GrossAmount に適用される調整金額です。適用できる調整は、種類が”creditMemoApplied” の AdditionalDeduction を含むクレジットメモだけです。
    DaysPaidEarly
    (必須)
    サプライヤに早期に支払われる日数です。
    Amount
    (必須)
    この交渉項目の正味金額です。クレジットメモ品目の場合、この金額は常にゼロです。この金額は、次の式を満たしている必要があります。

    Amount = OriginalAmount – FeeAmount – AdjustmentAmount

    FeeAmount 交渉時に発生する各種料金が含まれます。
    FeeAmount には以下の要素が含まれます。

    ● Money – 料金の金額です。
    ● Fee – さまざまな種類の個別料金です。Fee の任意の type 属性には、次の値のいずれかを指定できます。
    ○ serviceProvider
    ○ community
    ○ funder

    Extrinsic このオブジェクトに関連する追加情報が含まれます。

    10.8 PaymentReceiptConfirmDtionRequest

    サプライヤからバイヤーに送信される支払領収書確認依頼を定義します。これにより、支払領収書確認依頼がバイヤーに送信され、支払相手の詳細、サプライヤの税 ID、バイヤーの税 ID、ドキュメント提出方法などの支払いに関する情報が提供されます。このドキュメントは、バイヤーの ProfileResponse で指定されている場所に送信される必要があります。支払領収書は、特定の税務当局 (メキシコの税務当局 (SAT) など) によって定義されます。サプライヤは、分割払いでの支払受領時または請求日後に支払いを受領する際に、支払領収書を発行する必要があります。
    PaymentReceiptConfirmationRequest には以下の要素が含まれます。

    要素 説明
    PaymentReceiptConfirmationRequestHeader
    (必須)
    サプライヤまたはコントラクタによる支払いの受領を確認するためにバイヤーに送信される、PaymentReceiptConfirmationRequest のヘッダーです。「PaymentReceiptConfirmDtionRequestHeDder」を参照してください。
    PaymentReceiptDetails
    (必須)
    完了した支払いに関連付けられている領収書の詳細情報が含まれます。「PaymentReceiptDetails」を参照してください。
    PaymentReceiptSummary
    (必須)
    完了した支払いの概要が含まれます。「PaymentReceiptSummary」を参照してください。
    Extrinsic 支払領収書の提出方法や分類コードなどの国固有の情報を含む、PaymentReceiptConfirmationRequest に関する追加情報が含まれます。

    PaymentReceiptConfirmationRequest の例を次に示します。

    <Request deploymentMode="test">
     <PaymentReceiptConfirmationRequest>
     <PaymentReceiptConfirmationRequestHeader issuedDate="2019-01-27T12:00:00+05:30" paymentReceiptID="gem-inv-01-028-006" paymentReceivedDate="2018-11-09T12:00:00" >
     <paymentMethod type="03" />
     <PaymentPartner>
     <Contact role="payee">
     <Name xml:lang="en">Buyer</Name>
     <PostalAddress>
     <Street>100 Supplier12 Way</Street>
     <City>Fremont</City>
     <State isoStateCode="US-CA">CA</State>
     <PostalCode>99999</PostalCode>
     <Country isoCountryCode="MX">Mexico</Country>
     </PostalAddress>
     </Contact>
     <IdReference domain="bankAccountID" identifier="0447428774"/>
     <IdReference domain="taxID" identifier="AAA010101AAA"/>
     </PaymentPartner>
     <PaymentPartner>
     <Contact role="payer">
     <Name xml:lang="en">Buyer</Name>
     <PostalAddress>
     <Street>100 Buyer Way</Street>
     <City>Fremont</City>
     <State isoStateCode="US-CA">CA</State>
     <PostalCode>99999</PostalCode>
     <Country isoCountryCode="MX">Mexico</Country>
     </PostalAddress>
     </Contact>
     <IdReference domain="bankAccountID" identifier="179610679"/>
     <IdReference domain="taxID" identifier="PRO86050267A"/>
     </PaymentPartner>
     <PaymentPartner>
     <Contact role="originatingBank">
     <Name xml:lang="en">Buyer's Bank</Name>
     <PostalAddress>
     <Street>100 Way</Street>
     <City>Fremont</City>
     <State isoStateCode="US-CA">CA</State>
     <PostalCode>99999</PostalCode>
     <Country isoCountryCode="MX">Mexico</Country>
     </PostalAddress>
     </Contact>
     <IdReference domain="taxID" identifier="GB179610679"/>
     </PaymentPartner>
     <PaymentPartner>
     <Contact role="receivingBank">
     <Name xml:lang="en">Supplier's Bank</Name>
     <PostalAddress>
     <Street>100 Way</Street>
     <City>Fremont</City>
     <State isoStateCode="US-CA">CA</State>
     <PostalCode>99999</PostalCode>
     <Country isoCountryCode="MX">Mexico</Country>
     </PostalAddress>
     </Contact>
     <IdReference domain="taxID" identifier="GB179610679"/>
     </PaymentPartner>
     <Extrinsic name="paymentReceiptSubmissionMethod">LegalDocumentViaXML
     </Extrinsic>
     <Extrinsic name="taxRegime">601</Extrinsic>
     <Extrinsic name="serviceCode">
     <Classification domain="CFDI">G01</Classification>
     </Extrinsic>
     <Extrinsic name="paymentReceiptUUID">5DB00B0E-7E57-4EFD-8B42-68CA7B80D6AC
     </Extrinsic>
     </PaymentReceiptConfirmationRequestHeader>
     <PaymentReceiptDetails>
     <PaymentReceiptItem paymentLineNumber="1" installmentNumber="1" >
     <PaymentDetails >
     <PaymentAmount>
     <Money currency="MXN">88305.94</Money>
     </PaymentAmount>
     <PreviousBalance>
     <Money currency="MXN">00.00</Money>
     </PreviousBalance>
     <PresentBalance>
     <Money currency="MXN">00.00</Money>
     </PresentBalance>
     </PaymentDetails>
     <ReferenceDocumentInfo documentType="invoice" >
     <DocumentIdInfo documentID="invoice_123"></DocumentIdInfo>
     </ReferenceDocumentInfo>
     <Extrinsic name="refDocumentExchangeRate" ></Extrinsic>
     <Extrinsic name="refDocumentPaymentMethod" >PPD</Extrinsic>
     </PaymentReceiptItem>
     <PaymentReceiptItem paymentLineNumber="1" >
     <PaymentDetails >
     <PaymentAmount>
     <Money currency="MXN">88305.94</Money>
     </PaymentAmount>
     </PaymentDetails>
     <ReferenceDocumentInfo documentType="invoice" >
     <DocumentIdInfo documentID="invoice_123"></DocumentIdInfo>
     </ReferenceDocumentInfo>
     <Extrinsic name="refDocumentExchangeRate" ></Extrinsic>
     <Extrinsic name="refDocumentPaymentMethod" >PPD</Extrinsic>
     </PaymentReceiptItem>
     </PaymentReceiptDetails>
     <PaymentReceiptSummary>
     <NetAmount>
     <Money currency="MXN">88305.94</Money>
     </NetAmount>
     </PaymentReceiptSummary>
     <Extrinsic name="paymentChain"></Extrinsic>
     <Extrinsic name="paymentVoucher"></Extrinsic>
     </PaymentReceiptConfirmationRequest>
    </Request>
    

    10.8.1 PaymentReceiptConfirmationRequestHeader

    PaymentReceiptConfirmationRequest のヘッダーを定義します。この要素には、次の属性があります。

    属性 説明
    paymentReceiptID
    (必須)
    サプライヤが生成する支払領収書の識別子です。
    issuedDate
    (必須)
    この支払領収書が作成された日時です。
    paymentReceivedDate
    (必須)
    支払先が支払いを受領した日時です。
    paymentReferenceNumber 支払取引参照番号または支払識別番号を示します。たとえば、小切手による支払いの場合、paymentReferenceNumber は小切手番号、電子支払いの場合は電子参照番号または確認番号となります。

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

    要素 説明
    PaymentMethod 支払いに使用される支払方法です。
    PaymentPartner
    (必須)
    支払元 (バイヤーユーザー) および支払先 (サプライヤユーザー)、送金元銀行、および送金先銀行の連絡先詳細です。
    Comments この PaymentReceiptConfirmDtionRequest に関連付られているコメントが含まれます。
    Extrinsic PaymentReceiptConfirmationRequest に関連する追加情報が含まれます。PaymentReceiptConfirmDtionRequest の内容と重複しないようにしてください。

    10.8.2 PaymentReceiptDetails

    PaymentReceiptItem 要素が含まれます。各 PaymentReceiptItem が 1 つの請求書または支払送金ドキュメントに対応します。PaymentReceiptDetails には以下の要素が含まれます。

    要素 説明
    PaymentReceiptItem 支払いが行われる個別請求書の詳細が含まれます。「PaymentReceiptItem」を参照してください。
    10.8.2.1 PaymentReceiptItem

    支払いが行われる個別請求書の詳細が含まれます。この要素には、次の属性があります。

    属性 説明
    paymentLineNumber
    (必須)
    支払領収書ドキュメントの支払いの明細番号です。
    installmentNumber 支払番号の分割番号です。

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

    要素 説明
    PaymentDetails
    (必須)
    支払いの詳細が含まれます。「PaymentDetails」を参照してください。
    ReferenceDocumentInfo
    (必須)
    支払いが行われる参照ドキュメントの詳細が含まれます。「ReferenceDocumentInfo」を参照してください。
    Extrinsic PaymentReceiptItem に関する追加情報 (国固有の情報など) が含まれます。
    10.8.2.1.1 PaymentDetails

    支払いの詳細が含まれます。以下の要素が含まれます。

    要素 説明
    PaymentAmount
    (必須)
    支払領収書の支払金額です。「PaymentAmount」を参照してください。
    PreviousBalance この支払いを行う前に支払われる残高金額です。「PreviousBalance」を参照してください。
    PresentBalance 後で支払われる残高金額です。「PresentBalance」を参照してください。
    Extrinsic PaymentDetails に関する追加情報 (国固有の情報など) が含まれます。
    10.8.2.1.1.1 PaymentAmount

    支払領収書の支払金額が含まれます。PaymentAmount の例を次に示します。

    <PaymentAmount>
     <Money currency="MXN">88305.94</Money>
    </PaymentAmount>
    
    10.8.2.1.1.2 PreviousBalance

    この支払いを行う前に支払われる残高金額が含まれます。以下に、メキシコペソでの PreviousBalance 要素の例を示します。

    <PreviousBalance>
     <Money currency="MXN">250.00</Money>
    </PreviousBalance>
    
    10.8.2.1.1.3 PresentBalance

    後で支払われる残高金額が含まれます。
    以下に、PresentBalance がゼロの場合の例を示します。

    <PresentBalance>
     <Money currency="MXN">00.00</Money>
    </PresentBalance>
    

    10.8.3 PaymentReceiptSummary

    支払金額詳細の概要が含まれます。以下の要素が含まれます。

    要素 説明
    NetAmount
    (必須)
    支払領収書によって支払われた正味金額が含まれます。
    Extrinsic PaymentReceiptSummary に関する追加情報 (国固有の情報など) が含まれます。

    PaymentReceiptSummary の例を次に示します。

    <PaymentReceiptSummary>
     <NetAmount>
     <Money currency="MXN">88305.94</Money>
     </NetAmount>
    </PaymentReceiptSummary>
    

    10.9 ChargeFileRequest

    銀行 P カード請求ファイルの cXML 要求ラッパーです。要求は、1 つの銀行口座の個別のバイヤーに対してそれぞれ 1つ生成されます。そのため、要求により、P カード請求ファイルに関連付けられたバイヤーが一意に識別されます。ChargeFileRequest ドキュメントは、プロバイダによってバイヤーに送信されます。ChargeFileRequest には以下の要素が含まれます。

    要素 説明
    ChargeFileRequestHeader
    (必須)
    銀行 P カード請求を処理するための必須フィールドが含まれます。「ChargeFileRequestHeader」を参照してください。
    ChargeFileDetails
    (必須)
    銀行 P カード請求ファイルの一覧が含まれます。「ChargeFileDetails」を参照してください。

    以下に、ChargeFileRequest の例を示します。

    <Request deploymentMode="production">
     <ChargeFileRequest>
     <ChargeFileRequestHeader>
     <ProviderName xml:lang="en">Standard Chartered</ProviderName>
     <Extrinsic name="test">External Extrinsic</Extrinsic>
     </ChargeFileRequestHeader>
     <ChargeFileDetails>
     <ChargeFile filename="SC_Buyer1.csv" size="10000" format="BAI2" frequency="daily" statementDate="12-12-2019">
     <Period startDate="12-11-2019" endDate="12-12-2019"/>
     <Attachment>
     <URL>cid:part2.PCO28.975@saturn.workchairs.com</URL>
     </Attachment>
     <NumberOfCharges>2</NumberOfCharges>
     </ChargeFile>
     <Comments xml:lang="en" type="general">These are some comments</Comments>
     <IdReference domain="bankAccountID" identifier="214109887"/>
     <Extrinsic name="test">CharFileRequest</Extrinsic>
     </ChargeFileDetails>
     <ChargeFileDetails>
     <ChargeFile filename="SC_Buyer2.csv" size="10000" format="BAI2"
     frequency="daily" statementDate="12-13-2019">
     <Period startDate="12-12-2019" endDate="12-13-2019"/>
     <Attachment>
     <URL>cid:part2.PCO28.966@saturn.workchairs.com</URL>
     </Attachment>
     <NumberOfCharges>2</NumberOfCharges>
     </ChargeFile>
     <Comments xml:lang="en" type="general">These are some comments</Comments>
     <IdReference domain="bankAccountID" identifier="214109887"/>
     <Extrinsic name="test">CharFileRequest</Extrinsic>
     </ChargeFileDetails>
     </ChargeFileRequest>
    </Request>
    

    10.9.1 ChargeFileRequestHeader

    銀行 P カード請求を処理するための必須フィールドが含まれます。以下の要素が含まれます。

    要素 説明
    ProviderName
    (必須)
    ChargeFileRequest の銀行/プロバイダ名が含まれます。
    Comments この銀行 P カード請求ファイルに関連付けられているコメントです。
    IdReference ID 参照を定義します。たとえば、ID とドメインのペアでバイヤーを識別することができます。
    Extrinsic 銀行 P カード請求ファイルに関連する追加情報が含まれます。
    10.9.1.1 ProviderName

    ChargeFileRequest の銀行/プロバイダ名が含まれます。この要素には、次の属性があります。

    属性 説明
    xml:lang
    (必須)
    ProviderName が書き込まれる言語または地域情報です。

    10.9.2 ChargeFileDetails

    銀行 P カード請求ファイルの一覧が含まれます。以下の要素が含まれます。

    要素 説明
    ChargeFile
    (必須)
    銀行 P カード請求ファイル関連の情報です。「ChargeFile」を参照してください。
    Comments この銀行 P カード請求ファイルに関連付けられているコメントです。
    IdReference ID 参照を定義します。たとえば、ID とドメインのペアでバイヤーを識別することができます。
    Extrinsic 銀行 P カード請求ファイルに関連する追加情報が含まれます。
    10.9.2.1 ChargeFile

    銀行 P カード請求ファイルに関する情報が含まれます。銀行 P カード請求ファイルは、照合目的で銀行からバイヤーに送信されるファイルです。ChargeFile には次の属性があります。

    属性 説明
    filename 銀行 P カード請求ファイルの名前です。
    size 銀行 P カード請求ファイルのサイズです。
    frequency
    (必須)
    銀行 P カード請求ファイルの頻度を定義します。有効な値は次のとおりです。
    ● daily
    ● weekly
    ● monthly
    format 銀行 P カード請求ファイルの標準の形式 (MT940、CAMT.053、BAI2、CSV など) を定義します。
    statementDate
    (必須)
    この P カード請求ファイルの生成日です。

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

    要素 説明
    Period
    (必須)
    P カード請求ファイルの期間を定義します。
    Attachment
    (必須)
    添付された P カード請求ファイルの URL 参照が含まれます。
    NumberOfCharges
    (必須)
    添付ファイル内の P カード請求の数が含まれます。
    10.9.2.1.1 NumberOfCharges

    銀行 P カード請求ファイルに含まれた P カード請求の合計数が含まれます。



    ← cXML リファレンスガイド 目次へ戻る

     タイムカードは臨時社員およびコントラクタに関連した発注に使用されます。これらは、バイヤーまたはサプライヤによって生成および送信されます。どちらであるかは、タイムカード情報がどちらのシステムで取得されるかによります。

    11.1 TimeCard Request

    タイムカードには双方向の性質があるため、TimeCard 要素に関する Request には、TimeCardRequest およびTimeCardInfoRequest の 2 つが存在します。該当する臨時社員として業務を行うコントラクタは、状況によってバイヤーまたはサプライヤのいずれかのシステムにタイムカード情報を入力します。したがって、バイヤーまたはサプライヤのどちらも TimeCard ドキュメントを送信でき、また、TimeCard ドキュメントはいずれの方向にも転送されます。このように、タイムカードは、通常はサプライヤからのみ送信される請求書とは異なります。

    図 15: タイムカードドキュメントのフロー

    11.1.1 サプライヤからバイヤーへの Request

    TimeCardRequest には、人材派遣会社などのサプライヤからバイヤーに送信される TimeCard ドキュメントが記述されます。from および sender はサプライヤの認証情報で、to はバイヤーの認証情報です。タイムカードが承認されると、バイヤーはタイムカードが承認されたか却下されたかを示す DocumentApprovalStatus 要素とともにStatusUpdateRequest を送信します。

    11.1.2 バイヤーからサプライヤへの Request

    TimeCardInfoRequest には、バイヤーからサプライヤへ送信される TimeCard ドキュメントが記述されます。fromはバイヤーの認証情報で、to はサプライヤの認証情報です。

    11.2 TimeCard 要素

    TimeCard 要素は、コンストラクタやその他の臨時社員が作業した時間を取得するために使用されます。次の例では、Fulfill.dtd からの TimeCard の要素宣言を示しています。

    <!ELEMENT TimeCard (
     OrderInfo,
     Contractor,
     ReportedTime,
     SubmitterInfo,
     ApprovalInfo*,
     Comments?,
     DocumentReference?)>
    

    TimeCard 要素には以下の属性が含まれます。

    属性 説明
    type 指定可能な値は、new、update、および delete です。元のタイムカードが更新されない場合、通常の値は new です。
    status 指定できる値は submitted、approved、denied. です。通常の値は submitted です。
    timeCardID
    (必須)
    バイヤーおよびサプライヤシステムにおけるこのタイムカードの一意の識別子を表します。

    11.2.1 OrderInfo

    OrderInfo 要素はオーダーの参照に使用されます。1 つのタイムカードで 1 つのオーダーのみ参照します。

    11.2.2 Contractor

    Contractor 要素では、臨時社員のコンテキストで使用されるコントラクタが定義されます。

    11.2.2.1 ContractorIdentifier

    ContractorIdentifier では、バイヤーおよびサプライヤ両方のシステムでコントラクタが一意に識別されます。これはオーダーまたはタイムカードの送信前に、バイヤーおよびサプライヤによって合意されています。ContractorIdentifier 要素には次の属性が含まれます。

    属性 説明
    domain
    (必須)
    ContractorIdentifier が示されるドメインです。指定できる値は、ContractorIdentifier が定義されたシステムを示す supplierReferenceID または buyerReferenceID です。
    11.2.2.2 Contact

    一般的な Contact 要素には、コントラクタが記述されます。

    11.2.3 ReportedTime

    ReportedTime 要素では、タイムカードの明細が取得されます。

    11.2.3.1 Period

    Period では、タイムカードが提出された期間が定義されます。

    11.2.3.2 TimeCardTimeInterval

    TimeCardTimeInterval 要素は、タイムカードで報告される時間間隔を表します。この要素には、次の属性があります。

    属性 説明
    duration
    (必須)
    明細について報告される期間は、ISO 8601 形式 PnYn MnDTnH nMnS で表します。ここで、nY は年数、nM は月数、nD は日数、 T は日付/時刻の区切り記号、nH は時間数、nM は分数、nS は秒数です。たとえば、1 年、2 か月、3 日、10 時間、30 秒の期間を示すには、P1Y2M3DT10H30M と記述します。duration および TimeRange が一致しない場合、duration が優先されます。たとえば、duration が 2 時間で、TimeRange が午後 4 時から午後 8 時の場合、2 時間の duration が優先されます。ただし、duration が存在しない場合、TimeRange から計算されます。
    payCode
    (必須)
    使用される支給コードです。以下の支給コードの使用を推奨します。
    ● Regular
    ● Overtime
    ● Doubletime
    ● Mealbreak
    ● Tripletime
    ● WeeklyRestDay
    ● HolidayWorked
    ● RegularNightShift
    ● OvertimeNightShift
    ● DoubletimeNightShift
    ● TripletNightShift
    ● WeeklyRestDayNightShift
    ● RegularMixedShift
    ● OvertimeMixedShift
    ● DoubletimeMixedShift
    ● TripletimeMixedShift
    ● WeeklyRestDayMixedShift
    isNonBillable 指定した時間が請求可能かどうかを示す暗黙の属性です。通常は請求可能です。
    11.2.3.3 経費

    Expense 要素では、コンストラクタがタイムカードで報告した経費が定義されます。この要素には、次の属性があります。

    属性 説明
    expenseDate
    (必須)
    経費の日付です。
    expenseType 経費の種類です。推奨される経費の種類は以下のとおりです。
    ● mileage
    ● airfare
    ● fuel
    ● taxi
    ● perDiem
    ● hotel
    isNonBillable
    (必須)
    指定した経費が請求可能かどうかを暗黙的に示す属性です。通常は請求可能です。
    11.2.3.4 ExpenseAmount

    ExpenseAmount 要素は、コンストラクタがタイムカードで報告した経費の金額および通貨を表します。

    11.2.3.5 TimeRange

    TimeRange 要素では、開始日と終了日に制約がない期間が定義されます。TimeRange 要素には次の属性が含まれます。

    属性 説明
    startDate 請求可能期間の開始日です。
    endDate 請求可能期間の終了日です。

    11.2.4 SubmitterInfo

    SubmitterInfo 要素には、タイムカード提出者の情報が含まれます。この要素には、次の属性があります。

    属性 説明
    submittedDate
    (必須)
    タイムカードが提出された日時。
    11.2.4.1 Contact

    Contact 要素が存在しない場合、コントラクタが提出者であるとみなされます。

    11.2.5 ApprovalInfo

    ApprovalInfo 要素には、タイムカードの承認者の情報が含まれます。この情報は、情報提供のためだけにサプライヤによって送信され、チェーン内のすべての承認者を含めることができます。該当するタイムカードに多くの承認者を必要とする場合もあるため、複数の承認者情報が定義できます。ApprovalInfo 要素には以下の属性が含まれます。

    属性 説明
    approvedDate
    (必須)
    タイムカードが承認された日時。

    11.2.6 DocumentReference

    DocumentReference は、更新操作で以前の TimeCardRequest または TimeCardInfoRequest. を参照するために使用されます。

    11.3 TimeCard の例

    次の例は、サプライヤへ提出するために送信される TimeCardInfoRequest を示しています。

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE cXML SYSTEM "http://xml.cxml.org/schemas/cXML/1.2.014/Fulfill.dtd">
    <cXML xml:lang="en-US" payloadID=" tc1@buyer.com" timestamp="2003-10-01T23:00:06-08:00">
     <Header>
     <From>
     <Credential domain="NetworkId">
     <Identity>AN0100023456</Identity>
     </Credential>
     </From>
     <To>
     <Credential domain="NetworkId">
     <Identity> AN0100023457</Identity>
     </Credential>
     </To>
     <Sender>
     <Credential domain="NetworkId">
     <Identity> AN0100023456</Identity>
     <SharedSecret>abracadabra</SharedSecret>
     </Credential>
     <UserAgent>Our Procurement Application 2.0</UserAgent>
     </Sender>
     </Header>
     <Request>
     <TimeCardInfoRequest>
     <TimeCard type="new" status="submitted" timeCardID="TC101">
     <OrderInfo>
     <OrderIDInfo orderID="PO12" orderDate="2003-07-22T08:00:00-08:00"/>
     </OrderInfo>
     <Contractor>
     <ContractorIdentifier domain="supplierReferenceID">Doe8610
     </ContractorIdentifier>
     <Contact>
     <Name xml:lang="en">John Doe</Name>
     </Contact>
     </Contractor>
     <ReportedTime>
     <Period startDate="2003-09-22T08:00:00-08:00" endDate="2003-09-26T18:00:00-08:00"/>
     <TimeCardTimeInterval duration="PT8H" payCode="Regular">
     <TimeRange startDate="2003-09-22T08:00:00-08:00" endDate="2003-09-22T18:00:00-08:00"/>
     </TimeCardTimeInterval>
     <TimeCardTimeInterval duration="PT2H" payCode="Mealbreak" isNonBillable="yes">
     <TimeRange startDate="2003-09-22T012:00:00-08:00" endDate="2003-09-22T14:00:00-08:00"/>
     </TimeCardTimeInterval>
     <TimeCardTimeInterval duration="PT2H" payCode="Overtime">
     <TimeRange startDate="2003-09-22T18:00:00-08:00" endDate="2003-09-22T20:00:00-08:00"/>
     </TimeCardTimeInterval>
     <TimeCardTimeInterval duration="PT8H" payCode="Regular">
     <TimeRange startDate="2003-09-23T08:00:00-08:00"/>
     </TimeCardTimeInterval>
     <TimeCardTimeInterval duration="PT8H" payCode="Regular">
     <TimeRange startDate="2003-09-24T08:00:00-08:00"/>
     </TimeCardTimeInterval>
     <TimeCardTimeInterval duration="PT8H" payCode="Regular">
     <TimeRange startDate="2003-09-25T08:00:00-08:00"/>
     </TimeCardTimeInterval>
     <TimeCardTimeInterval duration="PT8H" payCode="Regular">
     <TimeRange startDate="2003-09-26T08:00:00-08:00"/>
     </TimeCardTimeInterval>
     </ReportedTime>
     <SubmitterInfo submittedDate="2003-10-01T08:00:00-08:00">
     <Contact>
     <Name xml:lang="en">John Doe</Name>
     </Contact>
     </SubmitterInfo>
     </TimeCard>
     </TimeCardInfoRequest>
     </Request>
    </cXML>
    

    次の例は、承認時にサプライヤへ送信される更新の例です。

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE cXML SYSTEM "http://xml.cxml.org/schemas/cXML/1.2.014/Fulfill.dtd">
    <cXML xml:lang="en-US" payloadID=" tc1-update@buyer.com" timestamp="2003-10-01T23:00:06-08:00">
     <Header>
     <From>
     <Credential domain="NetworkId">
     <Identity>AN0100023456</Identity>
     </Credential>
     </From>
     <To>
     <Credential domain="NetworkId">
     <Identity> AN0100023457</Identity>
     </Credential>
     </To>
     <Sender>
     <Credential domain="NetworkId">
     <Identity> AN0100023456</Identity>
     <SharedSecret>abracadabra</SharedSecret>
     </Credential>
     <UserAgent>Suppliers Time Card Application 5.0</UserAgent>
     </Sender>
     </Header>
     <Request>
     <TimeCardInfoRequest>
     <TimeCard type="update" status="approved" timeCardID="TC101">
     <OrderInfo>
     <OrderIDInfo orderID="PO123" orderDate="2003-07-22T08:00:00-08:00"/>
     </OrderInfo>
     <Contractor>
     <ContractorIdentifier domain="supplierReferenceID">Doe8610
     </ContractorIdentifier>
     <Contact>
     <Name xml:lang="en">John Doe</Name>
     </Contact>
     </Contractor>
     <ReportedTime>
     <Period startDate="2003-09-22T08:00:00-08:00" endDate="2003-09-26T18:00:00-08:00"/>
     <TimeCardTimeInterval duration="PT8H" payCode="Regular">
     <TimeRange startDate="2003-09-22T08:00:00-08:00" endDate="2003-09-22T18:00:00-08:00"/>
     </TimeCardTimeInterval>
     <TimeCardTimeInterval duration="PT2H" payCode="Mealbreak" isNonBillable="yes">
     <TimeRange startDate="2003-09-22T012:00:00-08:00" endDate="2003-09-22T14:00:00-08:00"/>
     </TimeCardTimeInterval>
     <TimeCardTimeInterval duration="PT2H" payCode="Overtime" >
     <TimeRange startDate="2003-09-22T18:00:00-08:00" endDate="2003-09-22T20:00:00-08:00"/>
     </TimeCardTimeInterval>
     <TimeCardTimeInterval duration="PT8H" payCode="Regular" >
     <TimeRange startDate="2003-09-23T08:00:00-08:00"/>
     </TimeCardTimeInterval>
     <TimeCardTimeInterval duration="PT8H" payCode="Regular" >
     <TimeRange startDate="2003-09-24T08:00:00-08:00"/>
     </TimeCardTimeInterval>
     <TimeCardTimeInterval duration="PT8H" payCode="Regular" >
     <TimeRange startDate="2003-09-25T08:00:00-08:00"/>
     </TimeCardTimeInterval>
     <TimeCardTimeInterval duration="PT8H" payCode="Regular" >
     <TimeRange startDate="2003-09-26T08:00:00-08:00"/>
     </TimeCardTimeInterval>
     </ReportedTime>
     <SubmitterInfo submittedDate="2003-10-01T08:00:00-08:00">
     <Contact>
     <Name xml:lang="en">John Doe</Name>
     </Contact>
     </SubmitterInfo>
     <ApprovalInfo approvedDate="2003-10-02T08:00:00-08:00">
     <Contact>
     <Name xml:lang="en">John Doe</Name>
     </Contact>
     </ApprovalInfo>
     <DocumentReference payloadID="tc1@buyer.com"/>
     </TimeCard>
     </TimeCardInfoRequest>
     </Request>
    </cXML>
    



    ← cXML リファレンスガイド 目次へ戻る

     cXML では、主契約ドキュメントの送信がサポートされています。主契約ドキュメントは、取引先間での契約を表します。ContractRequest および ContractStatusUpdateRequest ドキュメントの送信もサポートされています。このドキュメントはは、バイヤーから外部バイヤーシステムに送信される契約を表します。

    12.1 主契約の概要

    バイヤーとサプライヤは、主契約によって製品とサービスに関する取り決めを行います。主契約は、予算やサプライヤの取り決めを管理する一般的な仕組みを表し、これにより、バイヤーは今後の購買活動の基本となる、より有利な割引条件を交渉でき、またサプライヤはより正確に需要を予測できます。主契約トランザクションを使用することで、購買アプリケーションでは、主契約に関するサプライヤとの交渉および作成と、その主契約からリリースオーダーの作成が容易になります。これらの契約書 (Agreement ドキュメント) はネットワークハブを経由して、購買アプリケーションからサプライヤに送信されます。契約に基づいてオーダーを履行することを、リリースと呼びます。

    12.2 MasterAgreementRequest

    MasterAgreementRequest ドキュメントでは、バイヤー企業が作成した主契約が定義されます。開始日と終了日を指定し、さらに合意した最低金額と最高金額を指定します。また、個別の品目に対する最高金額と最低金額、および最高数量と最低数量も一覧表示されます。MasterAgreementRequest ドキュメントの例を次に示します。

    <MasterAgreementRequest>
     <MasterAgreementRequestHeader agreementID="MA123" agreementDate="2001-12-01" type="value" effectiveDate="2002-01-01" expirationDate="2002-12-31" operation="new">
     <MaxAmount>
     <Money currency="USD">10000</Money>
     </MaxAmount>
     <MaxReleaseAmount>
     <Money currency="USD">10000</Money>
     </MaxReleaseAmount>
     <Contact role="BuyerLocation">
     <Name xml:lang="en">Buyer Company</Name>
     <PostalAddress name="default">
     <DeliverTo>Joe Smith</DeliverTo>
     <DeliverTo>Mailstop M-543</DeliverTo>
     <Street>123 Anystreet</Street>
     <City>Sunnyvale</City>
     <State isoStateCode="US-CA">CA</State>
     <PostalCode>90489</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     </PostalAddress>
     </Contact>
     <Comments xml:lang="en-US">well formed XML can go here.</Comments>
     </MasterAgreementRequestHeader>
     <AgreementItemOut maxQuantity="100">
     <MaxAmount>
     <Money currency="USD">1000</Money>
     </MaxAmount>
     <MaxReleaseAmount>
     <Money currency="USD">100</Money>
     </MaxReleaseAmount>
     <ItemOut quantity="1">
     <ItemID>
     <SupplierPartID>1233244</SupplierPartID>
     </ItemID>
     <ItemDetail>
     <UnitPrice>
     <Money currency="USD">1.34</Money>
     </UnitPrice>
     <Description xml:lang="en">Blue Ballpoint Pen</Description>
     <UnitOfMeasure>EA</UnitOfMeasure>
     <Classification domain="UNSPSC">12345</Classification>
     <ManufacturerPartID>234</ManufacturerPartID>
     <ManufacturerName>foobar</ManufacturerName>
     <URL>www.foo.com</URL>
     </ItemDetail>
     <Shipping trackingDomain="FedEx" trackingId="1234567890">
     <Money currency="USD">2.5</Money>
     <Description xml:lang="en-us">FedEx 2-day</Description>
     </Shipping>
     <Comments xml:lang="en-US">Any well formed XML</Comments>
     </ItemOut>
     </AgreementItemOut>
    </MasterAgreementRequest>
    

    12.2.1 MasterAgreementRequestHeader

    MasterAgreementRequestHeader には、その主契約に含まれる品目すべてに共通する主契約に関する情報が含まれますMasterAgreementHeader には次の属性があります。

    属性 説明
    agreementID
    (必須)
    この申請の購買システム契約 ID です。
    agreementDate
    (必須)
    契約申請書の作成日時。これは、契約の発行日や有効期限とは異なります。
    type 契約で金額と数量のどちらが参照されるかを指定します。
    effectiveDate
    (必須)
    オーダーまたはリリースに対して、その契約が有効になる日付を指定します。
    expirationDate
    (必須)
    その契約が無効になる日付を指定します。
    parentAgreementPayloadID この契約の派生元である親ドキュメントのペイロード ID です。
    operation 契約申請のタイプを指定します。”new”、”update”、”delete” のいずれかを指定できます。通常は “new” に設定されています。”delete” 操作は、既存の契約をキャンセルするときに使用します。delete タイプの申請は、元の申請の完全な複製にしてください。

    MasterAgreementHeader には、次の子要素を任意で含めることができます。

    要素 説明
    MaxAmount 主契約に含まれるすべての明細の最高金額です。
    MinAmount 主契約に含まれるすべての明細の確定金額です。
    MaxReleaseAmount この主契約のリリースごとの契約最高金額です。
    MinReleaseAmount この主契約のリリースごとの契約最低金額です。
    Contact 追加の住所または所在地情報が提供されます。
    Comments 主契約全体の状況に関する追加情報が含まれます。
    Extrinsic アプリケーションで使用される主契約に関する追加データを挿入するために使用できます。

    12.2.2 AgreementItemOut

    AgreementItemOut 要素では、主契約の一部である特定の明細の必要条件が指定されます。AgreementItemOut には次の任意設定の属性があります。

    属性 説明
    maxQuantity この特定の明細の最高数量が指定されます。
    minQuantity この特定の明細の最低数量が指定されます。
    maxReleaseQuantity この特定の明細のリリースごとに最高数量が指定されます。
    minReleaseQuantity この特定の明細のリリースごとに最低数量が指定されます。

    AgreementItemOut には、次の子要素を任意で含めることができます。

    要素 説明
    MaxAmount この特定の明細の最高金額が含まれます。
    MinAmount この特定の明細の最低金額が含まれます。
    MaxReleaseAmount リリースごとに明細レベルの最高金額が指定されます。
    MinReleaseAmount リリースごとに明細レベルの最低金額が指定されます。
    ItemOut
    (必須)
    主契約に含まれる品目。
    ItemOut の lineNumber 属性では、購買アプリケーションの主契約に対応する lineNumber が指定されます。ItemOut の quantity 属性は “one” に設定すると、主契約の実装の処理段階で無視されます。

    12.3 ContractRequest

    ContractRequest 要素は、バイヤーから外部バイヤーシステムに送信される契約を表します。
    以下に ContractRequest の例を示します。

    <Request deploymentMode="production">
     <ContractRequest>
     <ContractRequestHeader operation="new" xml:lang="en" expirationDate="2016-01-30T00:00:00-00:00" effectiveDate="2016-01-11T00:00:00-00:00" type="value" agreementDate="2016-01-12T00:00:00-00:00" createDate="2016-01-11T23:36:18+08:00" contractID="CW2009">
     <LegalEntity domain="CompanyCode">100</LegalEntity>
     <OrganizationID>
     <Credential domain="NetworkID">
     <Identity>AN02000000120</Identity>
     </Credential>
     <Credential domain="sap">
     <Identity>0000000100</Identity>
     </Credential>
     </OrganizationID>
     <OrganizationalUnit domain="PurchasingOrganization">
     1001
     </OrganizationalUnit>
     <OrganizationalUnit domain="PurchasingGroup">
     10101
     </OrganizationalUnit>
     <PaymentTerm payInNumberOfDays="10">
     <Discount>
     <DiscountPercent percent="2"></DiscountPercent>
     </Discount>
     <Extrinsic name=”Id”>0001</Extrinsic>
     </PaymentTerm>
     <MaxAmount>
     <Money currency="USD">2000.00</Money>
     </MaxAmount>
     <TermsOfDelivery>
     <TermsOfDeliveryCode value="TransportCondition"/>
     <ShippingPaymentMethod value ="Other"/>
     <TransportTerms value="FOB">Free on board vessel</TransportTerms>
     </TermsOfDelivery>
     </ContractRequestHeader>
     <ContractItemIn>
     <TermsOfDelivery>
     <TermsOfDeliveryCode value="TransportCondition"/>
     <ShippingPaymentMethod value ="Other"/>
     <TransportTerms value="FOB">Free on board vessel</TransportTerms>
     </TermsOfDelivery>
     <ItemIn lineNumber="1" quantity="100" itemClassification=”material”>
     <ItemID>
     <SupplierPartID>1</SupplierPartID>
     <SupplierPartAuxiliaryID></SupplierPartAuxiliaryID>
     <BuyerPartID>992</BuyerPartID> <!-- Material code -->
     </ItemID>
     <ItemDetail>
     <UnitPrice>
     <Money currency="USD">1000.00</Money>
     <Modifications>
     <Modification>
     <AdditionalDeduction type="DISCOUNT">
     <DeductionAmount>
     <Money currency="USD">10.00</Money>
     </DeductionAmount>
     </AdditionalDeduction>
     </Modification>
     <Modification>
     <AdditionalDeduction type="DISCOUNT">
     <DeductionPercent percent="20"/>
     </AdditionalDeduction>
     </Modification>
     <Modification>
     <AdditionalCost>
     <Money currency="USD">30.00</Money>
     </AdditionalCost>
     </Modification>
     <Modification>
     <AdditionalCost>
     <Percentage percent="20"/>
     </AdditionalCost>
     </Modification>
     </Modifications>
     </UnitPrice>
     <Description xml:lang="en">Laptops</Description>
     <UnitOfMeasure>EA</UnitOfMeasure>
     <Classification domain="unspsc">43211503</Classification>
     <Classification domain="MaterialGroup">29</Classification>
     <ManufacturerPartID></ManufacturerPartID>
     <ManufacturerName></ManufacturerName>
     <URL></URL>
     <LeadTime>2</LeadTime>
     </ItemDetail>
     <ShipTo>
     <Address addressID="3000" addressIDDomain="buyerLocationID" isoCountryCode="US">
     <Name xml:lang="en" >Plant 3000</Name>
     </Address>
     </ShipTo>
     </ItemIn>
     <ReferenceDocumentInfo lineNumber = "10">
     <DocumentInfo documentID = "PR1234" documentType = "Requisition" documentDate = "2015-11-07T07:03:34-05:00">
     </DocumentInfo>
     </ReferenceDocumentInfo>
     <ReferenceDocumentInfo lineNumber = "3">
     <DocumentInfo documentID = "RFQ2345" documentType = "RFQ" documentDate = "2015-11-07T07:03:34-05:00">
     </DocumentInfo>
     </ReferenceDocumentInfo>
     </ContractItemIn>
     </ContractRequest>
    </Request>
    

    12.3.1 ContractRequestHeader

    ContractRequestHeader は、ContractRequest のヘッダー要素です。この要素には、次の属性があります。

    属性 説明
    contractID
    (必須)
    この申請のソースバイヤーシステムの契約 ID です。
    type 契約が値ベースであるか数量ベースであるかを識別します。使用可能な値は “value”または “quantity” です。
    createDate 契約が作成または公開された日時です。
    agreementDate 契約が作成された日時です。これは契約の発効日および有効期限とは異なります。
    effectiveDate
    (必須)
    契約のオーダーまたはリリースが可能となる日付です。
    expirationDate 契約が使用できなくなる日付です。
    xml:lang
    (必須)
    ContractRequest の内容が書き込まれる言語またはロケール。
    operation ContractRequest の操作モード。使用可能な値は次のとおりです。
    ● new – 新しい契約取引を識別します。
    ● update – 既存の取引の更新を識別します。DocumentInfo 要素は、外部システムの契約を示すために使用できます。
    ● delete – 既存の契約をキャンセルします。削除要求は、元の要求の完全な複製にしてください。

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

    要素 説明
    LegalEntity
    (必須)
    外部システム内の法人です。IdReference 要素が含まれます。
    OrganizationID
    (必須)
    組織 ID の認証情報を提供します。
    OrganizationalUnit 外部システム内の発注ユニットまたは発注グループを識別します。IdReference 要素が含まれます。
    PaymentTerm 請求書またはオーダーの支払条件が定義されます。支払条件には、支払期間 (割引なし) または割引適用期間 (割引あり) を指定できます。
    QuoteRequestReference 外部システムで作成された見積依頼を参照します。
    MaxAmount 契約の最高金額。
    MinAmount 契約の最低金額。
    MaxReleaseAmount 契約のリリースごとの契約最高数量。
    MinReleaseAmount 契約のリリースごとの契約最低数量。
    Contact 申請会社の追加の住所または所在地情報を提供します。
    Comments 契約申請に関する追加コメント。
    DocumentInfo 外部システムで管理される契約 ID です。操作が “update” の場合に含められます。
    ParentContractInfo 現在の契約が階層に含まれる場合の、外部システムの親契約 ID です。
    FollowUpDocument これには、ContractRequest でのフォローアップ方法に関する情報が含まれます。「FollowUpDocument 」を参照してください。
    TermsOfDelivery 国際商工会議所によって定義された任意の出荷条件 (インコタームズ)。
    SupplierProductionFacilityRelations サプライヤの生産設備とその生産設備の役割間に存在する関係を定義します。「SupplierProductionFacilityRelations」を参照してください。
    Extrinsic 契約申請ヘッダーに関する追加情報。
    12.3.1.1 FollowUpDocument

    QuoteMessage または ContractRequest でのフォローアップ方法に関する情報が含まれます。type および category 属性の設定は自由ですが、バックエンドシステムが理解できるように、広く知られた文字列を使用する必要があります。たとえば、type を “Contract” に、category を “WK” または “value” に設定することができます。これにより、次の手順が WK Contract の作成であるというヒントがバックエンドシステムに与えられます。
    FollowUpDocument には次の属性があります。

    属性 説明
    type ドキュメントの種類を示します。使用可能な値は Contract、Scheduling Agreement、またはすべてのカスタムドキュメントの種類です。
    category ドキュメントのカテゴリを示します。
    購買契約の場合: value または quantity を入力します。
    分納契約の場合: LP または LPA を入力します。
    カスタムドキュメントの種類の場合: 任意の設定された値を入力します。

    FollowUpDocument の例を次に示します。

    <FollowUpDocument type="Contract" category="value"/>
    <FollowUpDocument type="Scheduling Agreement" category="LP"/>
    
    12.3.1.2 SupplierProductionFacilityRelations

    サプライヤの生産設備とその生産設備の役割間に存在する関係が定義されます。
    SupplierProductionFacilityRelations には以下の要素が含まれます。

    要素 説明
    ProductionFacilityAssociation
    (必須)
    生産設備と生産設備の役割間の関係が定義されます。「ProductionFacilityAssociation」を参照してください。

    次の例は、SupplierProductionFacilityRelations 要素を示しています。

    <SupplierProductionFacilityRelations>
     <!-- ProductionFacilityAssociation describes a new relationship to be added in Contract where: Production Facility SUPEREXPRESSO AG (331) of supplier is used for "Spinning Dry" (50) process has a relation with buyer's purchasing organization (0001) and buyer's plant (3000).-->
     <ProductionFacilityAssociation operation="new">
     <ProductionFacility productionFacilityName="SUPEREXPRESSO AG">
     <IdReference identifier="331" domain="ProductionFacility" />
     <ProductionFacilityRole name="Spinning Dry">
     <IdReference identifier="50" domain="ProductionFacility" />
     </ProductionFacilityRole>
     </ProductionFacility>
     <OrganizationalUnit>
     <IdReference identifier="0001" domain="PurchasingOrganization" />
     </OrganizationalUnit>
     <ShipTo>
     <Address addressID="3000">
     <Name>Plant 3000</Name>
     </Address>
     </ShipTo>
     </ProductionFacilityAssociation>
     <ProductionFacilityAssociation operation="new">
     <ProductionFacility name="SUPEREXPRESSO AG">
     <IdReference identifier="331" domain="ProductionFacility" />
     <ProductionFacilityRole name="Spinning Wet">
     <IdReference identifier="51" domain="ProductionFacility" />
     </ProductionFacilityRole>
     </ProductionFacility>
     <OrganizationalUnit>
     <IdReference identifier="0001" domain="PurchasingOrganization" />
     </OrganizationalUnit>
     <ShipTo>
     <Address addressID="1010">
     <Name>Plant 1010</Name>
     </Address>
     </ShipTo>
     </ProductionFacilityAssociation>
     <ProductionFacilityAssociation operation="new">
     <ProductionFacility name="GRONO GMEH">
     <IdReference identifier="332" domain="ProductionFacility" />
     <ProductionFacilityRole name="Washing">
     <IdReference identifier="60" domain="ProductionFacility" />
     </ProductionFacilityRole>
     </ProductionFacility>
     <OrganizationalUnit>
     <IdReference identifier="0002" domain="PurchasingOrganization" />
     </OrganizationalUnit>
     <ShipTo>
     <Address addressID="2000">
     <Name>Plant 2000</Name>
     </Address>
     </ShipTo>
     </ProductionFacilityAssociation>
     <!-- ProductionFacilityAssociation describes a new relationship to be deleted in Contract where: Production Facility GRONO GMEH (332) of supplier is used for "Tannery" (64) process has a relation with buyer's purchasing organization (0002) and buyer's plant (2000).-->
     <ProductionFacilityAssociation operation='delete'>
     <ProductionFacility name="GRONO GMEH">
     <IdReference identifier="332" domain="ProductionFacility" />
     <ProductionFacilityRole name="Tannery">
     <IdReference identifier="64" domain="ProductionFacility" />
     </ProductionFacilityRole>
     </ProductionFacility>
     <OrganizationalUnit>
     <IdReference identifier="0002" domain="PurchasingOrganization" />
     </OrganizationalUnit>
     <ShipTo>
     <Address addressID="2000">
     <Name>Plant 2000</Name>
     </Address>
     </ShipTo>
     </ProductionFacilityAssociation>
    </SupplierProductionFacilityRelations>
    
    12.3.1.2.1 ProductionFacilityAssociation

    生産設備と生産設備の役割間の関係が定義されます。
    ProductionFacilityAssociation には次の属性があります。

    属性 説明
    operation 実行される操作です。使用可能な値は次のとおりです。
    ● new (初期値) – 外部システムに送信された新しい生産設備の関連付けを表します。
    ● update- 既存の生産設備の関連付けへの更新を表します。
    ● delete – この生産設備の関連付けを外部システムで削除する指示を表します。
    operation 属性によって、ProductionFacility、ProductionFacilityRole、OrganizationalUnit、または ShipTo などのオブジェクトは作成または削除されません。この属性は、既存の生産設備と生産設備の役割間の関係を定義するためにのみ使用されます。

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

    要素 説明
    ProductionFacility
    (必須)
    生産設備と生産設備の役割間の関係が定義されます。「ProductionFacility」を参照してください。
    OrganizationalUnit
    (必須)
    バイヤーの購買組織。ShipTo バイヤーのプラントに関するオプションの出荷先情報。
    12.3.1.2.1.1 ProductionFacility

    特定の製造プロセスで使用されるサプライヤ単位を定義します。
    ProductionFacility には次の属性があります。

    属性 説明
    name
    (必須)
    生産設備の名前です。

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

    要素 説明
    IdReference
    (必須)
    ID 参照を定義します。ID/ドメインのペアにより、生産設備が識別されます。
    ProductionFacilityRole
    (必須)
    サプライヤの生産設備が使用される製造プロセスのステージが定義されます。「ProductionFacilityRole」を参照してください。
    12.3.1.2.1.1.1 ProductionFacilityRole

    サプライヤ生産設備が使用される製造プロセスのステージが定義されます。たとえば、アパレル製造プロセスには、裁断、縫製、プレスと折りたたみ、仕上げ、装飾、染色、および洗濯のために、独立した生産設備の役割がある場合があります。
    ProductionFacilityRole には次の属性があります。

    属性 説明
    name
    (必須)
    生産設備の役割の名前です。

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

    要素 説明
    IdReference
    (必須)
    ID 参照を定義します。ID/ドメインのペアにより、生産設備の役割が識別されます。

    12.3.2 ContractItemIn

    ContractItemIn は、外部システムに送信される契約品目を表します。この要素には、次の属性があります。

    属性 説明
    operation 実行される操作です。使用可能な値は次のとおりです。
    ● new – 外部システムに送信される新しい契約品目です。
    ● update – 既存の契約品目への更新です。
    ● delete – 外部システムでこの契約品目を削除する手順です。
    itemType 品目の種類を指定します。使用可能な値は次のとおりです。
    ● composite – 品目グループを識別します。
    ● item – 独立した明細を識別します。
    ● lean – 明細で予定されている子品目がないことを示します。
    serviceLineType サービス明細の種類を表します。使用可能な値は次のとおりです。
    ● standard
    ● blanket
    ● contingency
    ● openquantity
    ● information

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

    要素 説明
    MaxAmount 品目の最高金額。
    MinAmount 品目の最低金額。
    MaxReleaseAmount リリース (オーダー) ごとの品目の契約最高数量。
    MinReleaseAmount リリース (オーダー) ごとの品目の契約最低数量。
    MaxQuantity 品目の最高数量。
    MinQuantity 品目の最低数量。
    MaxReleaseQuantity リリース (オーダー) ごとの品目の契約最高数量。
    MinReleaseQuantity リリース (オーダー) ごとの品目の契約最低数量。
    TermsOfDelivery 国際商工会議所によって定義された任意の出荷条件 (インコタームズ)。
    ItemIn
    (必須)
    ソースバイヤーシステムからの品目。
    ReferenceDocumentInfo この品目の任意の参照ドキュメント情報。たとえば、外部システムの購入申請または見積依頼書 (RFQ) です。「ReferenceDocumentInfo」を参照してください。
    Alternative サービス仕様明細の代替オプションを表します。代替が指定されている場合は、そのオプションは 1 つの基本明細と 1 つ以上の代替明細で構成されています。
    SupplierProductionFacilityRelations サプライヤの生産設備とその生産設備の役割間に存在する関係を定義します。「SupplierProductionFacilityRelations [281 ページ]」を参照してください。
    Extrinsic 契約品目に関連する追加情報が含まれます。

    次の例は、ContractItemIn 要素を示しています。

    <ContractItemIn operation="new" itemType="item" serviceLineType="standard">
     <MaxQuantity>10.000</MaxQuantity>
     <ItemIn itemClassification="service" lineNumber="3" quantity="10.000">
     <ItemID>
     <SupplierPartID></SupplierPartID>
     <SupplierPartAuxiliaryID></SupplierPartAuxiliaryID>
     <BuyerPartID>PROC-IT-SH-001</BuyerPartID>
     </ItemID>
     <ItemDetail>
     <UnitPrice>
     <Money currency="USD">10.00</Money>
     </UnitPrice>
     <Description xml:lang="en">Conan Digital Rebel XTi 10.1-Megapixel</Description>
     <UnitOfMeasure>EA</UnitOfMeasure>
     <Classification domain="MaterialGroup">45000000</Classification>
     <ManufacturerPartID></ManufacturerPartID>
     <ManufacturerName></ManufacturerName>
     <URL></URL>
     <LeadTime></LeadTime>
     <Extrinsic name="Material Number">PROC-IT-SH-001</Extrinsic>
     <Extrinsic name="Material Type">ZARB</Extrinsic>
     <Extrinsic name="Order Unit">EA</Extrinsic>
     </ItemDetail>
     <ShipTo>
     <Address addressIDDomain="buyerLocationID" addressID="3200">
     <Name xml:lang="en">3200</Name>
     </Address>
     </ShipTo>
     </ItemIn>
     <Alternative alternativeType="alternativeLine" basicLineNumber="1"/>
    </ContractItemIn>
    

    注記
    価格設定条件を使用して、さまざまなコスト項目の値 (Price、Discount、Surcharge など) を有効期間および基準次元に従って提供することができます。「価格設定条件の指定」を参照してください。

    12.4 ContractStatusUpdateRequest

    ContractStatusUpdateRequest には、契約状況の更新 (契約が正常に作成または更新されたかどうかなど) が含まれます。

    以下に ContractStatusUpdateRequest の例を示します。

    <Request deploymentMode="production">
     <ContractStatusUpdateRequest>
     <Status xml:lang="en-US" code="200" text="OK">Succeeded</Status>
     <ContractStatus type="created">
     <ContractIDInfo contractID="CW2009">
     <IdReference identifier="55000000" domain="SAPAgreementId"/>
     </ContractIDInfo>
     <ContractItemStatus>
     <ItemStatus type="created">
     <ReferenceDocumentInfo lineNumber="1"/>
     </ItemStatus>
     <IdReference identifier="010" domain="SAPLineNumber"/>
     </ContractItemStatus>
     <ContractItemStatus>
     <ItemStatus type="created">
     <ReferenceDocumentInfo lineNumber="2"/>
     </ItemStatus>
     <IdReference identifier="020" domain="SAPLineNumber"/>
     </ContractItemStatus>
     </ContractStatus>
     </ContractStatusUpdateRequest>
    </Request>
    

    12.4.1 Status

    回答またはメッセージの状況。この要素には、次の属性があります。

    属性 説明
    code
    (必須)
    HTTP または cXML 固有のステータスコード。
    text
    (必須)
    ステータスコードのテキストバージョン。
    xml:lang ContractStatusUpdateRequest の内容が書き込まれる言語または地域情報。

    12.4.2 ContractStatus

    ContractStatus には、契約の品目レベル状況更新が含まれます。この要素には、次の属性があります。

    属性 説明
    type
    (必須)
    契約状況の種類 (“created” など)。

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

    要素 説明
    ContractIDInfo
    (必須)
    ソースバイヤーシステムで作成/更新された契約 ID 情報。
    ContractItemStatus 契約状況更新要求の品目を表します。
    Comments 品目の任意のコメントまたは説明を提供するための任意のフィールド。

    12.4.3 Extrinsic

    契約状況に関する任意設定の追加情報です。



    ← cXML リファレンスガイド 目次へ戻る

     cXML では注文書およびその明細の状況(ステータス)を設定するためにエンティティを使用します。

    ページ内の目次
    13.1 状況の概要
    13.2 StatusUpdateRequest

    13.2.1 DocumentReference
    13.2.2 Status
    13.2.3 PaymentStatus
    13.2.4 SourcingStatus
    13.2.5 InvoiceStatus
    13.2.5.1 InvoiceIDInfo
    13.2.5.2 PartialAmount
    13.2.6 DocumentStatus
    13.2.6.1 DocumentInfo
    13.2.6.2 ItemStatus
    13.2.6.3 Comments
    13.2.7 IntegrationStatus
    13.2.8 Extrinsic

    13.3 ConfirmationRequest

    13.3.1 OrderReference
    13.3.2 ConfirmationHeader
    13.3.2.1 DocumentReference
    13.3.2.2 Tax および Shipping
    13.3.2.3 Total
    13.3.2.4 Contact
    13.3.2.5 Hazard
    13.3.2.6 コメント
    13.3.2.7 IdReference
    13.3.2.8 Extrinsic
    13.3.3 ConfirmationItem
    13.3.3.1 Contact
    13.3.3.2 Hazard
    13.3.3.3 ConfirmationStatus
    13.3.3.3.1 ScheduleLineReference

    13.4 OrderStatusRequest

    13.4.1 OrderStatusRequestHeader
    13.4.2 OrderStatusRequestItem
    13.4.2.1 ItemReference

    13.5 ShipNoticeRequest

    13.5.1 ShipNoticeHeader
    13.5.1.1 ServiceLevel
    13.5.1.2 DocumentReference
    13.5.1.3 Contact
    13.5.1.4 LegalEntity
    13.5.1.5 OrganizationalUnit
    13.5.1.6 Hazard
    13.5.1.7 Comments
    13.5.1.8 TermsOfTransport
    13.5.1.9 TermsofDelivery
    13.5.1.10 Packaging
    13.5.1.11 Extrinsic
    13.5.1.12 IdReference
    13.5.1.13 ReferenceDocumentInfo
    13.5.2 ShipControl
    13.5.2.1 CarrierIdentifier
    13.5.2.2 ShipmentIdentifier
    13.5.2.3 PackageIdentification
    13.5.2.4 Route
    13.5.2.5 TransportInformation
    13.5.2.6 Contact
    13.5.2.7 コメント
    13.5.2.8 Extrinsic
    13.5.3 ShipNoticePortion
    13.5.3.1 OrderReference
    13.5.3.2 MasterAgreementReference
    13.5.3.3 MasterAgreementIDInfo
    13.5.3.4 Contact
    13.5.3.5 コメント
    13.5.3.6 Extrinsic
    13.5.3.7 ShipNoticeItem
    13.5.3.7.1 ShipNoticeItemDetail
    13.5.3.7.2 Hazard
    13.5.3.7.3 SupplierBatchID または Batch
    13.5.3.7.4 AssetInfo
    13.5.3.7.5 ShipNoticeItemIndustry
    13.5.3.8 ReferenceDocumentInfo

    13.6 ReceiptRequest

    13.6.1 ReceiptRequestHeader
    13.6.2 ReceiptOrder
    13.6.2.1 ReceiptOrderInfo
    13.6.2.2 ReceiptItem
    13.6.2.2.1 ReceiptItemReference

    13.1 状況(ステータス)の概要

    OrderRequest トランザクションが完了した後、サプライヤと中間サーバーはバイヤー企業に追加情報を返送することが必要な場合があります。また、バイヤー企業が請求書を受け取った後、請求書の状況をサプライヤに返送することが必要な場合があります。この章で説明するトランザクションは、このような目的で使用します。これらのトランザクションは、いくつかの共通のセマンティクスと要素 (element) を共有します。OrderRequest (「OrderRequest に対する Response」を参照) への応答と同様に、これらのどのトランザクションにも固有の Response 要素は含まれません。代わりに、返されるドキュメントには、ほぼ空の Response (Status のみ) が含まれます。返信される各ドキュメントのフォームは次のとおりです。

    <cXML payloadID="9949494@supplier.com" timestamp="2000-01-12T18:39:09-08:00" xml:lang="en-US">
     <Response>
     <Status code="200" text="OK"/>
     </Response>
    </cXML>
    

    操作が正常に完了した場合にのみ “200” が返されます。

    13.2 StatusUpdateRequest

    このトランザクションは、オーダー、請求書、またはサービスシートの処理状況の変更について前のノードに通知します。特に重要な変更が 1 つあります。中間ハブは、ドキュメントを正常に転送した後、元の送信者または送信したハブに正常に転送できたという情報を通知することができます。サプライヤまたはハブで発生している待ち状況や処理状況も、バイヤー企業にとって意味がある場合があります。オーダー処理を支援するパートナー (FAX または EDI のサービスプロバイダなど) は、StatusUpdateRequest トランザクションメッセージをネットワークハブに送信して注文書状況を設定します。このトランザクションは、バイヤーとサプライヤの両方から参照可能な、ハブ上のオーダー状況指標に反映されます。さらに、サプライヤはこのトランザクションを送信して、バイヤー企業がサプライヤの組織内でドキュメント処理の状況を参照できるようにすることができます。バイヤー企業が StatusUpdateRequest を使用してネットワークハブ上の請求書の状況を更新すると、その情報がサプライヤに転送されます。StatusUpdateRequest は、1 つの OrderRequest ドキュメントの処理状況を更新します。

    例:

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE cXML SYSTEM "http://xml.cxml.org/schemas/cXML/1.2.014/cXML.dtd">
    <cXML xml:lang="en-US" payloadID="0c30050@supplierorg.com" timestamp="2000-01-08T23:00:06-08:00">
     <Header>
     <From>
     <Credential domain="NetworkId">
     <Identity>AN00000123</Identity>
     </Credential>
     </From>
     <To>
     <Credential domain="NetworkId">
     <Identity>AN00000456</Identity>
     </Credential>
     </To>
     <Sender>
     <Credential domain="NetworkId">
     <Identity>AN00000123</Identity>
     <SharedSecret>abracadabra</SharedSecret>
     </Credential>
     <UserAgent>Supplier’s Super Order Processor</UserAgent>
     </Sender>
     </Header>
     <Request>
     <StatusUpdateRequest>
     <DocumentReference payloadID="0c300508b7863dcclb_14999"/>
     <Status code="200" text="OK" xml:lang="en-US">Forwarded to supplier</Status>
     </StatusUpdateRequest>
     </Request>
    </cXML>
    

    この要求には、DocumentReference および Status 要素のみが含まれます。Status は、中間ハブで検出された最近の転送エラーを伝達できます。この要素のセマンティクスは、最初の HTTP 応答で OrderRequest ドキュメントに返された可能性がある Status と同じです。200/OK コードは、ドキュメントが保存され転送されたときに特に重要です。このコードは、サプライヤが OrderRequestの処理を開始したか、ハブがドキュメントを転送したことを示します。受領者には、200/OK を受信後にさらにStatusUpdateRequest ドキュメントが送られることはありません。StatusUpdate トランザクションを利用するサプライヤとハブは、OrderRequest が処理待ちのキューに入っている場合、201/Accepted コードを返する必要があります。200/OK を送信した後 (OrderRequest に対する即時のResponse や、その後の StatusUpdateRequest で) は、サーバーはこれ以上そのオーダーに対してStatusUpdate トランザクションを送信しません。その後の処理エラーによっては、このルールの例外が発生する場合があります。

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

    要素 説明
    DocumentReference 以前のドキュメント (OrderRequest または InvoiceDetailRequest など) を参照します。この要素は、状況更新要求を特定のドキュメントと関連付けます。「DocumentReference [290 ページ]」を参照してください。
    Status (必須) Response または Message の状況です。「Status [291 ページ]」を参照してください。
    PaymentStatus | SourcingStatus | InvoiceStatus | DocumentStatus | IntegrationStatus PaymentStatus は P カードトランザクションの状況更新です。「PaymentStatus[291 ページ]」を参照してください。SourcingStatus は既存のソーシングトランザクションの状況更新です。「SourcingStatus [292 ページ]」を参照してください。InvoiceStatus は請求書の状況更新です。「InvoiceStatus [292 ページ]」を参照してください。DocumentStatus はサービスシート、オーダー確認、または出荷通知の状況更新です。「DocumentStatus [294 ページ]」を参照してください。IntegrationStatus は外部システムからの状況更新です。「IntegrationStatus[296 ページ]」を参照してください。
    Extrinsic 状況更新に関連する追加情報が含まれます。

    13.2.1 DocumentReference

    DocumentReference 要素は、状況の更新を特定の OrderRequest または InvoiceDetailRequest ドキュメントに関連付けます。この要素は、前回のドキュメントの必須属性を繰り返し、サプライヤで生成された任意設定の識別子を 1 つ追加します。

    例:

    <DocumentReference payloadID="0c300508b7863dcclb_14999"/>
    

    DocumentReference には要素は含まれませんが、以下の属性があります。

    属性 説明
    payloadID
    (必須)
    ドキュメントを特定するために使用される、スペースと時間に関する一意の番号。この番号はログ作成のために使用されます。送信を再試行する場合、この値は変更しないでください。次のような実装を推奨します。

    datetime.process id.random number@hostname

    OrderRequest または InvoiceDetailRequest ドキュメントの cXML 要素から直接取得されます。

    DocumentReference は任意設定です。請求書の StatusUpdateRequest ドキュメントでは、InvoiceStatus 要素内で InvoiceIDInfo 要素を使用して、請求書を識別できます。

    13.2.2 Status

    Response または Message の状況です。この要素には、次の属性があります。

    属性 説明
    code
    (必須)
    HTTP または cXML 固有の状況コード。
    text
    (必須)
    状況コードのテキストバージョン。
    xml:lang テキスト属性および要素の内容で使用される言語

    13.2.3 PaymentStatus

    PaymentStatus 要素には、P カードトランザクションの状況が含まれます。状況の更新は、トランザクションの完了、取引 ID、認証 ID、オーダー ID、合計、税金、出荷情報、および元の申請のタイムスタンプなどの情報を含みます。StatusUpdateRequest ドキュメントは、ネットワークハブへの type=”RequestToPay” が指定されたConfirmationRequest に応答して、サプライヤに送信されます。この ConfirmationRequest はが支払サービスを起動します。これにより、ネットワークハブは支払サービスプロバイダを要求して、注文書に一覧された P カードに対してPOS トランザクションを実行し、トランザクションの状況を返します。その後、ネットワークハブはStatusUpdateRequest ドキュメントでサプライヤにトランザクションの状況を返信します。

    例:

    <StatusUpdateRequest>
     <DocumentReference payloadID="0c300508b7863dcclb_14999"/>
     <Status code="0" text="Approved">Approved</Status>
     <PaymentStatus orderID="PC100" transactionTimestamp="2000-01-08T10:00:06- 08:00" type="Sale" transactionID="V20000212000" authorizationID="PN123">
     <PCard number="1234567890123456" expiration="2003-03-31"/>
     <Total>
     <Money currency="USD">500.00</Money>
     </Total>
     <Shipping>
     <Money currency="USD">20.00</Money>
     <Description xml:lang="en">shipping charge</Description>
     </Shipping>
     <Tax>
     <Money currency="USD">40.00</Money>
     <Description xml:lang="en">CA Sales Tax</Description>
     </Tax>
     </PaymentStatus>
    </StatusUpdateRequest>
    

    PaymentStatus 要素には、必須の PCard および Total 要素と、任意設定の Shipping、Tax、および Extrinsic要素が含まれます。PCard 要素には、P カードの番号とその有効期限を指定する 2 つの属性が含まれます。
    PaymentStatus には次の属性があります。

    属性 説明
    orderID
    (必須)
    参照先のオーダーを識別します。この属性は、ConfirmDtionRequest またはOrderRequest からコピーされます。
    transactionTimeStamp
    (必須)
    支払トランザクションが送信された時刻を指定します。
    type
    (必須)
    P カードトランザクションのタイプを指定します。使用可能な値は次のとおりです。
    ● Authorization – P カードを承認します。P カード請求はされません。1 つのオーダーにつき 1 つの認証があります。
    ● Settlement— 以前の認証トランザクションによってセキュリティで保護された資金を転送します。
    ● Sale— P カードへの請求を開始します。
    ● Credit— 元の請求に対する払い戻しを開始します。バイヤーの見込みと一致しないオーダーを補償して、請求超過の勘定科目を調整したり、バイヤーによって返品された品目の勘定科目を払い戻したりします。
    transactionID 支払処理ゲートウェイによってトランザクションに割り当てられます。
    authorizationID 銀行によって提供されるトランザクションの認証コードです。

    13.2.4 SourcingStatus

    SourcingStatus 要素は、RFQ ソーシングトランザクションの更新情報である operation=”source” が設定されたPunchOutSetupRequest ドキュメントを提供します。

    <StatusUpdateRequest>
     <DocumentReference payloadID="123345678.RFQID:1234456787" />
     <Status code="200" text="OK">Approve Request</Status>
     <SourcingStatus action="approve" xml:lang="en"/>
    </StatusUpdateRequest>
    

    action 属性は、このトランザクションの更新タイプを特定します。“approve”、“cancel”、または “deny” を指定できま
    す。SourcingStatus 要素の本体には、RFQ の新しい状況に関する人間が判読可能な情報を含めることができます。

    13.2.5 InvoiceStatus

    請求書に StatusUpdateRequest を使用する場合は、InvoiceStatus 要素を含めます。

    <StatusUpdateRequest>
     <Status code="201" text="OK">Approved</Status>
     <InvoiceStatus type="reconciled">
     <InvoiceIDInfo invoiceID="INV123" invoiceDate="2005-04-20T23:59:20-07:00"/>
     </InvoiceStatus">
    </StatusUpdateRequest>
    

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

    属性 説明
    type
    (必須)
    請求書に対してバイヤー企業が行う処理を示します。使用可能な値は次のとおりです。
    ● processing – 請求書がバイヤー企業によって受領され、処理中です。
    ● reconciled – 請求書が正常に照合されました。請求書の金額は未払いです。
    ● rejected – 請求書の照合に失敗しました。バイヤー企業は、請求書を却下しました。Comments 要素には、請求書を却下した理由を説明する自由形式のテキストと、サプライヤが行わなければならない処理を含める必要があります。その後、サプライヤは訂正した請求書 (新しい請求書番号を付けた新しい請求書) を再送信できます。
    ● paying – 請求書は支払に対して承認済みであり、支払処理中です。
    ● paid – 請求金額がバイヤー企業により支払済みです。
    paymentNetDueDate この日時以降は割引なしで請求書を支払う必要があります。日付/時間値には、協定世界時 (UTC) からのタイムゾーンオフセットを含めることができます。「日付、時刻およびその他のデータタイプ [25 ページ]」を参照してください。支払期日は、バイヤーが請求書処理システムで行った設定に基づいて割引なしで請求書を支払う必要がある日時を決定します。支払期日の値は、法的に拘束力のある日付ではありません。実際の支払は、その日付よりも前または後に行われることがあります。

    次の例は、paymentNetDueDate を指定する InvoiceStatus を示しています。

    <StatusUpdateRequest>
     <DocumentReference payloadID="1600179659990@xyz.com"/>
     <Status code="200" text="OK" xml:lang="en"/>
     <InvoiceStatus type="reconciled" paymentNetDueDate="2021-05-31T00:00:00-08:00">
     <InvoiceIDInfo invoiceDate="2021-05-01T00:00:00-08:00" invoiceID="1234"/>
     </InvoiceStatus>
    </StatusUpdateRequest>
    
    13.2.5.1 InvoiceIDInfo

    InvoiceIDInfo 要素は、DocumentReference 要素を省略する場合に使用します。この要素は、DocumentReference によって要求される payloadID によってではなく、請求書 ID および日付によって固有の請求書ドキュメントを識別します。
    InvoiceIDInfo には次の属性があります。

    属性 説明
    invoiceID
    (必須)
    サプライヤが生成する請求書の識別子。この値は、請求書の InvoiceDetailRequestHeader に記述されていた invoiceID 属性です。
    invoiceDate 請求書が作成された日時。
    13.2.5.2 PartialAmount

    PartialAmount 要素により、バイヤー企業は請求書で指定された金額とは異なる支払金額を指定できます。請求書を全額支払う場合は、PartialAmount を含めないでください。PartialAmount がある場合は、差額についての詳細な説明を含む Comments 要素を読むようにサプライヤに警告されます。

    13.2.6 DocumentStatus

    サービスシートやオーダー確認などのドキュメントについて状況を更新します。DocumentStatus には次の属性があります。

    属性 説明
    type
    (必須)
    ドキュメント状況の種類を記述します。使用可能な値はネットワークハブまたは更新中のドキュメン
    トの種類に応じて異なります。
    サービスシート (ServiceEntryRequest) を更新する場合は、以下の値を使用できます。
    ● approved – バイヤー企業がサービスシートを承認しました。
    ● canceled – バイヤー企業がサービスシートを受信し、それをキャンセルしました。
    ● processing – バイヤー企業がサービスシートを受信し、それを処理中です。
    ● rejected – バイヤー企業がサービスシートを却下しました。Comments 要素には、サービスシートを却下した理由を説明する自由形式テキストとサプライヤが実行する必要がある処理が含まれています。サプライヤは、修正したサービスシート (たとえば、新しいserviceEntryID の ServiceEntryRequest ドキュメント) を再提出できます。

    オーダー確認 (ConfirmationRequest) を更新する場合、使用できる値はConfirmationStatusUpdate のみです。バイヤーが出荷通知 (ShipNoticeRequest) を更新する場合、バイヤーは値AcceptedWithChanges を使用して、出荷通知が変更の提案ありで承認されたことを示すことができます。

    以下に、サービスシートの DocumentStatus の例を示します。

    <Request>
     <StatusUpdateRequest>
     <DocumentReference payloadID="ss123456"></DocumentReference>
     <Status code="200" text=”OK></Status>
     <DocumentStatus type="approved">
     <DocumentInfo documentID="SES-1-A" documentType="ServiceEntryRequest" documentDate="2016-01-18T21:03:20-07:00 ">
     </DocumentInfo>
     <Comments>This service sheet has been approved.</Comments>
     </DocumentStatus>
     <StatusUpdateRequest>
    </Request>
    

    以下に、オーダー確認の DocumentStatus の例を示します。

    <Request>
     <StatusUpdateRequest>
     <DocumentReference payloadID="oc123456">
     </DocumentReference>
     <Status code="200" text="OK" />
     <DocumentStatus type="ConfirmationStatusUpdate">
     <!-- Status from the buyer's backend, lineNumber refers to the OC -->
     <ItemStatus type="rejected" code="out-of-tolerance">
     <ReferenceDocumentInfo lineNumber="1" />
     <Comments>Some back-ordered items have an out-of-tolerance delivery date.</Comments>
     </ItemStatus>
     <ItemStatus type="approved">
     <ReferenceDocumentInfo lineNumber="2" />
     </ItemStatus>
     </DocumentStatus>
     <StatusUpdateRequest>
    </Request>
    

    以下に、出荷通知の DocumentStatus の例を示します。Comments 要素には出荷通知に関する変更の提案が含まれます。コメントは情報目的のみであり、出荷通知には影響しません。

    <Request>
     <StatusUpdateRequest>
     <DocumentReference payloadID="ServiceOrderPayloadID12345">
     </DocumentReference>
     <Status code="200" text="OK"></Status>
     <DocumentStatus type="AcceptedWithChanges">
     <DocumentInfo documentID="SES-HC-t1" documentType="ShipNoticeDocument" documentDate="2018-08-12T21:03:20-07:00">
     </DocumentInfo>
     <Comments>proposed ship notice changes</Comments>
     </DocumentStatus>
     </StatusUpdateRequest>
    </Request>
    
    13.2.6.1 DocumentInfo

    システムで認識される更新前のドキュメントを識別します。この要素には、次の属性があります。

    属性 説明
    documentID
    (必須)
    システムで認識されるドキュメントの ID。
    documentType
    (必須)
    ドキュメントの種類。サービスシートの StatusUpdateRequest の場合、type はServiceEntryRequest です。
    documentDate 参照されるドキュメントが作成された日付。
    13.2.6.2 ItemStatus

    バイヤーが ConfirmationRequest に応答して StatusUpdateRequest を送信するとき、明細に関する詳細情報が含まれます。たとえば、バックエンド購買システムからの情報を含めることができます。ItemStatus には次の属性があります。

    属性 説明
    type
    (必須)
    明細の状況を指定します。使用可能な値は次のとおりです。
    ● rejected – 明細は却下されました。
    ● accepted – 明細は承認されました。
    code バックエンドシステムからの明細状況の任意設定のコードです。
    parentLineNumber 応答メッセージでこの明細の階層の親明細を識別するための対応する親明細の明細番号です。

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

    要素 説明
    ReferenceDocumentInfo
    (必須)
    参照されるドキュメントに関する情報が含まれます。「ReferenceDocumentInfo」を参照してください。
    Comments 明細の状況に関する任意のコメントを提供するための任意設定のフィールドです。
    13.2.6.3 Comments

    ドキュメントの状況に関する任意のコメントを提供するための任意設定のフィールドです。

    13.2.7 IntegrationStatus

    IntegrationStatus 要素により、外部当事者は、ドキュメントが処理されてネットワークハブによって配信された後にドキュメント状況を表示できるようになります。
    IntegrationStatus には次の属性があります。

    属性 説明
    documentStatus
    (必須)
    ドキュメント状況を示します。以下のいずれかの値になります。
    ● deliverySuccessful – ドキュメントは顧客に正常に配信されました (ただし、確認は処理中のため発行されていません)。
    ● deliveryDelayed – ドキュメントが顧客に届く途中で遅延が生じています。
    ● deliveryFailed – ゲートウェイと顧客間のエラーにより、ドキュメントを顧客に送信できませんでした。
    ● deliveryReady – バイヤーへの送信時に、ドキュメントが送信待ちになり、いつでも取得可能な状態です。
    ● customerConfirmed – 顧客は、ドキュメントが正常に処理されたことを確認しました。
    ● customerReceived – 顧客は、ドキュメントを正常に受信したことを確認しました。
    ● customerFailed – 顧客がドキュメントを受信しましたが、コンテンツ内のエラーを報告中です。

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

    要素 説明
    IntegrationMessage 外部当事者が受け取ったメッセージのタイプ/結果を示します。次の 2 つの必須属性があります。
    ● isSuccessful – メッセージが肯定的であるか、否定的であるかを示します。
    ● type – メッセージタイプ (997/824/MDN など) を示します。

    以下に IntegrationStatus 情報を含む StatusUpdateRequest の例を示します。

    <StatusUpdateRequest>
     <DocumentReference payloadID="1DA85A45-C90E-4668-AE9D-A85F4612E7E5"></DocumentReference>
     <Status text="Processed" code="201">Positive 824 received.</Status>
     <IntegrationStatus documentStatus="customerConfirmed">
     <IntegrationMessage isSuccessful="yes" type="824"/>
     </IntegrationStatus>
    </StatusUpdateRequest>
    

    13.2.8 Extrinsic

    Extrinsic 要素には、更新中のドキュメントの状況に関する追加情報を含めることができます。

    13.3 ConfirmationRequest

    このトランザクションは、特定のオーダー申請に関する詳細な状況の更新を提供します。このトランザクションでは、
    StatusUpdateRequest によって提供されるオーダーの簡易認知を詳細な明細レベルの確認および出荷通知に拡張
    します。

    注記
    このトランザクションの DTD は、cXML.dtd ではなく、Fulfill.dtd に含まれます。

    このトランザクションでは、特定の Response ドキュメントは必要ありません。サーバーは、一般的な Response ドキュメントで ConfirmationRequest に応答する必要があります。ドキュメントは、ConfirmationHeader 要素の type 属性で指定される “accept”、“allDetail”、“detail”、“backordered”、“except”、“reject”、“requestToPay”、および “replace” のいずれかのタイプになります。”detail” タイプを使用すると、注文書の一部 (価格、数量、配達日など) の更新/却下や、税および出荷情報の追加を行うことができます。指定した明細のみが変更されます。”allDetail” タイプを使用すると、オーダーを却下または承認しなくても、指定した明細のすべての情報を更新できます。“accept”、“reject”、および “except” タイプを使用して、オーダー申請全体に確認を適用できます。”allDetail” および “detail” は個別の明細を更新しますが、オーダー全体の承認または却下は行いません。
    type=”requestToPay” の ConfirmationRequest は、支払サービスを起動します。これにより、ネットワークハブは支払サービスプロバイダを要求して、注文書に一覧表示された P カードに対して POS トランザクションを実行し、トランザクションの状況を返します。その後、ネットワークハブは StatusUpdateRequest ドキュメントでサプライヤにトランザクションの状況を返信します。

    次の例は、accept タイプの ConfirmationRequest 要素を示しています。

    <ConfirmationRequest>
     <!-- Without the confirmID, it remains possible to update this confirmation. An update would refer (in the OrderReference element) to the same OrderRequest document, would describe the status of the same items, and would point to this document through its DocumentReference element. However, the confirmID makes the update much more explicit.-->
     <ConfirmationHeader type="accept" noticeDate="2000-10-12T18:39:09-08:00" confirmID="C999-234" invoiceID="I1010-10-12">
     <Shipping>
     <Money currency="USD">2.5</Money>
     <Description xml:lang="en-CA">FedEx 2-day</Description>
     </Shipping>
     <Tax>
     <Money currency="USD">0.19</Money>
     <Description xml:lang="en-CA">CA Sales Tax</Description>
     </Tax>
     <Contact role="shipFrom">
     <Name xml:lang="en-CA">Workchairs, Vancouver</Name>
     <PostalAddress>
     <Street>432 Lake Drive</Street>
     <City>Vancouver</City>
     <State isoStateCode="CA-BC">BC</State>
     <PostalCode>B3C 2G4</PostalCode>
     <Country isoCountryCode="CA">Canada</Country>
     </PostalAddress>
     <Phone>
     <TelephoneNumber>
     <CountryCode isoCountryCode="CA">1</CountryCode>
     <AreaOrCityCode>201</AreaOrCityCode>
     <Number>9211132</Number>
     </TelephoneNumber>
     </Phone>
     </Contact>
     <Comments xml:lang="en-CA">Look's great</Comments>
     </ConfirmationHeader>
     <!-- The orderID and orderDate attributes are not required in the OrderReference element. -->
     <OrderReference orderID="DO1234">
     <DocumentReference payloadID="32232995@hub.acme.com" />
     </OrderReference>
    </ConfirmationRequest>
    

    複数の “detail” ConfirmationRequest ドキュメントが 1 つの注文書を参照することはできますが、共通の明細を参照することはできません。差し替えを実行するには、ConfirmationItem 要素を含めて置き換える品目を指定し、置き換える新しい ItemIn 要素を提供します。ItemIn 要素は差し替えでのみ使用してください。その後、サプライヤは出荷する前に、バイヤーから変更オーダーによる返答が送られるまで待つ必要があります。ConfirmationRequest 要素は、受信サーバー側のオーダーに関する既知のデータに確認情報を追加するための依頼です。ConfirmationHeader、OrderReference、および ConfirmationItem (任意設定) の 3 つの要素を含めることができます。ConfirmationHeader で指定された確認依頼の type が “detail” または “except” のいずれかである場合は、ConfirmationItem 要素を含めて、注文書の特定の明細を更新することができます。サプライヤは、1 つの注文書に対して複数の確認処理 (ConfirmDtionRequest) を送ることができますが、各確認処理で指定できるオーダー明細は、1 明細につき 1 回のみです。また、特定のオーダー明細を複数の確認申請で指定することはできません。複数の確認は、”allDetail” または “detail” の場合にのみ実用的に許可されます。”accept”、”except”、または “reject” の場合は、オーダーごとに 1 つの確認のみが許可されます。これらのいずれかのタイプの確認を受け取った場合、受信側のシステムは注文書に対する以前のすべての確認を破棄する必要があります。ConfirmationItem 要素は、ConfirmationRequest ドキュメント内では任意の順序で使用できます。ただし、lineNumber 要素は、昇順で一覧することを推奨します。また、ConfirmationRequest 要素の中では明細を複数回使用することはできません。ConfirmationRequest に OrderStatusRequestReference および OrderStatusRequestIDInfo を任意設定の要素として含めると、ConfirmationRequest. に関連付られている OrderStatusRequest を明示的に参照することができます。

    13.3.1 OrderReference

    OrderReference 要素は、注文書への明確な参照を提供します。含まれる DocumentReference で明確な参照を提供しながら、OrderReference の追加属性では ConfirmationRequest および ShipNoticeRequest を単独で参照することができます。OrderReference には、DocumentReference 要素と 2 つの属性 orderID およびorderDate が含まれます。

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

    属性 説明
    orderID 確認のためのバイヤーシステムの orderID (注文書番号) を指定します。この属性を使用する場合は、参照される OrderRequestOrderRequestHeader 要素から値を直接コピーする必要があります。
    orderDate OrderRequest が作成された日時を指定します。この属性を使用する場合は、参照されるOrderRequest OrderRequestHeader 要素から値を直接コピーする必要があります。

    13.3.2 ConfirmationHeader

    ConfirmationHeader 要素には、ConfirmationRequest に含まれるすべての明細に共通する情報が含まれます。この要素には、次の属性があります。ConfirmationHeader には次の属性があります。

    属性 説明
    confirmID サプライヤによって割り当てられたドキュメントに対する、サプライヤが指定する任意設定の識別子です。この属性は、ドキュメントの payloadID に続いてユーザーに表示されます。この値は、特定の確認が更新されても変更されることはありません。すなわち、同じオーダーの同じ明細の状況を記述する operation=”update” が設定されたドキュメントは、operation=”new”が設定された元の ConfirmDtionRequest と confirmID を共有します。confirmID が operation=”new” の ConfirmDtionRequest で使用されていない場合は、対応する operation=”update” ドキュメントでそれを使用することはできません。更新のConfirmationHeader に含まれる DocumentReference 要素と、元または前回の更新のpayloadID 属性により、2 つのドキュメントがリンクされます。
    operation 確認が新規であるか、前回の確認の更新であるかを指定します。使用可能な値は次のとおりです。
    ● new – 通常設定の値です。一度も ConfirmDtionRequest は送信されていません。
    ● update – 前回の ConfirmDtionRequest を更新します。confirmID は、前回の申請のconfirmID と一致している必要があります。
    type
    (必須)
    確認のタイプを指定します。使用可能な値は次のとおりです。
    ● accept – 参照される注文書に記述されているとおりに、オーダー全体を承認します。この種類のドキュメントには、ConfirmationItem 要素を含めることができます。これらの要素には、type=”accept” の ConfirmationStatus 要素のみを含める必要があります。
    ● allDetail – 特定の明細のみを更新します。指定されていない明細については、現在の状況が維持されます。”detail” タイプとは異なり、このタイプの確認には、元の OrderRequest ドキュメントで提供されたデータと異なるかどうかを問わず、サプライヤが認識しているすべての情報が含まれます。この確認は、現在の EDI およびオーダーエントリツールと互換性があります。通常、これらのツールは、サプライヤのシステムにあるオーダーのスナップショットをバイヤーに送信します。このタイプの確認では照合の問題が発生するため、このタイプは短期間の「つなぎ」として使用することを推奨します。
    この確認には ConfirmationItem 要素を含め、ConfirmationStatus 要素は”allDetail”、”reject”、または “unknown” タイプにする必要があります。”accept” または “detail” ConfirmationStatus タイプは競合する可能性があるため、これらを含めないでください。
    ● detail – 個々の明細を更新します。指定されていない明細については、現在の状況が維持されます。このドキュメントタイプには、注文書で提供された情報とは異なる情報のみを定義します。前の ConfirmationRequest で記述したバリエーションは、注文書で提供された情報を復元する後の ConfirmationRequest ドキュメントには含めないでください。たとえば、Tax 要素は、ある ConfirmationRequest の ConfirmationStatus で使用されますが、その確認の更新では使用されません。これは、注文書に正しい請求が含まれていたことを示します。このドキュメントの種類には、ConfirmationItem 要素を含める必要があります。また、ConfirmationStatus 要素には “allDetail” 以外の任意のタイプを含めることができます。
    ● backordered – 注文書全体を入荷待ち状況に設定します。サプライヤには品目の在庫がありませんが、入手可能になったときに出荷します。
    ● except – 一部の例外を除き、注文書全体を承認します。指定されていない明細は、注文書に記述されている内容のとおりです。このドキュメントの種類には、ConfirmationItem 要素を含める必要があります。また、ConfirmationStatus 要素には “allDetail” 以外の任意のタイプを含めることができます。
    noticeDate
    (必須)
    ConfirmationRequest ドキュメントが作成された日時を指定します。
    invoiceID この確認で記述された明細に関連付けられている請求書のサプライヤが生成した任意設定の識別子。これは、実際の請求書の一番上に表示される請求書番号と同一です。
    incoTerms 国際商工会議所 (International Chamber of Commerce) によって定義された任意設定の出荷条件を指定します。これらの条件により、バイヤーは出荷費用のうち何割を負担するかを知ることができます。使用可能な値は次のとおりです。

    ● cfr – 運賃込み (CFR)
    ● cif – 運賃保険料込み (CIF)
    ● cip – 輸送費保険料込み (CIP)
    ● cpt – 輸送費込み (CPT)
    ● daf – 国境渡し
    ● ddp – 関税込み持込渡し (DDP)
    ● ddu – 関税抜き持込渡し (DDU)
    ● deq – 埠頭持込渡し (関税込み)
    ● des – 本船持込渡し
    ● exw – 工場渡し (EXW)
    ● fas – 船側渡し (FAS)
    ● fca – 運送人渡し (FCA)
    ● fob – 本船渡し (FOB)

    version この確認のバージョン番号。1 で始まり、後続バージョン (2、3、4…) ごとに 1 を追加する必要があります。

    ConfirmationHeader 要素には、次の要素を含めることができます。

    ● DocumentReference
    ● Tax
    ● Shipping
    ● Total
    ● Contact
    ● Hazard
    ● Comments
    ● IdReference
    ● Extrinsic

    ConfirmationHeader が “allDetail”、”detail”、または “except” のいずれかである場合は、ConfirmationItem 要素を含めて、注文書の特定の明細を更新することができます。
    タイプ “except” の ConfirmationRequest の例を次に示します。

    <ConfirmationRequest>
     <!-- Without the confirmID, it remains possible to update the original confirmation. This update refers (in the OrderReference element) to the same OrderRequest document, describes the status of the same items and refers to the original confirmation document in the DocumentReference element. However, the confirmID makes the update much more explicit. Note: The noticeDate changes to match the time of the update and not the original confirmation time.-->
     <ConfirmationHeader type="except" noticeDate="2000-10-13T18:39:09-08:00" confirmID="C999-234" operation="update" invoiceID="I1102-10-13">
     <DocumentReference payloadID="1233444-2001@premier.workchairs.com" />
     <Total>
     <Money currency="USD">190.60</Money>
     </Total>
     <Shipping>
     <Money currency="USD">2.5</Money>
     <Description xml:lang="en-CA">FedEx 2-day</Description>
     </Shipping>
     <Tax>
     <Money currency="USD">0.19</Money>
     <Description xml:lang="en-CA">CA Sales Tax</Description>
     </Tax>
     <Contact role="shipFrom">
     <Name xml:lang="en-CA">Workchairs, Vancouver</Name>
     <PostalAddress>
     <Street>432 Lake Drive</Street>
     <City>Vancouver</City>
     <State>BC</State>
     <PostalCode>B3C 2G4</PostalCode>
     <Country isoCountryCode="CA">Canada</Country>
     </PostalAddress>
     <Phone>
     <TelephoneNumber>
     <CountryCode isoCountryCode="CA">1</CountryCode>
     <AreaOrCityCode>201</AreaOrCityCode>
     <Number>9211132</Number>
     </TelephoneNumber>
     </Phone>
     </Contact>
     <Comments xml:lang="en-CA">Look's great, but for the price.</Comments>
     </ConfirmationHeader>
     <!-- The orderID and orderDate attributes are not required in the OrderReference element. -->
     <OrderReference orderID="DO1234">
     <DocumentReference payloadID="32232995@hub.acme.com" />
     </OrderReference>
     <ConfirmationItem lineNumber="1" quantity="10">
     <UnitOfMeasure>EA</UnitOfMeasure>
     <ConfirmationStatus quantity="10" type="detail" shipmentDate="2000-10-14" deliveryDate="2000-10-19">
     <UnitOfMeasure>EA</UnitOfMeasure>
     <UnitPrice>
     <Money currency="USD">1.64</Money>
     </UnitPrice>
     <Comments xml:lang="en-CA">Very sorry. There's been a slight (30 cents) price increase for that colour and it will be one day late.
     </Comments>
     </ConfirmationStatus>
     </ConfirmationItem>
    </ConfirmationRequest>
    
    13.3.2.1 DocumentReference

    DocumentReference 要素は、operation が “update” である場合にのみ表示されます。この要素は、通常は共通の confirmID で示される特定の確認に対して、最新の ConfirmationRequest ドキュメントを参照する必要があります。たとえば、確認を作成、更新、および再度更新する場合、最終的なドキュメントには operation=”update” を指定した、前の ConfirmationRequest を参照する DocumentReference を含める必要があります。そのドキュメントは、次に、元の operation=”new” の ConfirmationRequest ドキュメントを参照します。

    13.3.2.2 Tax および Shipping

    Tax および Shipping の金額は、対応する明細情報なしでも、新しい値で更新して確認に含めることができます。

    13.3.2.3 Total

    ConfirmationItem に新しい UnitPrice または quantity の記述がない場合、Total 値は OrderRequest ドキュメントの値と一致する必要があります。Total、Tax、および Shipping 情報が元のオーダーの金額と一致する場合、この情報を OrderRequest ドキュメントからコピーする必要はありません。Total 要素には、品目の元の価格または出荷価格の変更を格納する Modifications 要素も含まれます。この要素には、1 つまたは複数の Modification 要素を格納できます。Modification 要素には、ヘッダーレベルで適用可能な値引きおよび手数料の詳細が含まれます。詳細については、「Total」を参照してください。

    13.3.2.4 Contact

    Contact 要素は、主にオーダーについての新しい情報を追加するために使用します。OrderRequest ドキュメントからこの情報をコピーする必要はありません。
    Contact role values には以下の属性が含まれます。

    属性 説明
    technicalSupport テクニカルサポート
    customerService カスタマサービス
    sales 販売部門
    shipFrom このオーダーに関連する出荷の出発点
    shipTo OrderRequest ドキュメントからコピーした ShipTo 要素
    payTo このオーダーの支払いの送信先
    billTo OrderRequest ドキュメントからコピーした BillTo 要素
    supplierCorporate 企業のサプライヤ
    Contact 一覧内の要素は任意の順序で指定できます。Contact role は、ConfirmationHeader 要素内で複数回使用することはできません。
    13.3.2.5 Hazard

    Hazard 一覧内の要素は任意の順序で指定できます。同じ Hazard を ConfirmationHeader 要素内の一覧に複数回含めることはできません。このレベルで一覧に含めた各 Hazard は、オーダー全体、または確認で指定したすべての品目に適用される必要があります。1 つの品目の状況を更新する ConfirmationRequest には、ConfirmationItem 要素の Hazard 要素を含めないでください。詳細については、「Hazard」を参照してください。

    13.3.2.6 コメント

    Comments 要素には、オーダー全体の状況、または支払条件、出荷条件に関する追加詳細、および状況の説明などのこの確認で記述される部分の状況に関する追加情報を含めることができます。状況の情報には、”入荷待ち”、”出荷済み”、および “無効” などの用語が適しています。このようなデータはすべて、ユーザーに対して使用することを目的としています。

    13.3.2.7 IdReference

    ID 参照を定義します。識別子/ドメインのペアは、それぞれの取引先との取引関係 (バイヤー企業およびサプライヤ) において一意であることが必要です。
    IdReference には次の属性があります。

    属性 説明
    identifier
    (必須)
    ドメイン内にある IdReference の一意の識別子です。domain が supplierReference である場合、identifier は以下のいずれかの値を指定できます。
    ● 内部サプライヤ番号 – これは最も一般的なシナリオです。内部サプライヤ ERP システムによって作成されたドキュメント番号を表します。
    ● 契約番号 – 契約番号を使用して、特定の送信ドキュメントが特定の契約に関連していることを特定することができます。
    ● 内部基準 – サプライヤは、[サプライヤ参照番号] フィールドにカスタマイズした値を入力できる場合があります。たとえば、トランザクションのフォローアップの担当者名を入力できます。
    domain
    (必須)
    IdReference のドメインです。使用可能な値は次のとおりです。accountID, bankRoutingID, accountPayableID, accountReceivableID, bankAccountID, ibanID, abaRoutingNumber, bankNationalID, isoBicID, swiftID, bankBranchID, federalTaxID, stateTaxID, provincialTaxID, vatID, gstID、および taxExemptionID。supplierTaxID は廃止され、federalTaxID として処理されます。その他の使用可能な値には、1099ID、courtRegisterID、supplierReference、governmentNumber、documentName などがあります。

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

    要素 説明
    Creator この IdReference の作成者。
    Description IdReference の人間が解読可能なテキスト記述。
    13.3.2.8 Extrinsic

    Extrinsic 要素の一覧を使用して、アプリケーションで使用するオーダーに関する追加データを挿入できます。これらの要素には、受信側のシステムのワークフローに影響する、事前定義されたキーワードや値を組み込むことができます。Extrinsic 一覧内の要素は任意の順序で指定できます。Extrinsic タイプは、ConfirmationHeader 要素内で複数回使用しないでください。この一覧と特定の ConfirmationStatus 要素の両方で、このタイプを指定しないでください。ConfirmationHeader には、この下位レベルで上書きされた通常設定のエクストリンジック値を含めないでください。

    13.3.3 ConfirmationItem

    ConfirmationItem 要素は、特定の明細の状況を詳細に記述します。ConfirmationItem 要素には、次の要素を含めることができます。UnitOfMeasure、ConfirmationStatus、Contact、および Hazard。ConfirmationStatus は、複数回使用することができます。Contact のみが任意設定です。ConfirmationItem には次の属性があります。

    属性 説明
    quantity
    (必須)
    オーダーされた品目の数を指定します。UnitOfMeasure 要素で指定された単位で表されます。対応するOrderReference 要素内の明細の ItemOut 要素の数量値と一致します。
    lineNumber
    (必須)
    1 から始まるオーダーの明細番号です。OrderReference 要素で参照されるドキュメント内の対応する明細 ItemOut と一致します。
    parentLineNumber 対応する親明細の明細番号。この属性は、itemType=”item” が設定された明細にのみ適用できます。
    itemType 品目の種類を指定します。使用可能な値は次のとおりです。
    ● composite – 品目グループを識別します。
    ● item – 独立した明細を識別します。
    ● lean – 明細で予定されている子品目がないことを示します。
    compositeItemType 親品目でグループごとの価格設定が使用されるかどうかを指定します。使用可能な値は”groupLevel” または “itemLevel” です。複数の ConfirmationRequest ドキュメントを使用して、オーダー全体の状況を更新できますが、特定の明細は、1 つのドキュメント内とそのドキュメント内の 1 つの ConfirmationItem でしか指定することはできません。
    13.3.3.1 Contact

    ConfirmationItem 内の Contact 要素を使用して、品目に固有の連絡先を記述します。この要素は、任意の順序で指定できます。特定の Contact role を指定する場合、ConfirmationItem または ConfirmationHeader のいずれかで指定できますが、両方で指定することはできません。ConfirmationItem 内で同じ role を複数回指定しないでください。Contact 一覧内では、任意の順序で要素を一覧表示できます。ConfirmationItem 要素内では Contact role 属性を複数回追加しないでください。

    13.3.3.2 Hazard

    Hazard」を参照してください。

    13.3.3.3 ConfirmationStatus

    ConfirmationStatus 要素は、特定の明細またはその明細の一部の状況を示します。このレベルの数量の合計は、この要素を含む ConfirmationItem の数量と一致する必要があります。ConfirmationItem 要素と、その中に含まれる ConfirmationStatus 要素内では、一貫した UnitOfMeasure を使用してください。差し替えの場合は、ItemIn 要素内に含まれる ItemDetail では異なる UnitOfMeasure を使用できます。明細を承認または却下する場合、ConfirmationStatus 要素には UnitOfMeasure 要素のみを含めます。ItemIn 要素は、差し替えを推奨する場合にのみ使用します。差し替えの場合は、UnitOfMeasure が変更されない限り、ItemIn 要素の数量を、それを含む ConfirmationStatus の数量と一致させる必要があります。この場合、ItemIn 要素内に ItemDetail 要素が必要です。ConfirmationStatus 要素には、Modifications 要素も含まれます。Modification 要素には、明細レベルで適用可能な値引きおよび手数料の詳細が含まれます。詳細については、「Total」を参照してください。
    次の例は、Modification 要素を示しています。

    <ConfirmationItem quantity = "3" lineNumber = "1">
     <UnitOfMeasure>DZ</UnitOfMeasure>
     <ConfirmationStatus type = "unknown" quantity = "1">
     <UnitOfMeasure>DZ</UnitOfMeasure>
     </ConfirmationStatus>
     <ConfirmationStatus type = "accept" quantity = "2">
     <UnitOfMeasure>DZ</UnitOfMeasure>
     <UnitPrice>
     <Money currency = "USD">47</Money>
     <Modifications>
     <Modification>
     <OriginalPrice>
     <Money currency = "USD">45.00</Money>
     </OriginalPrice>
     <AdditionalDeduction>
     <DeductionAmount>
     <Money currency = "USD">5.00</Money>
     </DeductionAmount>
    </AdditionalDeduction>
     <ModificationDetail name = "Allowance" startDate = "2012-08-03T10:15:00-08:00" endDate = "2013-11-30T10:15:00-08:00">
     <Description xml:lang = "en-US">Contract Allowance
     <Description>
     </ModificationDetail>
     </Modification>
     </Modifications>
     </UnitPrice>
     <Tax>
     <Money currency = "USD">7.0</Money>
     <Description xml:lang = "en">Tax</Description>
     <TaxDetail category = "Other">
     <TaxAmount>
     <Money currency = "USD">5.0</Money>
     </TaxAmount>
     </TaxDetail>
     <TaxDetail category = "QST">
     <TaxAmount>
     <Money currency = "USD">2.0</Money>
     </TaxAmount>
     </TaxDetail>
     </Tax>
     </ConfirmationStatus>
    </ConfirmationItem>
    

    すべての部分を差し替えなくても、ConfirmationStatus 要素で UnitPrice、Tax、および Shipping の金額を更新できます。この情報は、OrderRequest ドキュメントからコピーする必要はありません。UnitPrice、Tax、およびShipping が元の ItemOut 要素の金額と一致する場合は、それらの要素を含めないでください。数量ベースの価格設定を含むオーダーを確認している場合は、ConfirmationStatus 要素内の PriceBasisQuantity を更新することもできます。タイプが “accept”、”allDetail”、または “detail” である場合は、元のオーダーで指定されていない税額または出荷費用を追加することができます。オーダーへの変更がこれらの追加のみである場合は、”accept” タイプを使用します。”detail” タイプを使用して、ItemIn 要素がある場合は差し替え、UnitPrice 要素がある場合は価格変更、deliveryDate 属性がある場合は遅延出荷を示します。”allDetail” タイプでは、元のオーダー以降に何が変更されたかを判断するために照合ソフトウェアが必要です。
    ConfirmationStatus には次の属性があります。

    属性 説明
    quantity
    (必須)
    この状況にある明細の数を指定します。UnitOfMeasure 要素で指定した単位で表されます。
    type
    (必須)
    オーダーのこの部分の状況を指定します。使用可能な値は次のとおりです。
    ● accept – 参照される ItemOut 要素で記述されているように、この部分を承認します。
    ● allDetail – この ConfirmationStatus 要素の内容に示されているように、明細のこの部分を承認します。これらの内容では、出荷内容を詳細に記述します。”detail” タイプとは異なり、この確認のタイプには、元の OrderRequest ドキュメントで提供されているデータと異なるかどうかを問わず、サプライヤが認識しているすべての情報が含まれます。このタイプは、現在の EDI とオーダーエントリツールに互換性を持たせるために提供されています。オーダーエントリツールは通常、サプライヤのシステムから、オーダーのスナップショットをバイヤーに送信します。このタイプの確認では照合の問題が発生するため、このタイプは、短期間の「つなぎ」として使用することを推奨します。ConfirmationHeader タイプが “allDetail” であるドキュメントでのみ使用できます。
    ● detail – ConfirmationStatus 要素で示された変更部分を承認します。UnitPrice、Shipping、Tax、または ItemIn 要素のうち少なくとも 1 つ、もしくは deliveryDate 属性が必要です。これは、ItemIn 要素がある場合は差し替え、UnitPrice 要素がある場合は価格変更、deliveryDate 属性がある場合は遅延出荷になります。
    ● reject – 明細のこの部分を却下します。
    ● requestToPay – 明細のこの部分に対する支払いを要求します。部分明細に対する決済処理を金融機関に始めるよう指示する要求を開始します。このタイプは、要求全体 (ConfirmationHeader) のタイプが “requestToPay” であるドキュメントでのみ使用できます。
    ● unknown – この確認時における明細のこの部分の状況は不明です。この明細の状況では、サプライヤが詳細を検索する場合のプレースホルダが提供されます。以前の確認で明細の部分が誤って承認または却下された場合は、更新確認で明細の部分の状況を “unknown” にリセットすることもできます。ConfirmationHeader タイプが “allDetail”、”detail”、または “except” であるドキュメントでのみ使用できます。
    ● backordered – 明細のこの部分を入荷待ち状況に設定します。サプライヤには品目の在庫がありませんが、入手可能になったときに出荷します。
    shipmentDate サプライヤからこの出荷品が発送される日時を指定します。タイプが “accept”、”allDetail”,または “detail” である場合に、ConfirmationStatus 要素を使用してこの情報を含めます。
    deliveryDate この出荷が到着する新しい日時を指定します。対応する OrderRequest ドキュメントでrequestedDeliveryDate 属性 (存在する場合) とこの値が一致する場合は、この属性を含めないでください。そうでない場合は、タイプが “accept”、”allDetail”, または “detail” である場合に、ConfirmationStatus 要素を使用してこの情報を含めます。

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

    要素 説明
    UnitOfMeasure
    (必須)
    製品を梱包して出荷する方法を記述します。数量単位の共通コードである UN/CEFACT 単位に準拠している必要があります。参照資料 www.unece.org/cefact/codesfortrade/codes_index.html を参照してください。
    ItemIn | (UnitPrice, Tax, Shipping) 購買アプリケーションでショッピングカートから購入申請に追加された品目を表すItemIn、あるいは UnitPrice、Tax、または Shipping の詳細のいずれかを入力します。
    SupplierBatchID 1 回の生産実行で生産される品目/商品を識別するためのサプライヤからの ID。「SupplierBatchID または Batch」を参照してください。
    ScheduleLineReference 確認の納入日程行に関連するすべての参照を定義します。「ScheduleLineReference」を参照してください。
    ComponentConsumptionDetails 最終製品の製造における構成品目の消費に関する詳細情報が含まれます。「ComponentConsumptionDetails」を参照してください。
    Comments 確認の状況に関連するコメントが含まれます。”backordered”、”shipped”, および “invalid” などの用語を使用すると実用的です。こうしたデータは、ユーザーが使用することを目的としています。
    Extrinsic アプリケーションで使用するこの確認の状況に関連する追加情報が含まれます。これらの要素には、受信側のシステムのワークフローに影響する、事前定義されたキーワードや値を組み込むことができます。
    Extrinsic 一覧内の要素は任意の順序で指定できます。エクストリンジック属性値は、ConfirmationStatus 要素内で複数回使用しないでください。この一覧と全体の ConfirmationHeader 要素の両方で同じタイプを指定ないでください。ConfirmationHeader には、この下位レベルで上書きされた通常設定のエクストリンジック値を含めないでください。

    サービス明細に関する ConfirmationStatus の例を次に示します。

    <ConfirmationItem itemType="item" parentLineNumber="10" quantity="80.000" lineNumber="1000100010">
     <UnitOfMeasure>EA</UnitOfMeasure>
     <ConfirmationStatus type="accept" quantity="70">
     <UnitOfMeasure>EA</UnitOfMeasure>
     <ItemIn lineNumber="1000100010" quantity="70">
     <ItemID>
     <ItemDetail>
     <ItemID>
     <UnitPrice>
     <Money currency="USD">2.00</Money>
     </UnitPrice>
     <Description xml:lang="EN">Consulting services</Description>
     <UnitOfMeasure>EA</UnitOfMeasure>
     <PriceBasisQuantity conversionFactor="1" quantity="1">
     <UnitOfMeasure>EA</UnitOfMeasure>
     </PriceBasisQuantity>
     <Classification domain="UNSPSC">007</Classification>
     </ItemDetail>
     <Period startDate="2019-06-27T00:00:00-00:00" endDate="2019-12-27T23:59:59-00:00"/>
     </ItemIn>
     </ConfirmationStatus>
     <ConfirmationStatus type="unknown" quantity="10.000">
     <UnitOfMeasure>EA</UnitOfMeasure>
    </ConfirmationStatus>
    </ConfirmationItem>
    
    13.3.3.3.1 ScheduleLineReference

    確認の納入日程行に関連するすべての参照を定義します。
    ScheduleLineReference には次の属性があります。

    属性 説明
    quantity
    (必須)
    現在のドキュメントによって参照される、OrderRequest ドキュメントの ScheduleLine 要素からの数量。
    requestedDeliveryDate
    (必須)
    現在のドキュメントによって参照される、OrderRequest ドキュメントの ScheduleLine 要素からの納品予定日。
    lineNumber 現在のドキュメントによって参照される、OrderRequest ドキュメントの ScheduleLine 要素からの明細の識別子。

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

    要素 説明
    Extrinsic この ScheduleLineReference に関連する追加情報が含まれます。

    ScheduleLineReference の例を次に示します。

    <ConfirmationRequest>
     <ConfirmationHeader noticeDate="2018-06-25T10:44:43-07:00" type="detail" operation="new">
     </ConfirmationHeader>
     <OrderReference orderDate="2018-06-25T10:43:46-07:00" orderID="Order00001">
     <DocumentReference payloadID="payload@10.163.1.39"/>
     </OrderReference>
     <ConfirmationItem quantity="12" lineNumber="1">
     <UnitOfMeasure>PK</UnitOfMeasure>
     <ConfirmationStatus type="accept" quantity="5">
     <UnitOfMeasure>PK</UnitOfMeasure>
     <ScheduleLineReference requestedDeliveryDate="2018-06-01T00:00:00-07:00" quantity="12" lineNumber="1"/>
     </ConfirmationStatus>
     <ConfirmationStatus type="accept" quantity="7" >
     <UnitOfMeasure>PK</UnitOfMeasure>
     <ScheduleLineReference requestedDeliveryDate="2018-06-01T00:00:00-07:00" quantity="12" lineNumber="1"/>
     </ConfirmationStatus>
     </ConfirmationItem>
    </ConfirmationRequest>
    

    13.4 OrderStatusRequest

    バイヤーは、OrderStatusRequest ドキュメントを使用して、まだ完了していないオーダーに関する状況レポートをサプライヤに要求できます。バイヤーは、オーダーの状況、配達日、出荷済み品目の現在の場所、または送信済みの注文書に関するその他の関連情報について、サプライヤに情報を求めることができます。
    OrderStatusRequest ドキュメントには、以下の要素が含まれています。

    ● OrderStatusRequestHeader
    ● OrderStatusRequestItem

    13.4.1 OrderStatusRequestHeader

    OrderStatusRequestHeader 要素は、OrderStatusRequest ドキュメントに関する参照情報を格納します。
    OrderStatusRequestHeader 要素には以下の要素が含まれます。

    要素 説明
    OrderReference | OrderIDInfo 注文書への参照です。OrderReference 情報または OrderIDInfo 情報のいずれかを指定できます。
    Contact バイヤーの連絡先情報です。このフィールドは必須です。
    Comments この要素は、バイヤーからのコメントを格納します。これは任意設定のフィールドです。
    Extrinsic バイヤーから送信された Extrinsic です。これは任意設定のフィールドです。

    OrderStatusRequestHeader 要素には以下の属性が含まれます。

    Attribute Name (属性名) 説明
    orderStatusRequestID
    (必須)
    OrderStatusRequest を送信するバイヤーのシステム ID。これはバイヤーの一意の内部番号です。
    orderStatusRequestDate
    (必須)
    OrderStatusRequest がバイヤーによって作成された日時。

    以下の例は、OrderStatusRequestHeader 要素の使用方法を示したものです。

    <OrderStatusRequestHeader orderStatusRequestID="osrFor_order02_08.20" orderStatusRequestDate="2013-02-06T16:09:26-08:00">
     <OrderReference orderID="order02_08.20" orderDate="2013-02-06T16:09:26-08:00">
     <DocumentReference payloadID="order02_08.20@cvbuyer.com"/>
     </OrderReference>
     <Contact role="soldTo" addressID="AA20">
     <Name xml:lang="en">Lisa Dollar</Name>
     <PostalAddress name="default">
     <DeliverTo>Lisa Dollar</DeliverTo>
     <Street>100 Castro Street</Street>
     <City>Mountain View</City>
     <State isoStateCode="US-CA">CA</State>
     <PostalCode>95035</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     <Extrinsicname="POBox"></Extrinsic>
     <Extrinsicname="houseNumber"></Extrinsic>
     <Extrinsicname="building"></Extrinsic>
     </PostalAddress>
     <Email name="default">ldollar@workchairs.com</Email>
     <Phone name="work">
     <TelephoneNumber>
     <CountryCode isoCountryCode="US">1</CountryCode>
     <AreaOrCityCode>650</AreaOrCityCode>
     <Number>9990000</Number>
     </TelephoneNumber>
     </Phone>
     </Contact>
     <Contact role="from" addressID="0030105956">
     <Name xml:lang=”en”>Lisa Dollar</Name>
     <PostalAddressname="default">
     <DeliverTo>Lisa Dollar</DeliverTo>
     <Street>100 Castro Street</Street>
     <City>Mountain View</City>
     <State isoStateCode="US-CA">CA</State>
     <PostalCode>95035</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     </PostalAddress>
     <Email name="default">ldollar@workchairs.com</Email>
     <Phone name="work">
     <TelephoneNumber>
     <CountryCode isoCountryCode="US">1</CountryCode>
     <AreaOrCityCode>650</AreaOrCityCode>
     <Number>9990000</Number>
     </TelephoneNumber>
     </Phone>
     </Contact>
     <Comments>Is there any news about our order?</Comments>
    </OrderStatusRequestHeader>
    

    13.4.2 OrderStatusRequestItem

    OrderStatusRequestItem 要素は、特定の明細に関する情報を格納します。この要素には、次の属性があります。

    属性 説明
    rescheduleRequest 配達日に対して可能な変更を提案する資材所要量計画 (MRP) に基づく情報です。使用可能な値は次のとおりです。
    ● in – 配達日を現在の配達日よりも前に再スケジュールする MRP 提案。
    ● out – 配達日を現在の配達日よりも後に再スケジュールする MRP 提案。
    ● cancel – 注文書明細をキャンセルする MRP 提案。
    rescheduleDate MRP 提案で再スケジュールされた配達日。

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

    要素 説明
    ItemReference 明細に関連するすべての参照を定義します。「ItemReference」を参照してください。
    Comments この明細に関連付けられたすべての追加コメントが含まれます。
    Priority サプライヤのオーダーの優先度を上げるために使用される優先度区分です。注文書明細に関連付けられた現在のビルドの優先順位を示します。この値では、注文書の優先度は更新されません。

    以下は、OrderStatusRequestItem 要素の例を示したものです。

    <OrderStatusRequestItem rescheduleRequest="in" rescheduleDate="2017-09-12T18:39:09-08:00">
     <ItemReference lineNumber="1">
     <ItemID>
     <SupplierPartID>AX4518</SupplierPartID>
     </ItemID>
     </ItemReference>
     <Comments>Is there any news about our order?</Comments>
     <Priority level="2">
     <Description type="" xml:lang="EN">
     <ShortName>Black</ShortName>
     </Description>
     </Priority>
    </OrderStatusRequestItem>
    
    13.4.2.1 ItemReference

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

    要素 説明
    ItemID OrderStatusRequest における明細の品目 ID。
    IDReference OrderStatusRequest における明細の品番への一意の参照。
    Classification 明細の推奨される商品分類コード。
    Description 明細の説明。

    ItemReference 要素には、必須フィールドである lineNumber 属性が含まれます。この明細番号は、OrderRequest における明細番号に対応します。

    13.5 ShipNoticeRequest

    サプライヤは ShipNoticeRequest ドキュメントを使用して、オーダーに関する出荷情報を送信します。このトランザクションには、出荷情報が 1 つ記述され、出荷全体または個別の明細に関する危険有害性情報と、複数のオーダーの一部の情報を含めることができます。

    注記
    このトランザクションの DTD は、cXML.dtd ではなく、Fulfill.dtd に含まれます。

    ShipNoticeRequest には、以下の要素を含めることができます。

    ● ShipNoticeHeader
    ● ShipControl
    ● ShipNoticePortion

    ShipNoticeRequest ドキュメントは、税額および出荷費用の更新は提供しません。この情報は、ConfirmationRequest ドキュメントで伝送する必要があります。必要に応じて、出荷が配送された後で、この情報とともに operation=”update” の ConfirmationRequest を送信することができます。operation=”update” の ConfirmationRequest および ShipNoticeRequest ドキュメントには、元のOrderRequest ドキュメントからの関連するすべての情報を含める必要があります。

    次の例は、ShipNoticeRequest 要素を示しています。

    <ShipNoticeRequest>
     <ShipNoticeHeader shipmentID="S2-123" noticeDate="2000-10-14T18:39:09-08:00" shipmentDate="2000-10-14T08:30:19-08:00" deliveryDate="2000-10-18T09:00:00-08:00">
     <Contact role="shipFrom">
     <Name xml:lang="en-CA">Workchairs, Vancouver</Name>
     <PostalAddress>
     <Street>432 Lake Drive</Street>
     <City>Vancouver</City>
     <State isoStateCode="CA-BC">BC</State>
     <PostalCode>B3C 2G4</PostalCode>
     <Country isoCountryCode="CA">Canada</Country>
     </PostalAddress>
     <Phone>
     <TelephoneNumber>
     <CountryCode isoCountryCode="CA">1</CountryCode>
     <AreaOrCityCode>201</AreaOrCityCode>
     <Number>9211132</Number>
     </TelephoneNumber>
     </Phone>
     </Contact>
     <Comments xml:lang="en-CA">Got it all into one shipment.</Comments>
     <ReferenceDocumentInfo>
     <DocumentInfo documentDate="2016-01-10T17:55:20-05:00" documentID="QN171226_01" documentType="QualityNotificationDocument"/>
     </ReferenceDocumentInfo>
     </ShipNoticeHeader>
     <ShipControl>
     <CarrierIdentifier domain="SCAC">FDE</CarrierIdentifier>
     <CarrierIdentifier domain="companyName">Federal Express</CarrierIdentifier>
     <ShipmentIdentifier>8202 8261 1194</ShipmentIdentifier>
     </ShipControl>
     <ShipNoticePortion>
     <!-- The orderID and orderDate attributes are not required in the OrderReference element. -->
     <OrderReference orderID="DO1234">
     <DocumentReference payloadID="32232995@hub.acme.com" />
     </OrderReference>
     </ShipNoticePortion>
    </ShipNoticeRequest>
    

    ShipNoticeRequest 要素には、含まれるすべての明細に共通の出荷通知に関する情報が含まれます。この情報は、OrderRequest ドキュメントからコピーする必要はありません。Contact 要素は、主にオーダーについての新しい情報を追加するために使用します。ShipNoticeRequest 要素には、ShipNoticeHeader、ShipControl、および ShipNoticePortion の 3 つの要素を含めます。これらはすべて必須要素であり、ShipNoticePortion および ShipControl は両方とも複数回使用できます。担当運送業者が複数である出荷は、次のいずれかの方法で記述します。

    1. 運送業者またはサードパーティの物流業者にはトラッキング識別子を作成してもらい、輸送全体についての情報を検索できるようにします。サプライヤは、このような情報を 1 つの ShipControl 要素で送信します。
    2. 各セグメントには、個別のトラッキング番号が必要です。サプライヤは、このような情報をセグメントごとに 1 つのShipControl 要素で送信します。

    ShipControl 要素は、出荷が輸送される順序で使用する必要があります。この最初の要素に明示的な開始日を含めることはできません。また、ShipControl startDate 属性を使用することもできません。その運送業者による管理は、ShipNoticeHeader shipmentDate 属性値で指定された出荷の開始時間から開始する必要があります。その後のすべての ShipControl 要素には、ShipControl startDate 属性値で指定された開始日後の日付が含まれる必要があります。
    ShipNoticePortion 要素は、任意の順序で使用できます。ShipNoticePortion、OrderReference、またはDocumentReference payloadID 属性値の特定の順序は、ShipNoticeRequest 要素内で複数回使用することはできません。

    注記
    ShipNoticeRequest および ShipNoticeHeader 要素内の多数の要素および属性は、operation=”delete” である場合にのみ任意で設定できます。そのほかの操作では、1 つまたは複数のShipControl および ShipNoticePortion 要素は、ShipNoticeHeader 要素内で使用する必要があります。

    13.5.1 ShipNoticeHeader

    ShipNoticeHeader 要素には、含まれるすべての明細に共通する出荷通知に関する情報が含まれます。
    ShipNoticeHeader 要素には、次の要素を含めることができます。ServiceLevel、DocumentReference、Contact、Hazard, Comments, TermsofDelivery, IdReference,Comments, Extrinsic,RequestedDeliveryDate, および Dimension。これらはすべて任意設定です。

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

    属性 説明
    shipmentID
    (必須)
    サプライヤが指定するドキュメントの識別子です。この属性は、ドキュメントの payloadID に続いてユーザーに表示されます。この値は、特定の出荷通知が削除されても変更されることはありません。すなわち、同じ出荷を記述する “delete” ドキュメントは、元の “new” ShipNoticeRequest とshipmentID を共有します。
    operation この任意設定の属性は、ShipNoticeRequest ドキュメントが新規であるか、前回の出荷通知の更新であるかを指定します。使用可能な値は次のとおりです。
    ● new – 通常設定の値です。一度も出荷通知は送信されていません。
    ● update – 前回の出荷通知申請を更新します。サプライヤは出荷通知のエラーを訂正したり、その後で得た追加情報を追加したりできます。いずれの場合も “update” ドキュメントが完全である必要があります。元のすべてのデータは受領者によって破棄される必要があります。shipmentID は、前回の申請の shipmentID と一致している必要があります。
    ● delete – 出荷の状況から以前の新規または更新された ShipNoticeRequest に記述された変更を削除します。サプライヤが計画出荷を破棄するか、発生しないオーダーについて誤って ShipNoticeRequest を送信する場合にのみ使用します。shipmentID は、前回の申請の shipmentID と一致している必要があります。operation が “new” でない場合は、ShipNoticeRequest で ShipNoticeHeader要素内に DocumentReference 要素を明示的または通常設定として含める必要があります。この要素の詳細については、「DocumentReference」を参照してください。これによって、出荷通知の複数のバージョンが効率的に順序付けられます。
    noticeDate
    (必須)
    ShipNoticeRequest ドキュメントが作成された日時を指定します。
    shipmentDate 商品が配送される予定日時を指定します。この値は 1 つのオーダーのrequestedDeliveryDate の通常設定の値として指定できますが、OrderRequestドキュメントではこの属性は任意設定であり、ShipNoticeRequest は複数のOrderRequest ドキュメントを参照できます。operation が “delete” である場合を除き、すべての ShipNoticeRequest ドキュメントにこの属性を含める必要があります。
    deliveryDate 商品が配送される予定日時を指定します。この値は 1 つのオーダーのrequestedDeliveryDate の通常設定の値として指定できますが、OrderRequestドキュメントではこの属性は任意設定であり、ShipNoticeRequest は複数のOrderRequest ドキュメントを参照できます。operation が “delete” である場合を除き、すべての ShipNoticeRequest ドキュメントにこの属性を含める必要があります。
    shipmentType この属性を使用して、出荷通知の種類が実際の出荷通知であるのか予定出荷通知であるのかを指定します。実際の出荷通知を示す場合は “actual”、予定出荷通知を示す場合は”planned” を指定します。”actual” を指定する場合は、実際の出荷日を入力する必要があります。”planned” を指定する場合は、出荷予定日を入力する必要があります。以下に例を示します。

    <!--
     -->
    <ShipNoticeRequest>
     <ShipNoticeHeader shipmentType="planned" deliveryDate="2012-09-28T12:00:00+05:30" shipmentDate="2012-09-27T12:00:00+05:30" noticeDate="2012-09-27T21:30:29+05:30" operation="new" shipmentID="ID00099">
    <!-- 
    -->
    fulfillmentType この出荷通知が作成される完了の種類。利用可能な値は、すべての品目が出荷されない場合は “partial”、オーダー全体が出荷される場合は “complete” です。
    requestedDeliveryDate 目的の配達日を指定します。多くの場合、バイヤーが商品の受領を希望する日付 (または期間)が反映できます。以下に例を示します。

    <!--
     -->
    <ShipNoticeHeader shipmentType="planned" shipmentID="S89823-123" operation="new” noticeDate="2001-10-14" shipmentDate="2001-10-14T08:30:19-08:00 deliveryDate="2001-10-18T09:00:00-08:00" requestedDeliveryDate="2001-10-18T09:00:00-08:00" >
    <!-- 
    -->
    reason 出荷通知の理由。使用できる唯一の値は “return” です。これは、出荷に何らかの理由でバイヤーからサプライヤに返品される品目が含まれていることを意味します。たとえば、品目が損傷しているか不具合がある可能性があります。
    activityStepType ビジネスドキュメントの識別子。使用可能な値は以下のとおりです。
    ● stockTransfer – 在庫転送シナリオでバイヤーからサプライヤに送信される出荷通知メッセージを識別します。
    ● stockShippingAdvice – 在庫転送シナリオでサプライヤからコピーサプライヤに送信される出荷通知メッセージのコピーを識別します。
    13.5.1.1 ServiceLevel

    サービスレベルコードを言語固有の文字列で指定します。operation=”delete” が指定されている場合を除き、すべての ShipNoticeRequest ドキュメントで 1 つまたは複数の ServiceLevel 要素を使用する必要があります。各ServiceLevel には、この出荷の運送業者から提供されるサービスのレベルに対応した単一文字列 (“overnight”など) を含める必要があります。複数の ServiceLevel 要素を使用する場合は、すべての要素に対して異なる言語または地域情報で同じレベルのサービスを記述する必要があります。2 つの ServiceLevel 要素に同じ xml:lang 属性を含めることはできません。このような一覧内の要素に順序の制限はありません。
    必須の属性 xml:lang. が含まれます。詳細については、「xmlLangCode」を参照してください。

    13.5.1.2 DocumentReference

    含まれる DocumentReference 要素は、operation が “update” または “delete” の場合にのみ使用されます。その場合、DocumentReference 要素は、通常は共通の shipmentID で示されるこの特定の出荷通知の最新のShipNoticeRequest ドキュメントを参照します。たとえば、出荷通知を作成し、更新してから再度更新する場合、最終的なドキュメントに、operation=”update” の前の ShipNoticeRequest を参照する DocumentReference を含める必要があります。それにより、そのドキュメントは、元の operation=”new” ShipNoticeRequest ドキュメントを参照します。

    13.5.1.3 Contact

    Contact roles には、technicalSupport、customerService、sales、shipFrom (この出荷の出発点)、shipTo (OrderRequest ドキュメントからの ShipTo のコピー)、buyerCorporate (サプライヤが所有するバイヤー企業についての詳細)、および supplierCorporate を含めることができます。通常は、さまざまな OrderRequest ドキュメントから情報をコピーする必要はありません。Contact 要素は、主にオーダーに関する情報を追加するために使用してください。Contact 一覧内の要素は任意の順序で指定できます。Contact role 属性値は、ShipNoticeHeader 要素内で複数回使用することはできません。

    13.5.1.4 LegalEntity

    外部システム内の法人を識別します。IdReference 要素が含まれます。

    13.5.1.5 OrganizationalUnit

    外部システム内の発注ユニットまたは発注グループを識別します。IdReference 要素が含まれます。

    13.5.1.6 Hazard

    Hazard」を参照してください。

    13.5.1.7 Comments

    出荷に関する追加情報を含めるには、Comments 要素を使用します。ShipNoticeHeader 要素では、その情報は、含まれるすべての明細とルートに共通している必要があります。そうしたすべてのデータは、ユーザーが使用することを目的としています。
    最大で 3 つの Comments 要素を指定して、出荷通知に以下の追加情報を指定できます。

    ● 出荷の理由を指定します。
    ● 運送方向を指定します。
    ● 出荷の追加情報。

    IdReference」の例を参照してください。

    13.5.1.8 TermsOfTransport

    商品の輸送に関する出荷条件を指定します。
    次の例は、TermsOfTransport 要素を示しています。

    <TermsOfTransport>
     <SealID>1231</SealID>
     <SealingPartyCode>6645</SealingPartyCode>
     <EquipmentIdentificationCode>34535</EquipmentIdentificationCode>
     <TransportTerms value=”Other”>Contract Terms</TransportTerms>
     <Dimension quantity="0.4" type="grossWeight">
     <UnitOfMeasure>MTR</UnitOfMeasure>
     </Dimension>
     <Dimension quantity="0.4" type="grossVolume">
     <UnitOfMeasure>MTR</UnitOfMeasure>
     </Dimension>
    </TermsOfTransport>
    

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

    SealID

    シールの一意の ID を指定します。シールは、輸送または貨物出荷の整合性を維持するために使用されます。シールにはさまざまな形式ありますが、1 つの共通特性 (オーナーまたは責任者によって指定された一意の ID) を共有します。SealID は、輸送中のコンテナ、トラック、船舶、またはそのほかの貨物のプロパティを国外で追跡するために使用されます。

    SealingPartyCode

    SealID を割り当てたパーティの会社コードを指定します。このパーティは通常、商品のオーナーまたは貨物を積載した運送業者になります。

    EquipmentIdentificationCode

    装置識別符号を指定します。これは、主に国内輸送および保管目的で使用されます。梱包装置には、移動と保管場所を監視および管理するための一意の符号が付けられます。この符号は一時的または永続的にすることができます。

    TransportTerms

    TransportTerms の詳細については、「TermsOfDelivery」を参照してください。

    Dimension

    品目の梱包に対して単一の次元を指定します。「次元」を参照してください。

    Extrinsic

    TermsOfTransport 要素の Extrinsic。

    13.5.1.9 TermsofDelivery

    TermsofDelivery 要素を ShipNoticeHeader 要素に追加して、ヘッダーレベルで配達条件を指定することができます。詳細については、「TermsOfDelivery」を参照してください。

    13.5.1.10 Packaging

    詳細については、「Packaging」を参照してください。

    13.5.1.11 Extrinsic

    また、Extrinsic 要素の一覧を使用して、アプリケーションで使用する出荷に関する追加データを挿入します。これらの要素には、受信側のシステムのワークフローに影響する、事前定義されたキーワードや値を組み込むことができます。Extrinsic 一覧内の要素は任意の順序で指定できます。Extrinsic タイプ、Extrinsicname 属性値は、ShipNoticeHeader 要素内で複数回使用しないでください。この一覧と特定の ShipControl またはShipNoticePortion 要素の両方で、このタイプを指定しないでください。ShipNoticeHeader には、いずれかの下位レベルで上書きされた通常設定のエクストリンジック値を含めないでください。

    13.5.1.12 IdReference

    政府発行の出荷 ID、ドキュメント名、およびサプライヤ参照番号を指定します。

    例:

    <ShipNoticeHeader>
     <Contact role="shipTo">
     <Name xml:lang="en">Acme</Name>
     <PostalAddress>
     <Street>123 Anystreet</Street>
     <City>Birmingham</City>
     <State isoStateCode="US-AL">AL</State>
     <PostalCode>350052</PostalCode>
     <Country isoCountryCode="US">United States</Country>
     </PostalAddress>
     </Contact>
     <Comments type="ReasonForShipment" xml:lang="en-US">Low availability at warehouse</Comments>
     <Comments type="TransitDirection" xml:lang="en-US">East</Comments>
     <Comments xml:lang="en-US">Comments to the buyer</Comments>
     <TermsOfDelivery>
     <TermsOfDeliveryCode value="DeliveryCondition">
     </TermsOfDeliveryCode>
     <ShippingPaymentMethod value="Prepaid-BySeller">
     </ShippingPaymentMethod>
     <TransportTerms value="Other">Contract Terms</TransportTerms>
     <Comments type="TermsOfDelivery" xml:lang="en-US">Delivery at the doorstep</Comments>
     <Comments type="Transport" xml:lang="en-US">As per the contract
     </Comments>
     </TermsOfDelivery>
     <Extrinsic name="invoiceNumber">INV1561</Extrinsic>
     <IdReference identifier="US12345" domain="governmentNumber">
     </IdReference>
     <IdReference identifier="Partial Shipment" domain="documentName">
     </IdReference>
     <IdReference identifier="ASN001" domain="supplierReference">
     </IdReference>
    </ShipNoticeHeader>
    
    13.5.1.13 ReferenceDocumentInfo

    追加のドキュメント参照情報が含まれます。「ReferenceDocumentInfo」を参照してください。

    13.5.2 ShipControl

    出荷の一部を担当する運送業者を指定します。ShipControl 要素には、CarrierIdentifier、ShipmentIdentifier、TransportInformation, PackageIdentification、Route、Contact、Comments、および Extrinsic 要素が含まれます。
    出荷状況は、この要素レベルで提供される識別子を使用してトラッキングされます。これらの識別子は、1 つのShipControl 要素の startDate または出荷の shipmentDate から、次の startDate まで有効である必要があります。
    ShipControl には次の属性があります。

    属性 説明
    startDate この出荷経路による輸送が開始される日時を指定します。2 番目以降のすべての ShipControl 要素では必須です。この属性は、ShipNoticeHeader’s shipmentDate 属性と重複するため、最初の ShipControl 要素で使用することはできません。
    13.5.2.1 CarrierIdentifier

    この出荷で輸送を担当する運送業者を指定します。CarrierIdentifier リストには、同じ運送業者の複数の識別子を含めることができます。このリスト内の要素に順序の制限はありません。特定の識別ドメイン(CarrierIdentifier@domain 属性値) は、ShipControl 要素内で複数回使用することはできません。CarrierIdentifier リストのすべての要素で提供される ID は、同じ運送業者に対応している必要があります。domain という名前の 1 つの属性がありますが、これは、CarrierIdentifier 値が意味を持つドメインを指定します。たとえば、Standard Carrier Alpha Code の場合は “SCAC”、または法的に有効な会社名を指定します。
    認識されるドメインは以下のとおりです。

    説明
    会社名 この会社の法的に有効な名称。場合によって、これは role が “carrierCorporate” の Contact要素で提供することもできます。Contact 要素の使用は、運送業者に関する追加詳細を伝えなければならない場合のために予約しておく必要があります。
    SCAC Standard Carrier Alpha Code。www.nmfta.org/pages/scac
    IATA International Air Transport Association。www.iata.org
    AAR Association of American Railroads。www.aar.org
    UIC International Union of Railways。www.uic.org
    EAN European Article Numbering。upc-ean-information.com
    DUNS Dun and Bradstreet’s Data Universal Numbering System。www.dnb.com
    13.5.2.2 ShipmentIdentifier

    出荷にかかわる運送業者によって定義されるトラッキング番号で、出荷に関するより詳細な情報を取得することができます。これは、Route 要素内の CarrierIdentifier 値で記述されるドメインで意味を持ちます。出荷識別子は、各運送業者で異なる名前を付けています。これは通常、運送目録番号、累進番号、および船荷証券とも呼ばれます。それらはすべてトラッキング番号を表します。
    ShipmentIdentifier には次の属性があります。

    属性 説明
    domain どのような種類の識別子であるかをより厳密に指定します。trackingNumber およびbillOfLading のような値を使用できます。
    trackingNumberDate 運送業者がこの出荷のトラッキング番号を作成する日付です。運送業者を指定してある場合は必須です。
    trackingURL 運送会社の URL です。これは、トラッキング番号と関連して出荷を追跡するために使用できます。

    次の例は、運送業者の trackingNumberDate を指定する ShipmentIdentifier を示します。

    <ShipControl>
     <CarrierIdentifier domain="companyName">BlueDart</CarrierIdentifier>
     <ShipmentIdentifier trackingNumberDate="2012-09-27 12:00:00 Asia/Calcutta">99345</ShipmentIdentifier>
    </ShipControl>
    

    次の例は、トラッキング番号と関連して出荷を追加するために使用される trackingURL を指定する ShipmentIdentifier を示します。

    <ShipControl>
     <CarrierIdentifier domain="companyName">DHL</CarrierIdentifier>
     <ShipmentIdentifier trackingURL="http://www.dhl.com/cgi-bin/tracking.pl?AWB=1234&TID=CP_ENG&FIRST_DB=US">62396</ShipmentIdentifier>
    </ShipControl>
    
    13.5.2.3 PackageIdentification

    出荷物を梱包したコンテナ、スキッド、ボックス、またはパッケージに表示される識別子を指定します。最小値と最大値が記述されます。
    PackageIdentification には次の属性があります。

    属性 説明
    rangeBegin
    (必須)
    この出荷の個別の要素での最も小さい番号を指定します。
    rangeEnd
    (必須)
    この出荷の個別の要素での最も大きい番号を指定します。rangeBegin と同じか、それ以上にする必要があります。
    13.5.2.4 Route

    Route 要素がある場合は、出荷が輸送される順序になっている必要があります。このセグメントで出荷の輸送方法を指定します。2 つの ShipmentIdentifier 値がある場合は、2 番目の値はその出荷で使用される一連の番号の終わりを定義します。Route には Contact 要素を含めることができます。唯一の Contact ロールは “carrierCorporate” です。これには、運送者、”shipFrom”、および “shipTo” についてサプライヤが所有する詳細な連絡先情報が含まれています。

    サードパーティ物流業者によって制御されるセグメント内の各運送業者は、そのサードパーティ物流業者に外部からトラッキング情報を提供します。ShipNoticeRequest には、ShipControl レベルのトラッキング情報のみが含まれます。Route 要素には、1 つの輸送モードのみを記述できます。すべてのモードを記述する場合は、個別の Route 要素にマルチモーダルルートの各モードを記述する必要があります。バイヤーの ShipTo 所在地までの輸送経路をすべて記述する必要はありません。”carrierCorporate” ロールは、サードパーティが複数の運送業者にトラッキング情報を提供している場合にのみ、この要素レベルに関係します。role が”shipFrom” の Contact 要素は、2 番目以降にすべての Route 要素で使用される必要があります。Route 要素では、特定の運送業者の管理下にある輸送全体を記述する必要はありません。これらの要素では、異なる時刻と地域で開始および終了する散発的なイベントの流れを記述できます。Contact 一覧にある要素は任意の順序で指定できます。Contact role 属性値は、Route 要素内で複数回使用することはできません。

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

    属性 説明
    method
    (必須)
    輸送タイプコードを示す修飾子。使用可能な値は、次のとおりです。
    ● ship – 船舶による輸送 (海上)。
    ● rail – 鉄道による輸送。
    ● motor – 自動車による輸送 (一般的な運送業者)。
    ● air – 航空便による輸送。
    ● mail – 郵便は純粋な輸送モードではありませんが、実用的な理由で提供されています。多くの国で、郵便によって輸出入される商品の金額はかなりのものですが、関係する輸出者または輸入者は、郵便物がどの方法で国境を越えたのかを示すことができないと考えられます。
    ● multimodal – マルチモーダル輸送は純粋な輸送モードではありませんが、実用的な理由で提供されています。これは、1 つの輸送契約に基づいて、商品が輸送オペレータによって管理される場所から、指定の配達場所まで 2 つ以上の異なるモードで輸送される場合に使用できます。(単一モードの輸送の遂行において実行される、商品の集荷および配達の業務は、契約で定義されているように、マルチモーダル輸送とは見なしません)。
    ● fixedTransport – 連続輸送のための施設 (パイプライン、ロープウェイ、電力線など) に適用されます。
    ● inlandWater – 水上輸送の適用が海上輸送とは別に報告される場合にのみ使用されます。
    ● unknown – モードが不明である場合、または関連ドキュメントの発行時にモードに関する情報が利用できない場合に使用できます。
    means 商品の輸送に使用される特定の船舶、車両、またはその他の装置。means の値は method の値によって異なります。

    method の値が “ship” である場合、means の使用可能な値は次のとおりです。
    ● cargoVessel – 一般貨物を輸送するために設計された船舶。
    ● unitCarrier – ユニットロードを輸送するために設計された船舶。
    ● bulkCarrier – バルクカーゴを輸送するために設計された船舶。
    ● tanker – 貨物を輸送するためにタンクのみを搭載した船舶。
    ● liquefiedGasTanker – 液化ガスを輸送するために設計されたタンカー。
    ● otherSpecialTanker – その他の特殊液体を輸送するために設計されたタンカー。
    ● cargoAndPassengerVessel – 貨物および乗客を輸送するために設計された船舶。
    ● otherVessel – 航洋船 (他で指定されていない場合)。
    ● fishingBoat – 漁業のために設計された船舶。
    ● floatingStructure – 任意の浮体構造物。

    method の値が “rail” である場合、means の使用可能な値は次のとおりです。
    ● train – 1 つ以上の機関車ユニットによって牽引または後押しされるか、自走して線路上を移動する 1 つ以上の鉄道車両。
    ● freightTrain – 貨物を輸送するための列車。

    method の値が “motor” である場合、means の使用可能な値は次のとおりです。
    ● truck – 荷物を運ぶために設計された自動車。
    ● tractor – 牽引用に設計されたエンジンを搭載した自動車。
    ● van – 貨物を輸送するために設計された密閉型の自動車。
    ● carCarrier – 自動車を輸送するために設計された自動車。
    ● shovelLoader – 砂やその他のバルク材料をシャベルで掘るために設計された自動車。
    ● straddleCarrier – コンテナを積んで輸送するために設計された自動車。
    ● mobileCrane – 荷役クレーンを搭載した自動車。
    ● bus – 運転手を含めて 9 人以上の乗客を輸送するために設計された自動車。
    ● car – 少人数の乗客を輸送するために設計された自動車。
    ● taxi – 人の輸送を商売として許可された自動車。

    method の値が “air” である場合、means の値は IATA (International Air Transport Association) 発行の Standard Schedules Information Manual (SSIM) の項 “ATA/IATA Aircraft Types” で指定されています。この参照コードは、商業定期便またはチャーター便 (のみ) として飛行しているか、間もなく飛行予定である航空機と、製造メーカーによって発表され航空機オーダーが手配されている航空機のすべてが対象となっています。

    method の値が “multimodal” である場合、複数のセグメントが存在し、セグメントごとにモードと手段が異なる可能性があることを意味します。したがって、means に対して使用可能な値は “unknown”のみです。

    method の値が “fixedTransport” である場合、means の使用可能な値は次のとおりです。
    ● unknown – 不明な種類の固定輸送施設。
    ● pipeline – 液体商品またはガス商品を連続輸送するための、1 本以上のパイプからなるパイプライン。
    ● powerline – 電気を連続輸送するための、1 本以上のケーブルまたは電線からなる電力線。

    method の値が “inlandWater” である場合、means の使用可能な値は次のとおりです。
    ● unknownVessel – 不明な種類の船舶。
    ● motorFreighter – 一般貨物を輸送するために設計された動力船。
    ● motorTanker – 液体貨物を輸送するために設計された動力船。
    ● containerVessel – コンテナを輸送するために設計された船舶。
    ● gasTanker – ガスを輸送するために設計されたタンクを搭載した船舶。
    ● tug – ほかの船舶を押したり引いたりするために設計された船舶。
    ● barge – 一般貨物を輸送するために設計されたはしけ。
    ● pushTow – 1 つ以上のはしけの移動を支援する押航/曳航のために設計された船舶。
    ● fishingBoat – 漁業のために設計された船舶。
    ● bunkerShip – 燃料の輸送および積み込みのための船舶。

    method の値が “mail” または “unknown” のいずれかである場合、means の固有の値は定義されていません。

    startDate この出荷経路による輸送が開始される日時を指定します。2 番目以降のすべての Route 要素では必須です。
    endDate この出荷経路による輸送が終了する日時を指定します。startDate の後に指定する必要があります。Route 要素が後に続く場合、その後続の要素の startDate をこの値より前の日付に設定しないでください。
    13.5.2.5 TransportInformation

    ShipTo/BillTo 」を参照してください。

    13.5.2.6 Contact

    この要素で最も一般的な Contact role を次に示します。

    説明
    carrierCorporate 運送業者の組織に関して、サプライヤが把握している連絡先情報の詳細を記述します。
    shipFrom role が “shipFrom” の Contact 要素は、2 番目以降のすべての ShipControl 要素で使用される必要があります。この role は、全体の ShipNoticeHeader 要素の role と重複する可能性があるため、最初の ShipControl 要素で使用することはできません。

    この要素では role=”shipTo” を使用しないでください。後続の ShipControl 要素または ShipNoticeHeader のrole で情報が重複する可能性があるからです。管理は、特定の地域で予定された時刻に 1 つの運送業者から別の運送業者へ移ります。

    Contact 内では任意の順序で要素を一覧できます。Contact role 属性値は、ShipControl 要素内で複数回使用することはできません。

    13.5.2.7 コメント

    Comments 要素には、この運送業者の管理下にある出荷に関する追加情報を含めることができます。ShipControl 要素のコンテキストでは、その情報をすべての関連するルートに共通のものにするか、どの Route に影響が及ぶかを明確にする必要があります。そうしたすべてのデータは、ユーザーが使用することを目的としています。

    13.5.2.8 Extrinsic

    また、Extrinsic 要素の一覧を使用して、アプリケーションで使用するこの運送業者またはその担当期間に関する追加データを挿入できます。これらの要素には、受信側のシステムのワークフローに影響する、事前定義されたキーワードや値を組み込むことができます。Extrinsic 一覧内の要素は任意の順序で指定できます。Extrinsic name 属性値は、ShipControl 要素内で複数回使用しないでください。この一覧と全体の ShipNoticeHeader 要素の両方で、同じタイプを指定しないでください。ShipNoticeHeader には、この下位レベルで上書きされた通常設定のエクストリンジック値を含めないでください。

    13.5.3 ShipNoticePortion

    注文書と明細の情報が含まれます。出荷の内容を指定します。

    13.5.3.1 OrderReference

    OrderReference 要素で指定された特定の OrderRequest は、最大 1 つの ShipNoticePortion 要素で指定されている必要があります。1 つのオーダーを分割配送できますが、出荷通知は各オーダーにつき 1 回のみ指定できます。
    ShipNoticePortion 要素に ShipNoticeItem 要素が 1 つも含まれていない場合は、参照されたオーダー全体が出荷に含まれています。この簡単なオプションによって、危険性情報および梱包情報が除外されます。
    OrderReference には次の属性があります。

    属性 説明
    orderID 出荷通知のためにバイヤーシステムの orderID (注文書番号) を指定します。この属性を使用する場合は、参照される OrderRequest ドキュメントの OrderRequestHeader 要素から値を直接コピーする必要があります。
    orderDate OrderRequest が作成された日時を指定します。日付形式は、国際 ISO 標準 8601 に従って yyyymm-dd です。
    13.5.3.2 MasterAgreementReference

    任意設定のフィールド。リリースの派生元である主契約への参照を含めることができます。

    13.5.3.3 MasterAgreementIDInfo

    任意設定のフィールド。リリースの派生元である主契約の ID を含めることができます。

    13.5.3.4 Contact

    このレベルで提供されるすべての Contact 要素には、オーダーのこの部分に固有の連絡先が記述されます。ShipNoticeHeader のレベルで記述した role の内容は、この要素のレベルでも適切であるため、このレベルではshipFrom、shipTo、buyerCorporate,、および supplierCorporate 情報を変更しないでください。特定のContact role は、ShipNoticePortion 要素とShipNoticeHeader 要素の両方で使用することはできません。このため、“technicalSupport”、“customerService”、および “sales” などのロールは、ShipNoticePortion内での使用が最も適しています。Contact 一覧内の要素は任意の順序で指定できます。Contact role 属性値は、ShipNoticePortion 要素内で複数回使用することはできません。

    13.5.3.5 コメント

    Comments 要素には、この出荷のオーダーに関する追加情報を含めることができます。このコンテキスト(ShipNoticePortion 要素) では、その情報をすべての含まれる品目に共通にするか、どの ShipNoticeItem が影響されるかを明確にする必要があります。そうしたすべてのデータは、ユーザーが使用することを目的としています。

    13.5.3.6 Extrinsic

    また、Extrinsic 要素の一覧を使用して、アプリケーションで使用するこのオーダーに関する追加データを挿入できます。これらの要素には、受信側のシステムのワークフローに影響する、事前定義されたキーワードや値を組み込むことができます。Extrinsic 一覧内の要素は任意の順序で指定できます。Extrinsic name 属性値は、ShipNoticePortion 要素内で複数回使用しないでください。この一覧と全体の ShipNoticeHeader 要素の両方で同じタイプを指定ないでください。ShipNoticeHeader には、この下位レベルで上書きされた通常設定のエクストリンジック値を含めないでください。

    13.5.3.7 ShipNoticeItem

    出荷の一部であり、特定の明細の部分です。オーダーからの各明細は、最大 1 つの ShipNoticeItem 要素で指定する必要があります。ShipNoticeItem には以下の要素が含まれます。ShipNoticeItem には以下の属性があります。

    属性 説明
    quantity
    (必須)
    出荷された品目の数を指定します。UnitOfMeasure 要素で指定された単位で表されます。
    lineNumber (必須) 1 から始まるオーダーの明細番号です。OrderReference 要素で参照されるドキュメント内の対応する明細 ItemOut と一致します。
    parentLineNumber 対応する親明細の明細番号。この属性は、itemType=”item” が設定された明細にのみ適用できます。
    shipNoticeLineNumber この明細に関連する出荷通知明細番号。1 つの注文書の明細に複数の出荷通知明細が存在する場合に使用します。
    itemType 品目の種類を指定します。使用可能な値は次のとおりです。
    ● composite – 品目グループを識別します。
    ● item – 独立した明細を識別します。
    ● lean – 明細で予定されている子品目がないことを示します。
    compositeItemType 親品目でグループごとの価格設定が使用されるかどうかを指定します。使用可能な値は”groupLevel” または “itemLevel” です。
    stockTransferType 在庫転送オーダーの種類を指定します。使用可能な値は次のとおりです。
    ● intra – 出荷通知明細が社内在庫転送オーダーに対して作成されたことを特定します。
    ● inter – 出荷通知明細が会社間在庫転送オーダーに対して作成されたことを特定します。
    outboundType stockTransport に設定して、在庫転送オーダーに対して配達が作成される必要があることを示します。

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

    要素 説明
    ItemID 品目の一意の ID が指定されます。「ItemID」を参照してください。
    ShipNoticeItemDetail 品目に関する詳細情報が含まれます。「ShipNoticeItemDetail」を参照してください。
    UnitOfMeasure 製品を梱包または出荷する方法が記述されます。「UnitOfMeasure」を参照してください。
    Packaging 各品目は、複数のボックスに梱包することができます。したがって、品目レベルのPackaging 要素は、その品目に属する複数のパッケージに対応する可能性があります。「Packaging」を参照してください。
    Hazard 品目および出荷全体に固有の、危険性についての説明と任意設定のコードを提供します。「Hazard」を参照してください。
    Batch | SupplierBatchID 商品のバッチを識別します。「SupplierBatchID または Batch」を参照してください。
    AssetInfo 商品の出荷における個別の品目に対して資産管理番号またはシリアル番号を提供します。「AssetInfo」を参照してください。
    TermsOfDelivery 品目レベルで配達条件を指定します。「TermsOfDelivery」を参照してください。
    OrderedQuantity 注文書の特定の明細に対して品目/製品の数を指定します。「OrderedQuantity」を参照してください。
    ShipNoticeItemIndustry 業界固有フィールドのグループが含まれます。「ShipNoticeItemIndustry」を参照してください。
    ComponentConsumptionDetails 最終製品の製造における構成品目の消費に関する詳細情報が含まれます。「ComponentConsumptionDetails」を参照してください。
    ReferenceDocumentInfo 追加のドキュメント参照情報が含まれます。「ReferenceDocumentInfo」を参照してください。
    Comments 出荷通知明細固有のコメントが含まれます。OrderRequest で要求された品質証明書を添付するために使用できます。この場合、コメントは添付ファイルによって提供され、証明書の種類は Comments@type 属性によって提供されます。
    Extrinsic この出荷通知明細の追加情報が含まれます。

    次の例は、ShipNoticeItem 要素を示しています。

    <ShipNoticeItem lineNumber="1" quantity="300" shipNoticeLineNumber="1">
     <ItemID>
     <SupplierPartID>AX4518</SupplierPartID>
     </ItemID>
     <ShipNoticeItemDetail>
     <UnitPrice>
     <Money currency="USD">31.20</Money>
     </UnitPrice>
     <Description xml:lang="en-US">BULLNOSE SHELVES 4 PK</Description>
     <UnitOfMeasure>PK</UnitOfMeasure>
     </ShipNoticeItemDetail>
     <UnitOfMeasure>PK</UnitOfMeasure>
     <Batch expirationDate="2015-11-18T09:00:00-08:00" productionDate="2015-11-10T09:00:00-08:00" batchQuantity="100">
     <SupplierBatchID>BAT-C-1</SupplierBatchID>
     </Batch>
     <Batch expirationDate="2015-11-18T09:00:00-08:00" productionDate="2015-11-10T09:00:00-08:00" batchQuantity="100">
     <SupplierBatchID>BAT-C-2</SupplierBatchID>
     </Batch>
     <Batch expirationDate="2015-11-18T09:00:00-08:00" productionDate="2015-11-10T09:00:00-08:00" batchQuantity="100">
     <SupplierBatchID>BAT-C-3</SupplierBatchID>
     </Batch>
     <ReferenceDocumentInfo>
     <DocumentInfo documentDate="2016-01-10T17:55:20-05:00" documentID="QN171226_01" documentType="QualityNotificationDocument"/>
     </ReferenceDocumentInfo>
     <!-- Quality certificate CERT123 attachment -->
     <Comments type="CERT123">
     <Attachment>
     <URL>cid: part1.DO63.982348912738@speedy.corp.alfa.com</URL>
     </Attachment>
     </Comments>
    </ShipNoticeItem>
    

    これは、配達を使用する「社内」在庫転送の別の ShipNoticeItem です。

    <ShipNoticeItem shipNoticeLineNumber="1" lineNumber="10" quantity="900" stockTransferType="intra" outboundType="stockTransport">
     <ItemID>
     <SupplierPartID>900000000446</SupplierPartID>
     <BuyerPartID>II-14417</BuyerPartID>
     </ItemID>
     <ShipNoticeItemDetail>
     <UnitPrice>
     <Money currency = "EUR">3.78</Money>
     </UnitPrice>
     <Description xml:lang = "en-US">Mocha Cola 1L</Description>
     <UnitOfMeasure>PCE</UnitOfMeasure>
     <ItemDetailIndustry>
     <ItemDetailRetail>
     <EANID>900000000447</EANID>
     </ItemDetailRetail>
     </ItemDetailIndustry>
     </ShipNoticeItemDetail>
     <UnitOfMeasure>PCE</UnitOfMeasure>
    </ShipNoticeItem>
    
    13.5.3.7.1 ShipNoticeItemDetail

    この要素には、品目に関する詳細情報が含まれます。出荷通知における品目の詳細は、参照される注文書から継承されます。注文書を参照しない出荷通知の場合、この要素から品目の詳細を取得できます。

    ShipNoticeItemDetail の例:

    <ShipNoticeItemDetail>
     <Description type=”CU” xml:lang="en">Computer Video Cables
     </Description>
     <UnitOfMeasure>EA</UnitOfMeasure>
    <Classification domain="UNSPSC">43173610</Classification>
     <ManufacturerPartID>JJ11P29</ManufacturerPartID>
     <Dimension quantity="0.4" type="grossWeight">
     <UnitOfMeasure>MTR</UnitOfMeasure>
     </Dimension>
     <Dimension quantity="0.4" type="grossVolume">
     <UnitOfMeasure>MTR</UnitOfMeasure>
     </Dimension>
     <Extrinsic name="PR No.">PR1026</Extrinsic>
    </ShipNoticeItemDetail>
    
    UnitPrice

    品目の単位あたりの価格。割引による変更など、任意の変更が提供されます。

    Description

    品目の簡単な説明。

    UnitOfMeasure

    製品を梱包または出荷する方法が記述されます。数量単位の共通コードである UN/CEFACT 単位に準拠している必要があります。参照資料 www.unece.org/cefact/codesfortrade/codes_index.html を参照してください。

    PriceBasisQuantity

    UnitPrice の基準となる数量を定義します。「PriceBasisQuantity」を参照してください。

    Classification

    類似するカテゴリのグループです。

    ManufacturerPartID

    品目の製造メーカーが品目を識別する ID です。

    ManufacturerName

    品目の製造メーカー名です。

    Dimension

    品目の次元です。「Dimension」を参照してください。

    ItemDetailIndustry

    業種別品目の詳細情報です。「ItemDetailIndustry」を参照してください。

    Extrinsic

    このオブジェクトに関連するすべての追加情報が含まれます。

    13.5.3.7.2 Hazard

    Hazard 要素は、品目と出荷全体の両方に固有の危険性に関するテキスト説明と任意設定のコードを提供します。出荷全体の危険性とは、すべての品目で同一の危険性、またはさまざまな製品をまとめて出荷する際に伴う危険性のいずれかになります。この要素には、詳細な取り扱い必要条件を含めることもできます。
    Hazard 一覧内の要素は任意の順序で一覧表示することができます。ConfirmationItem またはShipNoticeHeader では、同じ Hazard を複数回一覧に含めないでください。このレベル (ConfirmDtionItem 要素内)で一覧に含めた各 Hazard は、この特定の品目に適用する必要があります。1 つの品目の状況を更新するConfirmationRequest には、ConfirmationItem 要素の Hazard 要素を含めないでください。このレベル(ShipNoticeHeader 要素内) で一覧に含めた各 Hazard は、出荷全体またはこの出荷に含まれるすべての品目に適用する必要があります。1 つの品目の ShipNoticeRequest では、ShipNoticeItem 要素に Hazard 要素を含めないでください。
    Description と Classification の 2 つの要素があります。Classification は任意設定です。複数回使用することができます。
    Description 要素の一覧の場合は、詳細な取り扱い必要条件を含める必要があります。この一覧内の要素は任意の順序で指定できます。xml:lang 属性によって指定される地域情報の記述は複数回使用しないでください。
    Description 要素が複数ある場合は、各要素に同じ説明の翻訳を含める必要があります。
    Classification 要素は、任意の順序で使用できます。Classification domain 属性は、Hazard 要素内で複数回使用することはできません。

    一覧に含まれるすべての Classification 要素と Description (提供されている場合) は、1 つの危険性に関連している必要があります。危険性を追加する場合は、個別に Hazard 要素を使用する必要があります。
    このコンテキストでは、次の Classification domain 値が予測されます。

    説明
    UNDG United Nations Dangerous Goods
    IMDG International Marine Organization Dangerous Goods
    NAHG North American Hazardous Goods
    13.5.3.7.3 SupplierBatchID または Batch

    任意設定の SupplierBatchID または Batch 要素を指定して、商品のバッチを識別できます。
    SupplierBatchID は、同時に作成または製造された商品のバッチ番号 (“ロット番号” または “バリアント” とも呼ばれます) を指定します。たとえば、サプライヤはバッチ番号をコンピュータのハードドライブに割り当てることができます。
    Batch は、1 回の生産実行で生産される品目または商品のバッチ情報を指定します。「Batch」を参照してください。

    13.5.3.7.4 AssetInfo

    AssetInfo 要素は、商品の出荷における個別の品目に対して資産管理番号またはシリアル番号を提供します。バイヤーは、出荷を受領する前にこの情報を入手することができます。この要素には、以下の属性を含めることができます。

    属性 説明
    isReferencedAsset 資産情報がドキュメントの品目に関連付けられている参照された資産の情報であるかどうかを示します。
    tagNumber 品目に対するバイヤー固有の資産管理番号識別子を指定します。サプライヤがバイヤーに代わって資産管理番号を割り当てるには、サプライヤが使用する資産管理番号と割当方法についてバイヤーとサプライヤが前もって同意しておく必要があります。
    serialNumber 品目のシリアル番号を指定します。
    location 品目の所在地を指定します。
    equipmentId ユニットの装置 ID です。

    AssetInfo のすべての属性が任意設定ではありますが、この要素は、少なくとも 1 つの属性が指定されない限り、使用することはできません。複数の属性が指定された場合は、そのすべての属性が同じ品目のプロパティを参照する必要があります。

    13.5.3.7.5 ShipNoticeItemIndustry

    この要素は、業種別フィールドのグループです。

    ShipNoticeItemRetail

    小売業固有のフィールド詳細で、出荷通知用にグループ化できます。
    ShipNoticeItemRetail には以下の子要素が含まれます。

    要素 説明
    BestBeforeDate 品目/商品の品質が落ち始める日付を指定します。これを使用すると、食料品、薬品、化学薬品などに関連するすべての商品の賞味期限を示すことができます。この要素には、必須のdate 属性が含まれます。
    ExpiryDate 商品が販売不可能/使用不可能になる日付を指定します。この要素には、必須の date 属性が含まれます。
    FreeGoodsQuantity バイヤーへのコストなしで配達される数量を指定します。「FreeGoodsQuantity」を参照してください。
    PromotionDealID 販売促進活動に関連するサプライヤによって割り当てられる ID が指定されます。販売促進は将来の計画やオーダープロセス (および関連価格) に影響します。
    PromotionVariantID 商品の 1 つまたはいくつかのバリアントのみが推奨される場合に、特定の ID が指定されます。製品バリアントは、製品の特性 (色や形状など) を指定する特定のコードです。
    13.5.3.8 ReferenceDocumentInfo

    追加のドキュメント参照情報が含まれます。「ReferenceDocumentInfo」を参照してください。

    13.6 ReceiptRequest

    ReceiptRequest は、バイヤー企業からサプライヤに送信された注文書または主契約に対する受領書の詳細を表します。1 つまたは複数の注文書の全明細または選択された明細の任意の部分を対象にこれを使用できます。

    注記
    このトランザクションの DTD は、cXML.dtd ではなく、Fulfill.dtd に含まれます。

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

    要素 説明
    ReceiptRequestHeader
    (必須)
    この受領書のヘッダー情報が含まれます。「ReceiptRequestHeader」を参照してください。
    ReceiptOrder
    (必須)
    注文書または主契約に関連する情報を定義します。「ReceiptOrder」を参照してください。
    Total
    (必須)
    すべての受領書明細金額の合計金額です。

    ReceiptRequest の例を次に示します。

    <Request deploymentMode="production">
     <ReceiptRequest>
     <ReceiptRequestHeader operation="new" receiptDate="2017-01-19T12:59:49-05:00" receiptID="ComRec123">
     <Comments xml:lang="en"/>
     </ReceiptRequestHeader>
     <ReceiptOrder>
     <ReceiptOrderInfo>
     <OrderReference orderID="4500003069">
     <DocumentReference payloadID="CSN.20170120.01"/>
     </OrderReference>
     </ReceiptOrderInfo>
     <ReceiptItem quantity="10" receiptLineNumber="1" type="received">
     <ReceiptItemReference lineNumber="1">
     <ItemID>
     <SupplierPartID>BX886376-002</SupplierPartID>
     <BuyerPartID>X886376-002</BuyerPartID>
     </ItemID>
     <Description xml:lang="en">PROCSR-CPU-GPU,OTH,0003.10 GHZ,LGA1150,I</Description>
     <ShipNoticeReference shipNoticeID="SMSNG1001">
     <DocumentReference payloadID="CCSN.0904.PO.52"/>
     </ShipNoticeReference>
     <ShipNoticeLineItemReference shipNoticeLineNumber="2"/>
     </ReceiptItemReference>
     <UnitRate>
     <Money currency=""/>
     <UnitOfMeasure>EA</UnitOfMeasure>
     </UnitRate>
     <ReceivedAmount>
     <Money currency=""/>
     </ReceivedAmount>
     <Batch>
     <BuyerBatchID>4B93933</BuyerBatchID>
     <SupplierBatchID>SCM100</SupplierBatchID>
     </Batch>
     </ReceiptItem>
     </ReceiptOrder>
     <Total>
     <Money currency=""/>
     </Total>
     </ReceiptRequest>
    </Request>
    

    13.6.1 ReceiptRequestHeader

    ReceiptRequestHeader には、この受領書のヘッダー情報が含まれます。この要素には、次の属性があります。

    属性 説明
    receiptID
    (必須)
    バイヤーがこの受領書に対して生成した一意の識別子。
    receiptDate
    (必須)
    バイヤー企業が品目またはサービスを受け入れた日時。この日時はドキュメントのタイムスタンプよりも前である必要があります。
    operation この receipt ドキュメントで記述される処理。使用可能な値は、”new” (通常設定) と、DocumentReference 要素で指定された既存の受領書をキャンセルする”delete” です。”delete” 操作は、構成品目受領書でのみサポートされます。
    activityStepType ビジネスプロセスの識別子。使用できる唯一の値は、在庫転送オーダーシナリオを表す
    stockTransfer です。

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

    要素 説明
    DocumentReference 以前の ReceiptRequest への参照。属性ReceiptRequestHeader@operation が “delete” である場合は、DocumentReference 要素が必要となり、この要素は同じ受領書プロセスで元のReceiptRequest ドキュメントを参照する必要があります。
    ShipNoticeIDInfo バイヤーの入庫の受領書が含まれます。通常の設定は、サプライヤの出荷通知 ID になります。
    Comments このオブジェクトに関連するコメントが含まれます。
    Extrinsic このオブジェクトに関連するすべての追加情報が含まれます。

    以下の例は、ShipNoticeIDInfo を含む ReceiptRequestHeader を示します。

    <Request deploymentMode="production">
     <ReceiptRequest>
     <ReceiptRequestHeader operation="new" receiptDate="2015-04-16T12:00:00+02:00" receiptID="DNS124">
     <ShipNoticeIDInfo shipNoticeDate="2016-04-12T00:00-05:00" shipNoticeID="asn-1234">
     </ShipNoticeIDInfo>
     </ReceiptRequestHeader>
     ...
     </ReceiptRequest>
    </Request>
    

    以下の例は、構成品目受領書をキャンセルする方法を示します。

    <ReceiptRequest>
     <ReceiptRequestHeader operation="delete" receiptDate="2016-04-19T16:48:17-05:00" receiptID="RECEIPT002">
     <DocumentReference payloadID="RECEIPT001"/>
     ...
     </ReceiptRequestHeader>
     ...
    </ReceiptRequest>
    

    13.6.2 ReceiptOrder

    ReceiptOrder は、注文書または主契約に関連する情報を定義します。ReceiptRequest ドキュメントには、複数のReceiptOrder 要素が含まれることがあります。ReceiptOrder には次の属性があります。

    属性 説明
    closeForReceiving yes に設定して、この受領書の承認時に、基となるオーダーまたは主契約を終了し、今後の受け入れを不可とするかを指定します。

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

    要素 説明
    ReceiptOrderInfo
    (必須)
    注文書または主契約の参照情報が含まれます。「ReceiptOrderInfo」を参照してください。
    ReceiptItem
    (必須)
    注文書または主契約からの情報を使用して、受領書明細を定義します。「ReceiptItem」を参照してください。
    13.6.2.1 ReceiptOrderInfo

    ReceiptOrderInfo には、注文書または主契約の参照情報が含まれます。内容の任意設定は、優先順にOrderReference、MasterAgreementReference、MasterAgreementIDInfo、または OrderIDInfo です。

    要素 説明
    OrderReference 受領した品目またはサービスを含む注文書への参照です。
    MasterAgreementReference 受領した品目またはサービスを含む主契約への参照です。
    OrderIDInfo 対応する注文書のバイヤー ID です。
    MasterAgreementIDInfo 対応する主契約のバイヤー ID です。
    13.6.2.2 ReceiptItem

    ReceiptItem は、注文書または主契約からの情報を使用して、受領書明細を定義します。受領書明細情報を提供する場合は、以下のガイドラインに従います。

    ● リリースオーダーに対する受領書の場合には、リリースオーダーと主契約の両方を指定します。
    ● リリースなしの主契約に対する受領書の場合には、契約のみを指定します。
    ● 注文書に対する受領書の場合には、注文書を指定します。

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

    属性 説明
    receiptLineNumber
    (必須)
    現在の明細に対してバイヤーが定義した ID。これは、同じ ReceiptRequest ドキュメントのすべての受領書明細で一意である必要があります。
    quantity
    (必須)
    現在の受領書明細の受入済み数量。
    quantity 属性内の負の値は、受入済みオーダーまたはエラーのため戻されたオーダーに対する修正処理を示します。たとえば、数量 20 の明細を含むオーダーに対して、受入済み数量 20 を当初指定したとします。あとで、受入済み数量が 20 ではなく 15 だけで
    あったことが判明したので、負の数による受入処理を実行して、この間違いを修正することができます。

    <ReceiptItem receiptLineNumber="1" quantity="-5" type="received">
    
    type バイヤーが、サプライヤからの品目を受け入れたのか、または返品したのかを示します。この属性に対して次の値を指定できます。
    ● received: バイヤーが商品を受け入れたことを示します。
    例:

    <ReceiptItem receiptLineNumber="1" quantity="20" type="received">
    

    ● returned: バイヤーが商品を返品したことを示します。
    例:

    <ReceiptItem receiptLineNumber="1" quantity="10" type="returned">
    
    parentReceiptLineNumber 受領申請の親明細の明細番号。
    itemType 品目の種類を指定します。使用可能な値は次のとおりです。
    ● composite – 品目グループを識別します。
    ● item – 独立した明細を識別します。
    ● lean – 明細で予定されている子品目がないことを示します。
    compositeItemType 親品目でグループごとの価格設定が使用されるかどうかを指定します。使用可能な値は”groupLevel” または “itemLevel” です。
    completedIndicator “yes” に設定すると、構成品目出荷通知明細が終了とみなされ、構成品目受領はこれ以降行われなくなります。

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

    要素 説明
    ReceiptItemReference
    (必須)
    参照される明細の明細番号を示します。「ReceiptItemReference」を参照してください。
    UnitRate
    (必須)
    指定数量単位当たりの支払額。
    ReceivedAmount
    (必須)
    受領書明細の受入済み商品またはサービスの金額です。受入済み金額の合計は、quantity と UnitRate の積に等しくなる必要があります。
    AssetInfo 各受領書明細の数量ごとの任意設定の資産データが含まれます。
    DeliveryAddress 商品が受領される住所。
    Comments このオブジェクトに関連するコメントが含まれます。
    Batch 1 回の生産実行で生産される品目または商品のバッチ情報を含む要素。
    Classification 受領書の分類。たとえば、受領書明細移動の種類または在庫の種類。複数の分類をサポートするために複数回使用できます。
    Extrinsic このオブジェクトに関連するすべての追加情報が含まれます。

    ReceiptItem の例を次に示します。

    <ReceiptItem quantity="1" receiptLineNumber="1" type="received">
     <ReceiptItemReference lineNumber="1">
     <ItemID>
     <SupplierPartID>RCA15</SupplierPartID>
     </ItemID>
     <Description xml:lang="en">N160INSTLL</Description>
     <ManufacturerPartID>N160INSTLL</ManufacturerPartID>
     <ManufacturerName>RCA</ManufacturerName>
     <ShipNoticeReference shipNoticeID="ASNDOC_002">
     <DocumentReference payloadID="Payload_ASNDOC_002"/>
     </ShipNoticeReference>
     <ReferenceDocumentInfo>
     <DocumentInfo documentType="SalesOrder" documentDate="2016-01-10T17:55:20-05:00" documentID="QN171226_01"/>
     </ReferenceDocumentInfo>
     </ReceiptItemReference>
     <UnitRate>
     <Money currency="USD">400.00</Money>
     <UnitOfMeasure>EA</UnitOfMeasure>
     </UnitRate>
     <ReceivedAmount>
     <Money currency="USD">240.00</Money>
     </ReceivedAmount>
     <AssetInfo location="Sunnyvale" serialNumber="SER20201" tagNumber="tag000005"/>
     <AssetInfo location="Sunnyvale" serialNumber="SER20202" tagNumber="tag000006"/>
     <Classification domain="movementType" code="101">Goods receipt for purchase order or order</Classification>
     <Classification domain="stockType" code="Q">Quality Inspection</Classification>
    </ReceiptItem>
    
    13.6.2.2.1 ReceiptItemReference

    参照される明細の明細番号を示します。ReceiptItemReference には次の属性があります。

    属性 説明
    lineNumber
    (必須)
    OrderRequest ドキュメントからコピーされた現在の明細の明細番号です。この明細番号は、ShipNoticeReference によって参照される構成品目出荷通知の明細を参照することもできます。

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

    要素 説明
    ItemID OrderRequest ドキュメントからコピーされた現在の明細のサプライヤ品番です。
    Description OrderRequest ドキュメントからコピーされた明細の説明です。
    ManufacturerPartID 製造メーカーの品番です。
    ManufacturerName 製造メーカーの名前です。
    ShipNoticeReference この品目が出荷されたときにサプライヤから送信された ShipNoticeRequest ドキュメントへの参照です。
    ShipNoticeIDInfo バイヤーシステムで認識される ShipNoticeRequest の ID です。この ID はShipNoticeReference を省略する際に使用されます。
    ShipNoticeLineItemReference 前の ShipNoticeRequest ドキュメントの明細への参照です。
    ReferenceDocumentInfo 追加のドキュメント参照情報が含まれます。「ReferenceDocumentInfo」を参照してください。



    ← cXML リファレンスガイド 目次へ戻る

     サプライヤは、cXML InvoiceDetail トランザクションを使用して、バイヤー企業またはマーケットプレイスに請求書を送信できます。このトランザクションでは、さまざまな業務のシナリオ (標準の請求書、クレジットメモ、明細レベルのクレジットメモ、デビットメモ、および受領書など) に対応した請求書詳細がサポートされています。

    ページ内の目次
    14.1 請求書の概要

    14.1.1 以前の InvoiceRequest ドキュメント
    14.1.2 借方金額および貸方金額
    14.1.3 出荷情報
    14.1.4 請求書の種類
    14.1.4.1 個別請求書およびサマリ請求書
    14.1.4.2 請求書レベル
    14.1.4.3 請求書の目的
    14.1.5 請求書 DTD

    14.2 InvoiceDetailRequest

    14.2.1 InvoiceDetailRequestHeader
    14.2.1.1 InvoiceDetailHeaderIndicator
    14.2.1.2 InvoiceDetailLineIndicator
    14.2.1.3 InvoicePartner
    14.2.1.4 DocumentReference
    14.2.1.5 InvoiceIDInfo
    14.2.1.6 PaymentProposalIDInfo
    14.2.1.7 InvoiceDetailShipping
    14.2.1.8 InvoiceDetailPaymentTerm (非推奨)
    14.2.1.9 PaymentTerm
    14.2.1.10 PaymentInformation
    14.2.1.11 Period
    14.2.1.12 コメント
    14.2.1.13 IdReference
    14.2.1.14 Extrinsic
    14.2.2 InvoiceDetailOrder
    14.2.2.1 InvoiceDetailOrderInfo
    14.2.2.2 InvoiceDetailItem
    14.2.2.2.1 PriceBasisQuantity
    14.2.2.2.2 InvoiceDetailItemReference
    14.2.2.2.3 ReceiptLineItemReference
    14.2.2.2.4 ShipNoticeLineItemReference
    14.2.2.2.5 ServiceEntryItemReference
    14.2.2.2.6 ServiceEntryItemIDInfo
    14.2.2.2.7
    14.2.2.2.7.1 TaxDetail
    14.2.2.2.8 InvoiceDetailLineSpecialHandling
    14.2.2.2.9 InvoiceDetailLineShipping
    14.2.2.2.10 ShipNoticeIDInfo
    14.2.2.2.11 InvoiceDetailDiscount
    14.2.2.2.12 InvoiceItemModifications
    14.2.2.2.13 InvoiceDetailItemIndustry
    14.2.2.3 InvoiceDetailServiceItem
    14.2.2.4 InvoiceDetailReceiptInfo
    14.2.2.5 InvoiceDetailShipNoticeInfo
    14.2.3 InvoiceDetailHeaderOrder
    14.2.3.1 InvoiceDetailOrderInfo
    14.2.3.2 InvoiceDetailOrderSummary
    14.2.4 InvoiceDetailSummary
    14.2.4.1 SubtotalAmount
    14.2.4.2
    14.2.4.3 SpecialHandlingAmount
    14.2.4.4 ShippingAmount
    14.2.4.5 GrossAmount
    14.2.4.6 InvoiceDetailDiscount
    14.2.4.7 InvoiceHeaderModifications
    14.2.4.8 TotalCharges
    14.2.4.9 TotalAllowances
    14.2.4.10 TotalAmountWithoutTax
    14.2.4.11 NetAmount
    14.2.4.12 DepositAmount
    14.2.4.13 DueAmount
    14.2.4.14 InvoiceDetailSummaryIndustry

    14.3 Response
    14.4 請求書の状況更新
    14.5 請求書の例

    14.5.1 標準ヘッダー請求書
    14.5.2 標準詳細請求書
    14.5.3 サービス請求書
    14.5.4 マーケットプレイス請求書
    14.5.5 返品品目の明細レベルのクレジットメモ
    14.5.6 会計情報分割のある請求書

    14.1 請求書の概要

    サプライヤは、cXML 請求書を使用して、バイヤー企業またはマーケットプレイスに対して、提供済みの製品またはサービスについての請求を行います。1 つまたは複数の注文書に含まれるいかなる部分に対しても請求書を生成できます。InvoiceDetail トランザクションでは、請求書、クレジットメモ、明細レベルのクレジットメモ、デビットメモ、および受領書のキャンセルがサポートされています。請求書には、注文書、明細、関連するパートナー、勘定科目配分、支払条件、割引、出荷費用およびその他手数料、税、内金および前払、および送金情報が記述されます。サプライヤは、請求書をネットワークハブに送信します。ネットワークハブは、バイヤー企業の ProfileResponse に問い合わせるか、またはバイヤー企業のネットワークアカウントでルーティング情報を調べて、請求書をバイヤー企業に転送します。cXML InvoiceDetailRequest ドキュメントは、請求書を表します。受信側のシステムは、請求書ドキュメントを受け付けた後、一般的な cXML Response を使用して応答します。バイヤー企業は、請求書の処理を開始して StatusUpdateRequest ドキュメントを送信し、照合の進捗状況をネットワークハブに通知します。ネットワークハブは、これらのドキュメントをサプライヤに転送できます。

    14.1.1 以前の InvoiceRequest ドキュメント

    以前は、cXML 請求処理のサポートが InvoiceRequest ドキュメントで提供されていました。このドキュメントは、InvoiceDetailRequest と比較すると詳細情報が少なく、明細またはサマリ請求書がサポートされていませんでした。InvoiceRequest は、cXML 1.2.011 では推奨されていません。すべての cXML 請求書プロジェクトはInvoiceDetailRequest を実装する必要があります。

    14.1.2 借方金額および貸方金額

    請求書では、正の金額は借方で、バイヤー企業はサプライヤに対する支払義務があります。負の金額は、サプライヤからバイヤー企業に対して発生した貸方です。たとえば、サプライヤは -50 USD の SubtotalAmount を指定して、50 米国ドルの貸方をバイヤー企業に対して発生させることができます。借方は、標準の請求書とデビットメモの両方で使用できます。貸方は、標準の請求書、クレジットメモ、および明細レベルのクレジットメモで使用できます。P カードを使用できる注文書の場合、サプライヤは請求書または ConfirmationRequest ドキュメントで指定された支払申請機能を使用して、支払いを要求することができます。

    14.1.3 出荷情報

    請求書には、出荷費用、日付、出荷元/出荷先住所、運送業者 ID などの出荷情報を含めることができます。請求書で出荷情報をサポートする理由の 1 つは、請求書が国外に出荷されるオーダーの最終価格と税に影響する可能性があるためです。請求書の出荷情報が ShipNoticeRequest ドキュメント送信の代用になるわけではありません。

    14.1.4 請求書の種類

    InvoiceDetailRequest は、ほとんどの業務シナリオに対応する機能と柔軟性を備えています。

    14.1.4.1 個別請求書およびサマリ請求書

    cXML は、個別請求書とサマリ請求書の両方に対応しています。

    請求書カテゴリ 説明
    個別請求書 1 つの注文書に対して適用します。
    サマリ請求書 複数の注文書に対して適用します。
    14.1.4.2 請求書レベル

    cXML は、ヘッダー請求書と詳細請求書の両方に対応しています。

    請求書レベル 説明
    ヘッダー請求書 明細を記述せずに、1 つ以上の注文書全体に対して適用します。isHeaderInvoice=”yes” を指定して、明細情報を含まないInvoiceDetailHeaderOrder 要素を使用します。
    詳細請求書 (明細レベル請求書) 1 つ以上の注文書の特定の明細に対して適用します。isHeaderInvoice を除外して、明細情報を含む InvoiceDetailOrder 要素を使用します。
    14.1.4.3 請求書の目的

    InvoiceDetailRequestHeader 属性を使用して、請求書の目的を指定します。

    要素 説明
    標準請求書 製品またはサービスを提供した後に支払いを要求します。purpose=”standard” および operation=”new” を指定します。
    クレジットメモ バイヤー企業に対する貸方を指定します。purpose=”creditMemo” および operation=”new” を指定します。ヘッダー請求書である必要があります。金額は負である必要があります。
    明細レベルのクレジットメモ バイヤー企業に対する貸方を指定します。
    purpose=”lineLevelCreditMemo” および operation=”new” を指定します。ヘッダー請求書でないことが必要です。金額は負である必要があります。
    デビットメモ バイヤー企業に対する借方を指定します。purpose=”debitMemo” および operation=”new” を指定します。ヘッダー請求書である必要があります。金額は正である必要があります。
    情報参照用 受領書と同様、手数料の記録を提供します。処理は不要です。isInformationOnly=”yes” および operation=”new” を指定します。
    請求書のキャンセル 以前に送信した請求書をキャンセルします。operation=”delete” を指定します。

    14.1.5 請求書 DTD

    cXML 標準では、複数の DTD を使用してパーサーの検証のパフォーマンスを最適化します。InvoiceDetail トランザクションは、InvoiceDetail.dtd という名前の別の DTD で定義されます。この DTD は次の場所で取得できます。

    http://xml.cXML.org/schemas/cXML//InvoiceDetail.dtd

    14.2 InvoiceDetailRequest

    InvoiceDetailRequest ドキュメントは請求書を表します。InvoiceDetailRequest ドキュメントの構造は以下のとおりです。

    <Request>
     <InvoiceDetailRequest>
     <InvoiceDetailRequestHeader>
     header information
     </InvoiceDetailRequestHeader>
     <InvoiceDetailHeaderOrder>
     order-level invoice information
     </InvoiceDetailHeaderOrder>
     ...
     or
     <InvoiceDetailOrder>
     detailed line-item information
     </InvoiceDetailOrder>
     ...
     <InvoiceDetailSummary>
     invoice summary
     </InvoiceDetailSummary>
     </InvoiceDetailRequest>
    </Request>
    

    InvoiceDetailOrder 要素は詳細 (明細レベル) 請求書で使用され、InvoiceDetailHeaderOrder 要素はヘッダー請求書で使用されます。請求書に両方の要素を含めることはできません。どちらの要素にも、請求書明細が含まれます。請求書明細レベルの金額をすべて加算すると、InvoiceDetailSummary.で指定した合計になります。

    14.2.1 InvoiceDetailRequestHeader

    請求書全体に適用するヘッダー情報を定義します。
    InvoiceDetailRequestHeader には次の属性があります。

    属性 説明
    invoiceID
    (必須)
    サプライヤが生成する請求書の識別子。これは、実際の請求書の一番上に表示される請求書番号と同一です。
    isInformationOnly バイヤー企業が処理を行う必要があるかどうかを示します。使用可能な値は次のとおりです。
    ● yes – バイヤー企業に情報を提供するための請求書です (バイヤー企業は処理を行う必要
    はありません)。
    ● 指定なし – (通常設定) 請求書を実際に使用します。バイヤー企業は、このドキュメントを受け取った時点で処理を行う必要があります (支払いを行うか、または貸方を承認します)。
    purpose 請求書の目的を示します。使用可能な値は次のとおりです。
    ● standard – (通常設定) サプライヤからバイヤー企業への標準の請求書。
    ● creditMemo – バイヤー企業に対してクレジットを発行するためのクレジットメモ。isHeaderInvoice を yes にする必要があります。また、要素InvoiceDetailSummary/DueAmount は負の金額であることが必要です。
    ● debitMemo – バイヤー企業の負債残高を請求するためのデビットメモ。isHeaderInvoice を yes にする必要があります。また、要素InvoiceDetailSummary/DueAmount は正の金額であることが必要です。
    ● lineLevelCreditMemo – バイヤー企業に対してクレジットを発行するための明細レベルのクレジットメモ。isHeaderInvoice を false にする (指定しない) 必要があります。また、要素 InvoiceDetailSummary/DueAmount は負の金額であることが必要です。
    ● lineLevelDebitMemo – バイヤーの負債残高をサプライヤに請求する明細レベルのデビットメモ。isHeaderInvoice を false にする (指定しない) 必要があります。また、要素InvoiceDetailSummary/DueAmount は正の金額であることが必要です。
    operation 請求書でのこのドキュメントの動作方法を示します。使用可能な値は次のとおりです。
    ● new – (通常設定) 新規の請求書を作成します。
    ● delete – 既存の請求書をキャンセルします。既存の請求書の payloadID をDocumentReference に指定する必要があります。
    invoiceDate
    (必須)
    請求書が作成された日時 (cXML のタイムスタンプより前であることが必要です)。
    invoiceOrigin カテゴリ化する請求書の作成者を指定します。使用可能な値は次のとおりです。
    ● supplier – サプライヤが作成した請求書です。
    ● buyer – バイヤーが作成した請求書です。
    ● 指定なし – 請求書作成元が不明です。
    isERS 請求書が入庫/請求自動決済 (ERS) 請求書であるかどうかを示します。指定可能な値は “yes”のみです。指定しない場合は、通常の請求書です。

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

    要素 説明
    InvoiceDetailHeaderIndicator 請求書のすべての属性を記述する区分を定義します。「InvoiceDetailHeaderIndicator[348 ページ]」を参照してください。
    InvoiceDetailLineIndicator 請求書明細レベルにおける請求の詳細の存在を示します。「InvoiceDetailLineIndicator[349 ページ]」を参照してください。
    InvoicePartner 請求書の発行者や販売先など、請求処理に関係する組織を定義します。「InvoicePartner [349 ページ]」を参照してください。
    DocumentReference 以前の InvoiceDetailRequest ドキュメントを識別します。「DocumentReference [352 ページ]」を参照してください。
    InvoiceIDInfo サプライヤのシステムで認識されている以前の請求書の ID を定義します。「InvoiceIDInfo [352 ページ]」を参照してください。
    PaymentProposalIDInfo サプライヤおよびバイヤーのシステムで認識されているPaymentProposalRequest の ID を定義します。「PaymentProposalIDInfo[352 ページ]」を参照してください。
    InvoiceDetailShipping 請求書の出荷の詳細が含まれます。「InvoiceDetailShipping [353 ページ]」を参照してください。
    ShipNoticeIDInfo 追加の出荷関連の ID を指定します。「ShipNoticeIDInfo [368 ページ]」を参照してください。
    InvoiceDetailPaymentTerm | PaymentTerm InvoiceDetailPaymentTerm は非推奨になりました。「InvoiceDetailPaymentTerm (非推奨) [354 ページ]」を参照してください。PaymentTerm は請求書またはオーダーの支払条件を定義します。「PaymentTerm[354 ページ]」を参照してください。
    PaymentInformation バイヤーが ERP 請求書のコピーおよび ERS 請求書で提供できる支払情報を定義します。バイヤーによって決定された請求書の支払期日が含まれます。「PaymentInformation [355 ページ]」を参照してください。
    Period サービスが提供された期間です。「Period [355 ページ]」を参照してください。
    Comments 請求書に関するコメントが含まれます。「Comments [125 ページ]」を参照してください。
    IdReference ID 参照を定義します。「IdReference [305 ページ]」を参照してください。
    Extrinsic 請求書に関連する追加情報が含まれます。InvoiceDetailRequestHeader または InvoiceDetailRequest に含まれる情報は複製しないでください。
    14.2.1.1 InvoiceDetailHeaderIndicator

    請求書のすべての属性を記述する区分を定義します。通常設定では、すべての区分は FALSE になります。InvoiceDetailHeaderIndicator には次の属性があります。

    属性 説明
    isHeaderInvoice 請求書のカテゴリです。使用可能な値は次のとおりです。
    ● yes – ヘッダー請求書です。請求書では、明細の詳細を記述しないヘッダーレベルの請求書情報を含むInvoiceDetailHeaderOrder が使用されます。
    ● 指定なし – 詳細請求書です。請求書では、明細の詳細を含むInvoiceDetailOrder が使用されます。
    isVatRecoverable yes – 請求書全体が VAT (付加価値税) 還付可能です。
    priceBasedLineLevelCreditMemo yes に設定すると、請求書が、元の請求書が発行された後に付与された早期支払割引の単価に基づいた明細レベルのクレジットメモであることが示されます。
    14.2.1.2 InvoiceDetailLineIndicator

    請求書明細レベル (InvoiceDetailItem、InvoiceDetailServiceItem、またはInvoiceDetailOrderSummary 内) で請求書の詳細が記述されていることを示します。通常、すべての区分はFALSE になります。この要素で請求書の詳細が請求書明細レベルで記述されていることが示されている場合、その情報を提供していない請求書明細は、値がゼロであるか、またはその情報が「使用不可」であるとみなされます。InvoiceDetailLineIndicator には次の属性があります。

    属性 説明
    isTaxInLine yes – 税 (Tax) が請求書明細レベルで指定されます。ヘッダーレベルの税が指定されている場合は、無視されます。
    isSpecialHandlingInLine yes – その他手数料 (InvoiceDetailLineSpecialHandling) が請求書明細レベルで提供されます。
    isShippingInLine yes – 出荷 (InvoiceDetailLineShipping) が請求書明細レベルで提供されます。
    isDiscountInLine yes – 割引 (InvoiceDetailDiscount) が請求書明細レベルで提供されます。
    isAccountingInLine yes – 勘定科目配分 (Distribution) が請求書明細レベルで提供されます。Distribution は明細レベルでのみ使用できるため、isHeaderInvoice がTRUE の場合は、この区分を指定しないでください。
    isPriceAdjustmentInLine yes – 明細レベルのクレジットメモまたはデビットメモに価格の調整が含まれます。
    14.2.1.3 InvoicePartner

    請求書の発行者や販売先など、請求処理に関係する組織を定義します。Contact 要素だけでは請求処理に関係するさまざまな参照識別子がサポートされないため、請求書ではInvoicePartner 要素もサポートされています。出荷元または出荷先の指定にはこの要素を使用しないでください。代わりに、InvoiceDetailShipping を使用してください。

    Contact(連絡先)

    請求書のパートナーの連絡先情報。指定可能な連絡先役割には、billFrom、billTo、from、issuerOfInvoice、receivingBank、remitTo、shipFrom、shipTo、soldTo、wireReceivingBank があります。

    注記
    from と issuerOfInvoice は同義である必要があります。

    IdReference

    ID 参照を定義します。識別子/ドメインのペアは、それぞれの取引先との取引関係 (バイヤー企業およびサプライヤ) において一意であることが必要です。IdReference には次の属性があります。

    属性 説明
    identifier
    (必須)
    ドメイン内にある IdReference の一意の識別子です。
    domain
    (必須)
    IdReference のドメインです。サポートされる値は、ご使用の購買アプリケーションによって異なります。使用可能な値は次のとおりです。
    ● 1099ID
    ● abaRoutingNumber
    ● accountID
    ● accountName
    ● accountPayableID
    ● accountReceivableID
    ● accountType
    ● bankAccountID
    ● bankBranchID
    ● bankNationalID
    ● bankRoutingID
    ● branchName
    ● companyRegistrationNumber
    ● contactPerson
    ● courtRegisterID
    ● creditorRefID
    ● departmentName
    ● documentName
    ● federalTaxID
    ● governmentNumber
    ● gstID
    ● ibanID
    ● iso6523
    ● isoBicID
    ● provincialTaxID
    ● reference
    ● stateTaxID
    ● supplierReference
    ● supplierTaxID
    ● swiftID
    ● taxExemptionID
    ● vatID

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

    要素 説明
    Creator IdReference の作成者 (銀行、出荷担当者、その他の組織の名前など) です。
    Description 人間が読める IdReference のテキスト形式の説明です。
    14.2.1.4 DocumentReference

    以前の InvoiceDetailRequest ドキュメントを識別します。operation=”delete” の場合は、DocumentReference が必要であり、(operation=”new” が設定された) 元の InvoiceDetailRequest ドキュメントが参照される必要があります。その他のすべての状況では、DocumentReference の設定は任意です。DocumentReference には次の属性があります。

    属性 説明
    payloadID
    (必須)
    別の cXML ドキュメントの payloadID 属性です。
    14.2.1.5 InvoiceIDInfo

    サプライヤのシステムで認識されている以前の請求書の ID を定義します。DocumentReference と InvoiceIDInfoの両方が指定されている場合は、同じ請求書が参照される必要があります。InvoiceIDInfo は、以下の 2 つの属性のコンテナです。

    属性 説明
    invoiceID
    (必須)
    サプライヤのシステムで認識されている請求書の ID です。
    invoiceDate 請求日。
    14.2.1.6 PaymentProposalIDInfo

    サプライヤおよびバイヤーのシステムで認識されている PaymentProposalRequest の ID を定義します。この要素には、次の属性があります。

    属性 説明
    paymentProposalID
    (必須)
    バイヤーおよびサプライヤのシステムで認識されている PaymentProposalRequestの ID です。
    14.2.1.7 InvoiceDetailShipping

    請求書の出荷の詳細です。InvoiceDetailShipping には次の属性があります。

    属性 説明
    shippingDate この出荷がサプライヤから発送される日時。
    Contact(連絡先)

    出荷元住所および出荷先住所です。出荷元と出荷先の両方を指定する必要があります。「Contact」を参照
    してください。

    CarrierIdentifier

    このリストには、同じ運送業者について複数の識別子を含めることができます。このリスト内の要素に順序の制限はありません。識別ドメイン (CarrierIdentifier ドメイン) は、InvoiceDetailShipping 要素内で 2 回以上使用しないでください。1 つの CarrierIdentifier リストの要素によって提供されるすべての ID は、同じ運送業者に対応している必要があります。CarrierIdentifier には次の属性があります。

    属性 説明
    domain
    (必須)
    この値のドメイン。使用可能な値は次のとおりです。
    ● companyName – この会社の法的に有効な名称です。これは、場合によっては「carrierCorporate」という役割を持つ Contact 要素で提供されます。Contact 要素の使用は、運送業者に関する追加詳細を含めなければならないときのために残しておく必要があります。
    ● SCAC – Standard Carrier Alpha Code。www.nmfta.org/pages/scac
    ● IATA – International Air Transport Association。www.iata.org
    ● AAR – Association of American Railroads。www.aar.org
    ● UIC – International Union of Railways。www.uic.org
    ● EAN – European Article Numbering。upc-ean-information.com
    ● DUNS – D&B’s Data Universal Numbering System。www.dnb.com
    ShipmentIdentifier

    この出荷のトラッキング番号です。「ShipmentIdentifier」を参照してください。

    DocumentReference

    以前の ShipNoticeRequest を識別します。詳細については、「DocumentReference」を参照してください。

    14.2.1.8 InvoiceDetailPaymentTerm (非推奨)

    InvoicedetailPaymentTerm は、cXML 1.2.011 では推奨されていません。InvoicedetailPaymentTerm [350 ペー
    ジ] が推奨されています。

    14.2.1.9 PaymentTerm

    請求書またはオーダーの支払条件を定義します。PaymentTerm では、支払期間 (割引なし) または割引適用期間 (割
    引あり) を定義します。
    PaymentTerm には次の属性があります。

    属性 説明
    payInNumberOfDays 請求書の発行日以降、全額の支払期限までの日数。
    Discount

    割引条件の割引率 (%) または割引金額。この割引率は、payInNumberOfDays で指定した期間内に請求書の合計が支払われた場合に適用されます。正の比率は割引を示し、負の比率は違約金を示します。パーセント記号 (%) を使用したり、100 で除算したりしないでください。たとえば、2 は 2% を意味します。PaymentTerm に支払期間 (割引なし) を指定する場合、Discount 要素は使用しないでください。

    Extrinsic

    この支払いに関連する追加情報を指定します。これには、ValueDate および DiscountTermsDueDate を含めることができます。

    14.2.1.10 PaymentInformation

    バイヤーが ERP 請求書のコピーおよび ERS 請求書で提供できる支払情報を定義します。バイヤーによって決定された請求書の支払期日が含まれます。PaymentInformation には次の属性があります。

    属性 説明
    paymentNetDueDate この日時以降は割引なしで請求書を支払う必要があります。日付/時間値には、協定世界時 (UTC) からのタイムゾーンオフセットを含めることができます。「日付、時刻およびその他のデータタイプ [25 ページ]」を参照してください。支払期日は、バイヤーが請求書処理システムで行った設定に基づいて割引なしで請求書を支払う必要がある日時を決定します。支払期日の値は、法的に拘束力のある日付ではありません。実際の支払は、その日付よりも前または後に行われることがあります。

    次の例は、PaymentInformation 要素を示しています。

    <PaymentInformation paymentNetDueDate="2021-05-31T00:00:00-08:00"/>
    
    14.2.1.11 Period

    サービスが提供された期間です。Period には次の属性があります。

    属性 説明
    startDate サービスの開始日
    endDate サービスの終了日
    14.2.1.12 コメント

    請求書に関するコメントです。

    14.2.1.13 IdReference

    ID 参照を定義します。「IdReference」を参照してください。

    14.2.1.14 Extrinsic

    請求書に関する追加情報を指定します。InvoiceDetailRequestHeader または InvoiceDetailRequest で何も重複していないことを確認する必要があります。

    14.2.2 InvoiceDetailOrder

    明細の詳細を含むオーダーの請求書情報を定義します。isHeaderInvoice が FALSE (指定なし) である場合にのみ使用されます。請求書明細は InvoiceDetailItem または InvoiceDetailServiceItem です。その請求書明細番号は invoiceLineNumber 属性で指定されます。

    14.2.2.1 InvoiceDetailOrderInfo

    オーダー参照や関連する主契約の参照といった、対応する注文書に関連する情報を定義します。アプリケーションでは、この情報を使用して、対応する注文書または主契約と請求書が照合されます。参照を詳細に定義するほど、アプリケーションによるドキュメントの照合を正確に実行できます。InvoiceDetailOrderInfo には、ドキュメントの参照を目的とした複数の要素を含めることができます。OrderReference の使用が強く推奨されますが、該当する情報を入手できない場合は、MasterAgreementReference、MasterAgreementIDInfo、OrderIDInfo、または SupplierOrderInfo をこの順序で使用してください。

    OrderReference

    請求処理される注文書への参照です。

    MasterAgreementReference

    以前の MasterAgreementRequest ドキュメントへの参照を定義します。この要素は、請求処理されるリリースオーダーの主契約を指定します。MasterAgreementReference には次の属性があります。

    属性 説明
    agreementID バイヤー企業のシステムで認識されている主契約の ID 番号。
    agreementDate 主契約申請が作成された日時。
    agreementType 参照先契約が分納契約リリースであるかどうかを示します。
    MasterAgreementIDInfo

    請求処理されるオーダーがリリースオーダーである場合、対応する主契約のバイヤー企業の ID 番号を定義します。この要素は、主契約または請求処理されるリリースオーダーの契約を指定します。MasterAgreementIDInfo には次の属性があります。

    属性 説明
    agreementID
    (必須)
    バイヤー企業のシステムで認識されている主契約の ID 番号。
    agreementDate 主契約申請が作成された日時。
    agreementType 参照先契約が分納契約リリースであるかどうかを示します。

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

    要素 説明
    IdReference 主契約の追加 ID を指定します。
    OrderIDInfo

    バイヤー企業で認識されている注文書を指定します。OrderIDInfo には次の属性があります。

    属性 説明
    orderID
    (必須)
    バイヤー企業で認識されている注文書の ID (注文書番号)。
    orderDate 注文書が作成された日時。
    SupplierOrderInfo

    注文書に関連したサプライヤ受注情報を定義します。SupplierOrderInfo には次の属性があります。

    属性 説明
    orderID
    (必須)
    注文書のサプライヤ受注 ID。
    orderDate 受注の日時。
    14.2.2.2 InvoiceDetailItem

    請求書の明細を定義します。バイヤー企業では、注文書に指定された情報と照合するために、この情報を必要とする場合があります。たとえば、バイヤー企業は場合によって、UnitOfMeasure の値に変更がないことを確認する必要があります。InvoiceDetailItem には次の属性があります。

    属性 説明
    invoiceLineNumber
    (必須)
    現在の請求書明細に対してサプライヤが定義した ID です。請求書内のすべての請求書明細で一意であることが必要です。
    quantity
    (必須)
    請求処理される明細ごとの数量。
    referenceDate 包括注文書または契約品目の参照日。この属性の使用は多くの場合任意です。また、トランザクションに関連する取引先によって定義される必要があります。調達ソフトウェアでは、包括注文書または契約品目と請求書の照合時にこの日付を使用する場合があります。
    inspectionDate 法的な税定義によって決定される、商品配達の日付またはサービス配送の日付です。この属性の使用は多くの場合任意です。また、トランザクションに関連する取引先によって定義される必要があります。
    parentInvoiceLineNumber 対応する親明細の明細番号を指定します。この属性は、itemType=”item” が設定された明細にのみ適用できます。
    itemType 品目の種類を指定します。使用可能な値は次のとおりです。
    ● composite – 品目グループを識別します。
    ● item – 独立した明細を識別します。
    ● lean – 明細で予定されている子品目がないことを示します。
    compositeItemType 親品目でグループごとの価格設定が使用されるかどうかを指定します。使用可能な値は”groupLevel” または “itemLevel” です。
    reason 明細レベルのクレジットメモの理由を指定します。理由に指定できる値は、返品品目用のクレジットメモを表す “return” のみです。
    isAdHoc [yes] に設定すると、品目が参照ドキュメントまたは契約 (主契約) に存在しないことを示します。

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

    要素 説明
    UnitOfMeasure
    (必須)
    明細の数量単位です。「UnitOfMeasure」を参照してください。
    UnitPrice
    (必須)
    単価です。
    PriceBasisQuantity 明細の数量ベースの価格設定です。「PriceBasisQuantity」を参照してください。
    InvoiceDetailItemReference
    (必須)
    請求書明細に関連するすべての参照を定義します。
    InvoiceDetailItemReference」を参照してください。
    ReceiptLineItemReference この明細に関連する受領書明細を参照します。「ReceiptLineItemReference」を参照してください。
    ShipNoticeLineItemReference この明細に関連する出荷通知明細を参照します。「ShipNoticeLineItemReference」を参照してください。
    ServiceEntryItemReference この明細に関連するサービスシート明細を参照します。「ServiceEntryItemReference」を参照してください。
    ServiceEntryItemIDInfo 請求書に関連する ServiceEntryRequest を参照します。「ServiceEntryItemIDInfo」を参照してください。
    SubtotalAmount 現在の明細の請求書の小計 (UnitPrice * 数量) です。
    Tax 明細の税です。「」を参照してください。
    InvoiceDetailLineSpecialHandling 明細のその他手数料情報が含まれます。「InvoiceDetailLineSpecialHandling」を参照してください。
    InvoiceDetailLineShipping 明細の出荷情報が含まれます。「InvoiceDetailLineShipping」を参照してください。
    ShipNoticeIDInfo 出荷に関連する ID の追加参照 ID を指定します。「ShipNoticeIDInfo」を参照してください。
    GrossAmount SubtotalAmount に明細の税、出荷費用、その他手数料を加算した金額です。
    InvoiceDetailDiscount 明細に適用される割引です。「InvoiceDetailDiscount」を参照してください。
    InvoiceItemModifications 請求書品目の商品とサービスの陸揚げ費用合計で発生した追加の手数料、値引き、およびそれらの税額を指定します。「InvoiceItemModificDtions」を参照してください。
    TotalCharges 商品およびサービスに適用されるすべての手数料の合計です。これを請求書の明細と概要に表示できます。
    TotalAllowances 商品およびサービスに適用されるすべての値引きの合計です。これを請求書の明細と概要に表示できます。
    TotalAmountWithoutTax 税抜きの請求金額合計がまとめられます。「TotalAmountWithoutTax」を参照してください。
    NetAmount GrossAmount から明細の割引を差し引いた金額です。
    Distribution コストセンタまたは総勘定元帳カテゴリなど、バイヤー企業により生成される会計情報です。この情報は、OrderRequest からコピーされる必要があります。isAccountingInLine が FALSE (指定なし) の場合は無視されます。
    Packaging 明細の梱包について詳細を記述します。「Packaging」を参照してくだ