16. カタログ

カタログは、製品およびサービスの内容をバイヤー企業に伝えるドキュメントです。サプライヤはカタログを使用して、提供する製品とサービスの情報およびそれらの価格を記述します。

16.1 カタログの定義

16.1.1 Supplier
16.1.1.1 SupplierLocation
16.1.2 Index
16.1.2.1 IndexItem、IndexItemAdd、IndexItemDelete、および IndexItemPunchout

16.2 型の定義

16.2.1 TypeProvider
16.2.1.1 Name
16.2.1.2 OrganizationID
16.2.2 Type
16.2.2.1 Name
16.2.2.2 説明
16.2.3 TypeAttribute
16.2.3.1 名称
16.2.3.2 説明
16.2.3.3 EnumerationValue
16.2.3.4 Range
16.2.4 PrimitiveType

16.3 受信登録管理の定義

16.3.1 サプライヤデータ
16.3.1.1 SupplierListRequest
16.3.1.2 SupplierListResponse
16.3.1.3 SupplierDataRequest
16.3.1.4 SupplierDataResponse
16.3.1.5 SupplierChangeMessage
16.3.2 サプライヤプロファイル情報
16.3.2.1 OrganizationDataRequest
16.3.2.2 OrganizationDataResponse
16.3.2.3 OrganizationChangeMessage
16.3.3 カタログ登録
16.3.3.1 Subscription
16.3.3.2 SubscriptionListRequest
16.3.3.3 SubscriptionListResponse
16.3.3.4 SubscriptionContentRequest
16.3.3.5 SubscriptionContentResponse
16.3.3.6 SubscriptionChangeMessage
16.3.3.7 SubscriptionStatusUpdateRequest

16.4 カタログアップロードトランザクション

16.4.1 CatalogUploadRequest
16.4.1.1 カタログの添付
16.4.2 Response
16.4.2.1 後からのカタログ状況の受信
16.4.2.2 URLPost

16.1 カタログの定義

cXML カタログの定義は、Supplier と Index の 2 つのメイン要素で構成されます。これらの要素は、ハブまたはバイ
ヤー企業の購買システム内で永続的またはキャッシュでの使用を目的とするデータを記述します。

  • Supplier – 住所、連絡先、およびオーダー情報などのサプライヤに関する基本データが含まれます。
  • Index – 説明、品番、および分類コードなどのサプライヤの商品およびサービスの在庫に関するデータが記述されます。

カタログの Contract 要素は、cXML 1.2.008 で非推奨になりました。Index はいくつかのサブ要素を使用して、サプライヤの在庫の明細を記述する点に注意してください。サプライヤは、バイヤーのシステム内にキャッシュする価格情報を送信するか、バイヤーが価格情報やそのほかの情報のリモート Web サイトにパンチアウトできるようにパンチアウト情報を送信することができます。これらの要素は、XML 準拠の文書では、一般的に最上位レベルの要素として使用されるため、cXML の中ではほとんど使用されません。実際に、Index は、cXML ドキュメントのほかの部分ではめったに使用されません。

16.1.1 Supplier

Supplier 要素は、商品およびサービスを提供するサプライヤを指定して、カプセル化するのに使用します。この要素には、Name 要素と SupplierID 要素を含める必要があります。さらに、この要素には、任意設定の住所、およびサプライヤのオーダー情報も記述できます。

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

属性説明
corporateURLサプライヤの Web サイトの URL
storeFrontURLショッピングまたは商品やサービスを参照する Web サイトの URL

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

16.1.1.1 SupplierLocation

サプライヤは、複数の所在地で商取引を行う場合があります。SupplierLocation 要素は、所在地ごとに使用できます。さらに、この要素により、その所在地におけるビジネスの運営方法やオーダーの受け取り方法がカプセル化されます。SupplierLocation 要素には、1 つの Address と OrderMethods のセットが含まれます。

OrderMethods および OrderMethod

OrderMethods 要素は、特定の SupplierLocation 要素に対して 1 つ以上の OrderMethod 要素をグループ化したものです。一覧における OrderMethods の位置が重要です。最初の要素は、優先度の最も高いオーダー方法で、2番目の要素は次に優先度の高いオーダー方法というように、順序が後になるほど優先度も低くなります。OrderMethod は、オーダーターゲット (電話、FAX、または URL など) と任意設定のプロトコルの形式でオーダー情報をカプセル化し、特定のターゲット (たとえば、URL ターゲットの “cxml”) でオーダー予想をさらに明確にします。

16.1.2 Index

この要素は、バイヤー企業の購買システム内でカタログを更新するためのルート要素です。Index 要素は、単一のサプライヤと関連付けられます。Index 要素にはサプライヤ ID の一覧を記述できます。この場合、各 ID はそのサプライヤの同義語とみなされます。Index には、1 つまたは複数の IndexItem 要素が含まれます。IndexItem 要素には、バイヤー企業のキャッシュされたカタログに追加またはそこからの削除を行う要素が含まれます。次の例では、Index 要素の概要を示します。

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

属性説明
loadmodeターゲットのアプリケーションで Index をロードするモード。使用可能な値は次のとおりです。
● Full – 以前にロードされたインデックスを完全に置き換えます。
● Incremental – 既存のインデックスに追加する形でインデックスをインポートします。品目が既に存在する場合は置き換えるか削除して、新しい品目を追加します。推奨されるアプリケーションの通常設定はIncremental です。
16.1.2.1 IndexItem、IndexItemAdd、IndexItemDelete、およびIndexItemPunchout

IndexItem 要素は、インデックス内の品目の一覧のコンテナです。この要素は、次の 3 種類の要素で構成されます。

  • IndexItemAdd – インデックスに新規の品目を挿入するか、インデックス内の既存の品目を更新します。ItemID 要素、ItemDetail 要素、および IndexItemDetail 要素が含まれます。
  • IndexItemDelete – インデックスから品目を削除します。品目を識別する ItemID 要素が含まれます。
  • IndexItemPunchout – サプライヤの Web サイトへのパンチアウトを開始するための品目を挿入します。PunchoutDetail 要素と ItemID 要素が含まれます。この要素は、価格情報を要求しない点を除いて、IndexItemAdd 要素に類似しています。バイヤーは、サプライヤの Web サイトから品目の詳細をリアルタイムで取得します。
ItemID

品目を一意に識別する基本的な ItemID 要素。「ItemID [90 ページ]」を参照してください。

ItemDetail

ItemDetail には、品目に関する詳細情報や、品目に関してユーザーが参照できる ItemID で示された基本情報以外のすべてのデータが含まれます。この要素には、1 つの UnitPrice、1 つの UnitOfMeasure、1 つ以上の Description 要素、および 1 つの Classification を含める必要があります。また、任意で 1 つの ManufacturerPartID、1 つの ManufacturerName、1 つの URL、LeadTime、および任意の数の Extrinsic 要素を含めることができます。「ItemDetail [91 ページ]」を参照してください。任意設定の LeadTime 要素は、バイヤーが製品を受け取るまでに必要な日数を示します。以下に例を示します。

IndexItemAdd 要素では、重複する LeadTime 情報が ItemDetail (任意設定) と IndexItemDetail (必須) の両方から取得される場合があります。LeadTime 要素が両方で定義される場合は、その値を一致させる必要があります。IndexItemAdd のコンテキストでは、Extrinsic 要素は特定の品目に関する情報を拡張します。サプライヤは一意のItemID を使用して同じデータを取得できるため、OrderRequest 内ではこれらの拡張をサプライヤに転送する必要はありません。

IndexItemDetail

IndexItemDetail 要素には、LeadTime、ExpirationDate、EffectiveDate、SearchGroupData、またはTerritoryAvailable など、品目の特徴をさらに定義するインデックス固有の要素が含まれます。

PunchoutDetail

PunchoutDetail は、ItemDetail に似ていますが、必要なのは 1 つ以上の Description 要素と 1 つの Classification のみです。また、UnitPrice、UnitOfMeasure、URL、ManufacturerName、ManufacturerPartID、ExpirationDate、EffectiveDate、SearchGroupData、TerritoryAvailable、LeadTime、および Extrinsic 要素も含めることができます。価格値は概算です。ユーザーはサプライヤの Web サイトにパンチアウトして、現在の価格設定情報を取得できます。PunchoutDetail には次の属性があります。

属性説明
punchoutLevel購買アプリケーションでパンチアウト品目をどのようにユーザーに提示するかを指定します。この属性には、store (店舗レベル)、aisle (製品群レベル)、shelf (製品ラインナップレベル)、または product (製品レベル) の値を指定できます。購買アプリケーションでは、サプライヤによるタグ付けに応じて、これらの品目の表示方法が変更される場合があります。たとえば、店舗レベルの品目と製品レベルの品目をそれぞれ異なる方法で表示することができます。

上位レベルの製品カテゴリに対しては punchoutLevel=”aisle” を使用します。たとえば、コンピュータの付属品や電子部品が該当します。ユーザーがショッピング中に選択できる類似製品に対しては punchoutLevel=”shelf” を使用します。たとえば、複数の製造メーカーが類似製品を製造している場合や、1 つの製品に複数の構成がある場合に該当します。パンチアウトサイトページに単独で表示される固有の品目に対しては punchoutLevel=”product” を使用します。

16.2 型の定義

型を使用すると、型のプロバイダ (コンテンツアグリゲータ、サプライヤ、マーケットプレイスなど) でカタログ品目の標準定義を拡張し、商品分類固有の属性 (パラメータ型など) をグループ化した型を指定できます。型は、追加指定した属性の集合体になります。それぞれの属性は型に関して定義され、型の中にほかの型を含めることができます。型は、ほかの型から派生することも、ほかの型に拡張することもできます。型の定義には、補足的なカタログ属性とパラメータ型のデータ型が記述されます。これらはパラメータ型を定義するための高機能なフレームワークを提供し、インデックスデータとは別に、型プロバイダ組織からのパラメータ型の定義および標準化を可能にします。特定のカタログ品目に対して実際のパラメータデータを指定するには、SearchGroupData 要素およびSearchDataElement 要素を使用します。SearchGroupData は定義済みの型を参照する必要があります。また、SearchDataElement では、その型の中のそれぞれの型属性のデータを指定します。TypeDefinition ドキュメントには、TypeProvider 要素と、Type 要素または PrimitiveType 要素のいずれかが含まれます。

16.2.1 TypeProvider

TypeProvider には、定義する型プロバイダを指定します。型プロバイダは、名前と 1 つ以上の ID (NetworkId、DUNSなど) で識別されます。TypeProvider には次の属性があります。

属性説明
name (必須)型の名前を完全に記述する際に型プロバイダを参照するために使用される標準名 (たとえば、SearchGroupData 要素の参照で)。
16.2.1.1 Name

Name 要素の目的は、その地域で使用される名前を示すことです。地域情報ごとに異なる名前を定義することができます。

16.2.1.2 OrganizationID

型プロバイダ組織の一意の識別子です。

16.2.2 Type

Type 要素は、1 つ以上の TypeAttribute 要素を含む名前付き要素です。型はほかの型を拡張 (またはほかの型から派生) できるため、親の TypeAttribute 要素を継承します。型の継承と標準的なオブジェクト指向の継承モデルには、大きな違いが 1 つあります。TypeAttributes は親のTypeAttributes を上書きすることはできません。親の TypeAttribute と同じ名前の TypeAttribute を定義することはできません。Type には次の属性があります。

属性説明
name (必須)型の標準名です。
extends拡張する型の名前です。
16.2.2.1 Name

Type 名は常に TypeProvider 名によって範囲が限定され、複数の型分類法を存在させることができます。定義されたTypeProvider の範囲外では、アプリケーションは完全に記述された型名に対して次の表記法に従う必要があります。

たとえば、Acme という名前の組織が Pipes という名前の型定義を提供する場合、その型は、SearchGroupData 名では “Acme:Pipes” として参照されます。

16.2.2.2 説明

複数の地域情報での名前は、任意設定の Description 要素一覧を使って指定できます。型に対する地域情報ごとの別名を指定するには、その Description 内で ShortName 要素を使用する必要があります。特定の型を参照するには、必須の属性である name を SearchGroupData 要素内で使用する必要があります。

16.2.3 TypeAttribute

TypeAttribute 要素は、型の中の属性を定義します。name 属性は必須であり、SearchDataElement 要素で使用される名前を表します。任意設定の Name 要素は、この属性の地域固有の代案名を提供します。TypeAttribute 要素自体も “type” 属性で示されるように、名前付き型の 1 つです。この名前は、後述するPrimitiveType または別の Type にすることができます。

属性説明
name (必須)この属性の標準名を指定します。
type (必須)この属性のデータ型を指定します。使用可能な値は次のとおりです。
● integer – 整数 (小数点以下はなし)
● string – 文字の集合で、フリーテキスト検索のために個々にインデックスを付けられる語を含みます。
● literal – 文字の集合で、フリーテキスト検索のために個々にインデックスを付けられない語を含みます。
● double – 浮動小数点数。
● date – yyyy-mm-dd 形式の日付 (たとえば、2002-01-25)。
● boolean – ブール型の値 (yes、no、1、0、true、false、t、または f)。
shortTagこの属性のエイリアス。
mappedFromこの属性を暗黙に定義している、システム内の別のオブジェクトの名前を指定します。
isRequiredこの属性が、(空値以外の) 値を必要とするかどうかを示します。
isRequiredForOrdering属性の値が (通常は申請者によって) あらかじめ提示されていなければ、サプライヤに対するオーダーに品目を含めることができないことを示します。通常は、カタログ外品目または部分的に指定されたカタログ品目に対して使用します。
isRefinableこの属性が、検索クエリで絞り込み可能かどうかを示します。
isSearchableこの属性が、検索クエリで検索可能かどうかを示します。
isCollectionこの属性で、値の繰り返しが可能かどうかを示します。
isCaseSensitiveこの属性で、大文字と小文字の区別が保持されるかどうかを示します。このプロパティは、
string 型と literal 型の属性に対してのみ適用されます。数値型、ブール型、日付型の属性には影響しません。また、複合型の属性にも適用されません。
isInKeyこの属性が、型に対する一意なキーの一部かどうかを示します。
isInFreeTextSearchこの属性にインデックスを付けて、フリーテキスト (全文) クエリの候補にするかどうかを示します。
isHiddenこの属性をユーザーに表示するかどうかを示します。
isSortableこの属性が並べ替え可能かどうかを示します。
isReadOnlyこの属性に割り当てられた値が固定され、受け取るアプリケーションで変更不可能かどうかを示します。
unit必要に応じて、この属性の単位を指定します。たとえば、TypeAttribute が”integer” スカラ型を使用る,PrimitiveType である場合、この単位はインチを示す “IN” となる場合があります。
16.2.3.1 名称

TypeAttribute のローカライズされた名前です。

16.2.3.2 説明

TypeAttribute のローカライズされた説明です。

16.2.3.3 EnumerationValue

EnumerationValue を使用すると、TypeAttribute の有効なデータ値を 1 つ以上指定できます (任意設定)。

例:

16.2.3.4 Range

Range を使用すると、TypeAttribute に対して有効なデータ値の範囲を指定できます (任意設定)。RangeBegin、RangeEnd、あるいはその両方が含まれます。

例:

RangeBegin と RangeEnd のどちらに対しても、属性の inclusive=”no” を指定することができます (任意設定)。こ
の属性は、指定した開始値または終了値を有効な値から除外します。

16.2.4 PrimitiveType

PrimitiveType は名前付きスカラ型です。認識されるスカラ型の一覧は前述したとおりです。これらの型は、単純なTypeAttributes を定義するためのビルディングブロックです。たとえば、PrimitiveType を使用して、長さが 255の文字列の TypeAttribute を定義できます。PrimitiveType には次の任意設定の属性があります。

属性説明
name
(必須)
TypeAttribute の名前。
type
(必須)
スカラ型。指定可能な値は、”integer”、”string”、”literal”、”double”、”date”、および”boolean” です。
min“string” または “literal” の TypeAttribute の最小長。
max“string” または “literal” の TypeAttribute の最大長。
maxPrecisionscalarType “double” の TypeAttribute の最大精度。
maxScalescalarType “double” の TypeAttribute の最大スケール。

16.3 受信登録管理の定義

ネットワークハブなどの仲介組織は、購買システムで使用するサプライヤ情報とカタログを管理できます。この項では、サプライヤデータとカタログの管理に使用する Request/Response 要素について説明します。Request は、常に購買システムによって開始されます。この項では、次の内容について説明します。

  • サプライヤデータ [420 ページ]
  • サプライヤプロファイル情報 [423 ページ]
  • カタログの受信登録 [425 ページ]

16.3.1 サプライヤデータ

サプライヤデータ管理では、3 種類のトランザクションが使用されます。

  • SupplierList – バイヤーと取引関係があるサプライヤの名前を返します。
  • SupplierData – サプライヤの詳細情報を返します。
  • SupplierChange – 情報に変更があったサプライヤの名前を返します。
16.3.1.1 SupplierListRequest

SupplierListRequest は、バイヤーが取引関係を確立したサプライヤの一覧を要求します。

16.3.1.2 SupplierListResponse

SupplierListResponse は、バイヤーが取引関係を確立したサプライヤを一覧表示します。

16.3.1.3 SupplierDataRequest/h5>

SupplierDataRequest は、サプライヤに関するデータを要求します。

16.3.1.4 SupplierDataResponse

SupplierDataResponse には、サプライヤに関するデータが含まれます。

Supplier 要素の詳細については、「Supplier [411 ページ]」を参照してください。

16.3.1.5 SupplierChangeMessage

この要素を使用して、サプライヤデータの変更を通知します。このメッセージは、GetPending トランザクションを使用しています。バイヤー企業は、GetPendingRequest を送信して、受信待ちメッセージに関する問い合わせを行います。ネットワークハブ上に受信待ちメッセージがあれば、そのメッセージが GetPendingResponse に含められます。

16.3.2 サプライヤプロファイル情報

サプライヤプロファイル管理では、3 種類のトランザクションが使用されます。

  • OrganizationDataRequest – バイヤーと取引関係のあるサプライヤのプロファイル情報を要求します。
  • OrganizationDataResponse – サプライヤプロファイル情報を返します。
  • OrganizationChangeMessage – プロファイルが変更されたサプライヤのプロファイル情報を返します。
16.3.2.1 OrganizationDataRequest

OrganizationDataRequest は、バイヤーが取引関係を確立したサプライヤのプロファイル情報を要求します。

16.3.2.2 OrganizationDataResponse

OrganizationDataResponse は、バイヤーが取引関係を確立したサプライヤのプロファイル情報を返します。

16.3.2.3 OrganizationChangeMessage

OrganizationChangeMessage は、バイヤーが取引関係を確立したサプライヤの更新されたプロファイル情報を返します。

16.3.3 カタログ登録

カタログ登録管理では、4 種類のトランザクションが使用されます。

  • SubscriptionList – バイヤーが登録したカタログの名前を返します。
  • SubscriptionContent – カタログコンテンツを返します。
  • SubscriptionChange – 変更されたカタログの名前を返します。
  • SubscriptionStatusUpdateRequest – バイヤーからのカタログ登録状況を返します。
16.3.3.1 Subscription

すべてのカタログ受信登録トランザクションでは、Subscription 要素を使用してカタログ受信登録に関するメタデータを記述します。

例:

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

要素説明
InternalID
(必須)
仲介組織内の一意の ID。任意設定の domain 属性が含まれます。
Name
(必須)
受信登録の名前。
ChangeTime
(必須)
受信登録に関する任意の情報が最後に変更された日付と時刻。
SupplierID
(必須)
サプライヤの ID。
Formatカタログのフォーマット。
Descriptionカタログの説明。
16.3.3.2 SubscriptionListRequest

この要素は、バイヤーのカタログ受信登録の現在の一覧を要求します。

16.3.3.3 SubscriptionListResponse

この要素で、バイヤーが現在受信登録しているカタログを一覧表示します。

16.3.3.4 SubscriptionContentRequest

この要素は、登録済みのカタログのコンテンツを要求します。この要求には、カタログの InternalID およびSupplierID が含まれます。

は任意設定のパラメータです。このパラメータが提供された場合は、カタログの要求されたバージョン番号が取得されます。このパラメータが提供されない場合は、カタログの最新の利用可能なバージョンが取得されます。

16.3.3.5 SubscriptionContentResponse

この要素にはカタログのコンテンツが含まれます。カタログのフォーマットは、CIF (Catalog Interchange Format) または
cXML のいずれかを使用します。フォーマットが CIF の場合は、Base64 でエンコードされ、CIFContent 要素のコンテンツとして含められます。フォーマットが cXML の場合は、Index 要素が直接含められます。

16.3.3.6 SubscriptionChangeMessage

この要素は、登録済みのカタログが変更されたことをバイヤーの購買システムに通知します。このメッセージは、GetPending トランザクションに依存します。バイヤー企業は、GetPendingRequest を送信して警告メッセージをクエリします。ネットワークハブ上に受信待ちメッセージがあれば、そのメッセージが GetPendingResponse に含められます。詳細については、「待機データ確認/データダウンロードトランザクション [436ページ]」を参照してください。

type 属性は、次の変更の種類を示します。new、delete、または update。

16.3.3.7 SubscriptionStatusUpdateRequest

この要素は、カタログ受信登録の状況を要求します。これにより、バイヤー企業はネットワークハブを介してカタログ受信登録の状況をサプライヤに送信できるようになります。バイヤー企業のシステムでは、カタログは、ダウンロードされてから有効化されるまで、さまざまな状況に更新されている可能性があります。バイヤー企業のシステムにおけるカタログの各状況は、この要素を使用してサプライヤに送信することができます。ネットワークハブは、InternalID を使用してカタログ受信登録の状況を受信および更新します。

SubscriptionStatusUpdateRequest には、カタログの InternalID、SubscriptionVersion 要素、およびSubscriptionStatus 要素が含まれます。

SubscriptionVersion

この要素は、カタログのバージョン番号を格納します。サプライヤがカタログを編集すると、ネットワークハブはカタログの新しいバージョンを作成し、バージョン番号を割り当てます。このバージョン番号は、バイヤーからネットワークハブに送信されるすべてのメッセージで InternalID とともに使用されます。これは任意設定の属性です。定義されていない場合、ネットワークハブは InternalID としてカタログの最後に公開されたバージョンを使用します。

SubscriptionStatus

この要素は、カタログの状況を格納します。カタログの状況の値には、承認済み、却下済み、検証エラー、削除済み、受入済み、検証済み、有効化、無効化、および変更済みがあります。

16.4 カタログアップロードトランザクション

cXML のカタログアップロードトランザクションにより、サプライヤはネットワークハブ上へのカタログのアップロードと公開をプログラムを使用して実行できます。カタログアップロードトランザクションにより、ネットワークハブにログインして、カタログを対話的にアップロードし、公開することと同様の作業を実行することができます。この方法を使用すると、製品やサービスの価格や提供可能時期を変更する場合に、更新したカタログを自動的に配信できます。カタログアップロードトランザクションは、CIF カタログおよび cXML カタログの両方をサポートします。カタログアップロードトランザクションは、次の 2 つの cXML ドキュメントで構成されます。

  • CatalogUploadRequest: カタログをアップロードするためにサプライヤが送信します。このドキュメントには、添付ファイルとしてカタログが含まれており、それが新規のカタログか、更新するカタログか、およびアップロード後に自動的に公開するかどうかについて指定します。
  • Response: CatalogUploadRequest の受入を確認するためにネットワークハブによって送信されます。

16.4.1 CatalogUploadRequest

CatalogUploadRequest 要素には、カタログのアップロードに関連するすべての情報が含まれます。CatalogUploadRequest の例を次に示します。

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

属性説明
operation
(必須)
実行するアップロードの種類を指定します。使用可能な値は次のとおりです。
● new – 新しいカタログをアップロードします。同じ名前のカタログが存在してはなりません。
● update – 既存のカタログを上書きします。同じ名前のカタログが存在する必要があります。

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

CatalogName

CatalogName で、アップロードされたカタログ名を指定します。この名前は、ユーザーが見るカタログ名で、カタログのファイル名ではありません。CatalogName には次の属性があります。

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

Description では、カタログコンテンツを簡単に説明します。バイヤー企業は、この情報を検索、表示できます。Description には次の属性があります。

属性説明
xml:lang
(必須)
カタログ名に使用する言語を指定します。詳細については、前述した CatalogName の xml:lang の説明を参照してください。
type
(必須)
説明の条件。
Attachment

Attachment は、添付したカタログの URL を指定します。Attachment 要素には、スキーム「cid:」を含む URL 要素が 1 つ含まれています。添付ファイルの詳細については、「カタログの添付 [433 ページ]」を参照してください。

Commodities

Commodities では、カタログに含まれる品目の最上位レベルの商品分類コードを指定します。バイヤー企業はこのコードを使用して新規のカタログを検索します。Commodities 要素には、1 つ以上の CommodityCode 要素が含まれます。2 桁の UNSPSC (United Nations Standard Products and Services Code) セグメントコードを使用します。UNSPSC セグメントコードの一覧については、UNSPSC Web サイト (www.unspsc.org) を参照してください。

AutoPublish

AutoPublish は、アップロード後にカタログをバイヤーに自動的に公開します。カタログを自動的に公開するには、次の必要条件の両方を満たしている必要があります。

1. 前のバージョンのカタログがアカウントにあり、update 処理を実行していること。
2. 前のバージョンの状況が、「公開済み」であること。限定公開 (バイヤーのリストが存在すること)、または公開のいずれかで公開されている必要があります。

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

属性説明
enabled
(必須)
カタログを自動的に公開するかどうかを指定します。使用可能な値は次のとおりです。
● true — カタログを公開します。このカタログは、公開済みの前のカタログを更新するものでなければなりません。
● false — カタログを公開しません。アカウントにログインして、手動でカタログを公開できます。
Notification

Notification は、カタログ状況の通知を電子メールまたは cXML POST で送信します。これらのメッセージの例については、「後からのカタログ状況の受信 [434 ページ]」を参照してください。Notification には、1 つの Email 要素または 1 つの URLPost 要素のいずれか、または両方の要素が含まれます。Email は、ネットワークハブが状況メッセージを電子メール送信するメールボックスを指定します。Email 要素は 1 つだけ使用でき、この要素には電子メールアドレスを 1 つだけ含めることができます。URLPost は、ネットワークハブがカタログ状況メッセージを cXML の StatusUpdateRequest ドキュメントとして送信するかどうかを指定します。StatusUpdateRequest の URL 宛先は、Web サイトの ProfileRequest トランザクションへの応答によって決定されます。「プロファイルトランザクション [45 ページ]」を参照してください。URLPost には次の属性があります。

属性説明
enabled
(必須)
ネットワークが StatusUpdateRequest を介してカタログ状況通知を送信するかどうかを指定します。使用可能な値は次のとおりです。
● true — この機能を有効にします。
● false — この機能を無効にします。
16.4.1.1 カタログの添付

CatalogUploadRequest ドキュメントにカタログを添付して送信します。サイズの大きいカタログは、アップロードする前に ZIP 形式で圧縮する必要があります。

MIME エンベロープの使用

カタログファイルは MIME (Multipurpose Internet Mail Extensions) 添付ファイルとして CatalogUpdateRequest に含めます。cXML には、1 つのマルチパート MIME エンベロープで送信される外部 MIME パートへの参照のみが含まれます。参照されるカタログファイルは、cXML ドキュメントとともに、マルチパート MIME エンベロープに含める必要があります。このエンベロープに対する cXML の必要条件 (基本的な考え方は、RFC 2046 の「Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types」で規定されています) は、Content-ID ヘッダーを添付ファイルに含めることです。

注記
cXML 仕様では添付ファイルを MIME エンベロープの外部に置くこともできますが、カタログアップロードトランザクションではこの添付方法はサポートしていません。

Attachment 要素には、添付ファイルを含む別の MIME パートへの参照のみを定義します。Attachment には、スキーム「cid:」の 1 つの URL が含まれます。カタログファイルは、ZIP 形式で圧縮できます。

16.4.2 Response

CatalogUploadRequest を送信すると、ネットワークハブは、次のような標準の cXML Response ドキュメントで応答します。

16.4.2.1 後からのカタログ状況の受信

Notification 要素を含めてカタログ状況通知を後で要求する場合は、カタログが最終的な状況に達すると、ネットワークによってメッセージが送信されます。最終的なカタログ状況は次のいずれかになります。

  • Validated: カタログに構文エラーはありません。
  • BadZipFormat: zip 形式が正しくありません。
  • HasErrors: カタログに構文エラーがあるため、公開できません。
  • Published: カタログは公開済みです (限定公開版または公開版)。
16.4.2.2 URLPost

次の例は、ネットワークハブによって送信される StatusUpdateRequest 通知を示しています。

通知される状況コードは、次のとおりです。

状況コード意味
200 SuccessCatalogUploadRequest は正常に処理されました。
463 Bad Catalog FormatZIP ファイルが無効です。
470 Catalog Has Errorsメッセージが、カタログの状況を示しています。(HasErrors)