13. 後からの状況(ステータス)の変更

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 [190 ページ]」を参照) への応答と同様に、これらのどのトランザクションにも固有の Response 要素は含まれません。代わりに、返されるドキュメントには、ほぼ空の Response (Status のみ) が含まれます。返信される各ドキュメントのフォームは次のとおりです。

操作が正常に完了した場合にのみ “200” が返されます。

13.2 StatusUpdateRequest

このトランザクションは、オーダー、請求書、またはサービスシートの処理状況の変更について前のノードに通知します。特に重要な変更が 1 つあります。中間ハブは、ドキュメントを正常に転送した後、元の送信者または送信したハブに正常に転送できたという情報を通知することができます。サプライヤまたはハブで発生している待ち状況や処理状況も、バイヤー企業にとって意味がある場合があります。オーダー処理を支援するパートナー (FAX または EDI のサービスプロバイダなど) は、StatusUpdateRequest トランザクションメッセージをネットワークハブに送信して注文書状況を設定します。このトランザクションは、バイヤーとサプライヤの両方から参照可能な、ハブ上のオーダー状況指標に反映されます。さらに、サプライヤはこのトランザクションを送信して、バイヤー企業がサプライヤの組織内でドキュメント処理の状況を参照できるようにすることができます。バイヤー企業が StatusUpdateRequest を使用してネットワークハブ上の請求書の状況を更新すると、その情報がサプライヤに転送されます。StatusUpdateRequest は、1 つの OrderRequest ドキュメントの処理状況を更新します。

例:

この要求には、DocumentReference および Status 要素のみが含まれます。Status は、中間ハブで検出された最近の転送エラーを伝達できます。この要素のセマンティクスは、最初の HTTP 応答で OrderRequest ドキュメントに返された可能性がある Status と同じです。200/OK コードは、ドキュメントが保存され転送されたときに特に重要です。このコードは、サプライヤが OrderRequestの処理を開始したか、ハブがドキュメントを転送したことを示します。受領者には、200/OK を受信後にさらにStatusUpdateRequest ドキュメントが送られることはありません。StatusUpdate トランザクションを利用するサプライヤとハブは、OrderRequest が処理待ちのキューに入っている場合、201/Accepted コードを返する必要があります。200/OK を送信した後 (OrderRequest に対する即時のResponse や、その後の StatusUpdateRequest で) は、サーバーはこれ以上そのオーダーに対してStatusUpdate トランザクションを送信しません。その後の処理エラーによっては、このルールの例外が発生する場合があります。

13.2.1 DocumentReference

DocumentReference 要素は、状況の更新を特定の OrderRequest または InvoiceDetailRequest ドキュメントに関連付けます。この要素は、前回のドキュメントの必須属性を繰り返し、サプライヤで生成された任意設定の識別子を 1 つ追加します。

例:

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 ドキュメントでサプライヤにトランザクションの状況を返信します。

例:

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 ドキュメントを提供します。

action 属性は、このトランザクションの更新タイプを特定します。“approve”、“cancel”、または “deny” を指定できま
す。SourcingStatus 要素の本体には、RFQ の新しい状況に関する人間が判読可能な情報を含めることができます。

13.2.5 InvoiceStatus

請求書に StatusUpdateRequest を使用する場合は、InvoiceStatus 要素を含めます。

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

属性説明
type
(必須)
請求書に対してバイヤー企業が行う処理を示します。使用可能な値は次のとおりです。
● processing – 請求書がバイヤー企業によって受領され、処理中です。
● reconciled – 請求書が正常に照合されました。請求書の金額は未払いです。
● rejected – 請求書の照合に失敗しました。バイヤー企業は、請求書を却下しました。Comments 要素には、請求書を却下した理由を説明する自由形式のテキストと、サプライヤが行わなければならない処理を含める必要があります。その後、サプライヤは訂正した請求書 (新しい請求書番号を付けた新しい請求書) を再送信できます。
● paying – 請求書は支払に対して承認済みであり、支払処理中です。
● paid – 請求金額がバイヤー企業により支払済みです。
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 の例を示します。

以下に、オーダー確認の DocumentStatus の例を示します。

以下に、出荷通知の DocumentStatus の例を示します。Comments 要素には出荷通知に関する変更の提案が含まれます。コメントは情報目的のみであり、出荷通知には影響しません。

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 [132 ページ]」を参照してください。
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 の例を示します。

13.2.8 Extrinsic

Extrinsic 要素には、更新中のドキュメントの状況に関する追加情報を含めることができます。

13.3 ConfirmDtionRequest

このトランザクションは、特定のオーダー申請に関する詳細な状況の更新を提供します。このトランザクションでは、
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 要素を示しています。

複数の “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 要素から値を直接コピーする必要があります。
orderDateOrderRequest が作成された日時を指定します。この属性を使用する場合は、参照される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 の例を次に示します。

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 [113 ページ]」を参照してください。

13.3.2.4 Contact

Contact 要素は、主にオーダーについての新しい情報を追加するために使用します。OrderRequest ドキュメントからこの情報をコピーする必要はありません。
Contact role values には以下の属性が含まれます。

属性説明
technicalSupportテクニカルサポート
customerServiceカスタマサービス
sales販売部門
shipFromこのオーダーに関連する出荷の出発点
shipToOrderRequest ドキュメントからコピーした ShipTo 要素
payToこのオーダーの支払いの送信先
billToOrderRequest ドキュメントからコピーした BillTo 要素
supplierCorporate企業のサプライヤ
Contact一覧内の要素は任意の順序で指定できます。Contact role は、ConfirmationHeader 要素内で複数回使用することはできません。
13.3.2.5 Hazard

Hazard 一覧内の要素は任意の順序で指定できます。同じ Hazard を ConfirmationHeader 要素内の一覧に複数回含めることはできません。このレベルで一覧に含めた各 Hazard は、オーダー全体、または確認で指定したすべての品目に適用される必要があります。1 つの品目の状況を更新する ConfirmationRequest には、ConfirmationItem 要素の Hazard 要素を含めないでください。詳細については、「Hazard [331 ページ]」を参照してください。

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 の作成者。
DescriptionIdReference の人間が解読可能なテキスト記述。
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 [331 ページ]」を参照してください。

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 [113 ページ]」を参照してください。
次の例は、Modification 要素を示しています。

すべての部分を差し替えなくても、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 の詳細のいずれかを入力します。
SupplierBatchID1 回の生産実行で生産される品目/商品を識別するためのサプライヤからの ID。「SupplierBatchID または Batch [332 ページ]」を参照してください。
ScheduleLineReference確認の納入日程行に関連するすべての参照を定義します。「ScheduleLineReference [308 ページ]」を参照してください。
ComponentConsumptionDetails最終製品の製造における構成品目の消費に関する詳細情報が含まれます。「ComponentConsumptionDetails [472 ページ]」を参照してください。
Comments確認の状況に関連するコメントが含まれます。”backordered”、”shipped”, および “invalid” などの用語を使用すると実用的です。こうしたデータは、ユーザーが使用することを目的としています。
Extrinsicアプリケーションで使用するこの確認の状況に関連する追加情報が含まれます。これらの要素には、受信側のシステムのワークフローに影響する、事前定義されたキーワードや値を組み込むことができます。
Extrinsic 一覧内の要素は任意の順序で指定できます。エクストリンジック属性値は、ConfirmationStatus 要素内で複数回使用しないでください。この一覧と全体の ConfirmationHeader 要素の両方で同じタイプを指定ないでください。ConfirmationHeader には、この下位レベルで上書きされた通常設定のエクストリンジック値を含めないでください。

サービス明細に関する ConfirmationStatus の例を次に示します。

13.3.3.3.1 ScheduleLineReference

確認の納入日程行に関連するすべての参照を定義します。
ScheduleLineReference には次の属性があります。

属性説明
quantity
(必須)
現在のドキュメントによって参照される、OrderRequest ドキュメントの ScheduleLine 要素からの数量。
requestedDeliveryDate
(必須)
現在のドキュメントによって参照される、OrderRequest ドキュメントの ScheduleLine 要素からの納品予定日。
lineNumber現在のドキュメントによって参照される、OrderRequest ドキュメントの ScheduleLine 要素からの明細の識別子。

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

要素説明
Extrinsicこの ScheduleLineReference に関連する追加情報が含まれます。

ScheduleLineReference の例を次に示します。

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 要素の使用方法を示したものです。

13.4.2 OrderStatusRequestItem

OrderStatusRequestItem 要素は、特定の明細に関する情報を格納します。この要素には、次の属性があります。

属性説明
rescheduleRequest配達日に対して可能な変更を提案する資材所要量計画 (MRP) に基づく情報です。使用可能な値は次のとおりです。
● in – 配達日を現在の配達日よりも前に再スケジュールする MRP 提案。
● out – 配達日を現在の配達日よりも後に再スケジュールする MRP 提案。
● cancel – 注文書明細をキャンセルする MRP 提案。
rescheduleDateMRP 提案で再スケジュールされた配達日。

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

要素説明
ItemReference明細に関連するすべての参照を定義します。「ItemReference [311 ページ]」を参照してください。
Commentsこの明細に関連付けられたすべての追加コメントが含まれます。
Priorityサプライヤのオーダーの優先度を上げるために使用される優先度区分です。注文書明細に関連付けられた現在のビルドの優先順位を示します。この値では、注文書の優先度は更新されません。

以下は、OrderStatusRequestItem 要素の例を示したものです。

13.4.2.1 ItemReference

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

要素説明
ItemIDOrderStatusRequest における明細の品目 ID。
IDReferenceOrderStatusRequest における明細の品番への一意の参照。
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 要素には、含まれるすべての明細に共通の出荷通知に関する情報が含まれます。この情報は、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 [315 ページ]」を参照してください。これによって、出荷通知の複数のバージョンが効率的に順序付けられます。
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” を指定する場合は、出荷予定日を入力する必要があります。以下に例を示します。

fulfillmentTypeこの出荷通知が作成される完了の種類。利用可能な値は、すべての品目が出荷されない場合は “partial”、オーダー全体が出荷される場合は “complete” です。
requestedDeliveryDate目的の配達日を指定します。多くの場合、バイヤーが商品の受領を希望する日付 (または期間)が反映できます。以下に例を示します。

reason出荷通知の理由。使用できる唯一の値は “return” です。これは、出荷に何らかの理由でバイヤーからサプライヤに返品される品目が含まれていることを意味します。たとえば、品目が損傷しているか不具合がある可能性があります。
13.5.1.1 ServiceLevel

サービスレベルコードを言語固有の文字列で指定します。operation=”delete” が指定されている場合を除き、すべての ShipNoticeRequest ドキュメントで 1 つまたは複数の ServiceLevel 要素を使用する必要があります。各ServiceLevel には、この出荷の運送業者から提供されるサービスのレベルに対応した単一文字列 (“overnight”など) を含める必要があります。複数の ServiceLevel 要素を使用する場合は、すべての要素に対して異なる言語または地域情報で同じレベルのサービスを記述する必要があります。2 つの ServiceLevel 要素に同じ xml:lang 属性を含めることはできません。このような一覧内の要素に順序の制限はありません。
必須の属性 xml:lang. が含まれます。詳細については、「xmlLangCode [42 ページ]」を参照してください。

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 [331 ページ]」を参照してください。

13.5.1.7 Comments

出荷に関する追加情報を含めるには、Comments 要素を使用します。ShipNoticeHeader 要素では、その情報は、含まれるすべての明細とルートに共通している必要があります。そうしたすべてのデータは、ユーザーが使用することを目的としています。
最大で 3 つの Comments 要素を指定して、出荷通知に以下の追加情報を指定できます。

● 出荷の理由を指定します。
● 運送方向を指定します。
● 出荷の追加情報。

「IdReference [318 ページ]」の例を参照してください。

13.5.1.8 TermsOfTransport

商品の輸送に関する出荷条件を指定します。
次の例は、TermsOfTransport 要素を示しています。

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

SealID

シールの一意の ID を指定します。シールは、輸送または貨物出荷の整合性を維持するために使用されます。シールにはさまざまな形式ありますが、1 つの共通特性 (オーナーまたは責任者によって指定された一意の ID) を共有します。SealID は、輸送中のコンテナ、トラック、船舶、またはそのほかの貨物のプロパティを国外で追跡するために使用されます。

SealingPartyCode

SealID を割り当てたパーティの会社コードを指定します。このパーティは通常、商品のオーナーまたは貨物を積載した運送業者になります。

EquipmentIdentificationCode

装置識別符号を指定します。これは、主に国内輸送および保管目的で使用されます。梱包装置には、移動と保管場所を監視および管理するための一意の符号が付けられます。この符号は一時的または永続的にすることができます。

TransportTerms

TransportTerms の詳細については、「TermsOfDelivery [129 ページ]」を参照してください。

Dimension

品目の梱包に対して単一の次元を指定します。「次元 [182 ページ]」を参照してください。

Extrinsic

TermsOfTransport 要素の Extrinsic。

13.5.1.9 TermsofDelivery

TermsofDelivery 要素を ShipNoticeHeader 要素に追加して、ヘッダーレベルで配達条件を指定することができます。詳細については、「TermsOfDelivery [129 ページ]」を参照してください。

13.5.1.10 Packaging

詳細については、「Packaging [179 ページ]」を参照してください。

13.5.1.11 Extrinsic

また、Extrinsic 要素の一覧を使用して、アプリケーションで使用する出荷に関する追加データを挿入します。これらの要素には、受信側のシステムのワークフローに影響する、事前定義されたキーワードや値を組み込むことができます。Extrinsic 一覧内の要素は任意の順序で指定できます。Extrinsic タイプ、Extrinsicname 属性値は、ShipNoticeHeader 要素内で複数回使用しないでください。この一覧と特定の ShipControl またはShipNoticePortion 要素の両方で、このタイプを指定しないでください。ShipNoticeHeader には、いずれかの下位レベルで上書きされた通常設定のエクストリンジック値を含めないでください。

13.5.1.12 IdReference

政府発行の出荷 ID、ドキュメント名、およびサプライヤ参照番号を指定します。

例:

13.5.1.13 ReferenceDocumentInfo

追加のドキュメント参照情報が含まれます。「ReferenceDocumentInfo [132 ページ]」を参照してください。

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 要素の使用は、運送業者に関する追加詳細を伝えなければならない場合のために予約しておく必要があります。
SCACStandard Carrier Alpha Code。www.nmfta.org/pages/scac
IATAInternational Air Transport Association。www.iata.org
AARAssociation of American Railroads。www.aar.org
UICInternational Union of Railways。www.uic.org
EANEuropean Article Numbering。upc-ean-information.com
DUNSDun 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 を示します。

次の例は、トラッキング番号と関連して出荷を追加するために使用される trackingURL を指定する ShipmentIdentifier を示します。

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 [116 ページ]」を参照してください。

13.5.2.6 Contact

この要素で最も一般的な Contact role を次に示します。

説明
carrierCorporate運送業者の組織に関して、サプライヤが把握している連絡先情報の詳細を記述します。
shipFromrole が “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 要素から値を直接コピーする必要があります。
orderDateOrderRequest が作成された日時を指定します。日付形式は、国際 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 – 出荷通知明細が会社間在庫転送オーダーに対して作成されたことを特定します。
outboundTypestockTransport に設定して、在庫転送オーダーに対して配達が作成される必要があることを示します。

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

要素説明
ItemID品目の一意の ID が指定されます。「ItemID [90 ページ]」を参照してください。
ShipNoticeItemDetail品目に関する詳細情報が含まれます。「ShipNoticeItemDetail [329 ページ]」を参照してください。
UnitOfMeasure製品を梱包または出荷する方法が記述されます。「UnitOfMeasure [43 ページ]」を参照してください。
Packaging各品目は、複数のボックスに梱包することができます。したがって、品目レベルのPackaging 要素は、その品目に属する複数のパッケージに対応する可能性があります。「Packaging [179 ページ]」を参照してください。
Hazard品目および出荷全体に固有の、危険性についての説明と任意設定のコードを提供します。「Hazard [331 ページ]」を参照してください。
Batch | SupplierBatchID商品のバッチを識別します。「SupplierBatchID または Batch [332 ページ]」を参照してください。
AssetInfo商品の出荷における個別の品目に対して資産管理番号またはシリアル番号を提供します。「AssetInfo [332 ページ]」を参照してください。
TermsOfDelivery品目レベルで配達条件を指定します。「TermsOfDelivery [129 ページ]」を参照してください。
OrderedQuantity注文書の特定の明細に対して品目/製品の数を指定します。「OrderedQuantity [183 ページ]」を参照してください。
ShipNoticeItemIndustry業界固有フィールドのグループが含まれます。「ShipNoticeItemIndustry [333 ページ]」を参照してください。
ComponentConsumptionDetails最終製品の製造における構成品目の消費に関する詳細情報が含まれます。「ComponentConsumptionDetails [472 ページ]」を参照してください。
ReferenceDocumentInfo追加のドキュメント参照情報が含まれます。「ReferenceDocumentInfo [132 ページ]」を参照してください。
Comments出荷通知明細固有のコメントが含まれます。OrderRequest で要求された品質証明書を添付するために使用できます。この場合、コメントは添付ファイルによって提供され、証明書の種類は Comments@type 属性によって提供されます。
Extrinsicこの出荷通知明細の追加情報が含まれます。

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

これは、配達を使用する「社内」在庫転送の別の ShipNoticeItem です。

13.5.3.7.1 ShipNoticeItemDetail

この要素には、品目に関する詳細情報が含まれます。出荷通知における品目の詳細は、参照される注文書から継承されます。注文書を参照しない出荷通知の場合、この要素から品目の詳細を取得できます。

ShipNoticeItemDetail の例:

UnitPrice

品目の単位あたりの価格。割引による変更など、任意の変更が提供されます。

Description

品目の簡単な説明。

UnitOfMeasure

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

PriceBasisQuantity

UnitPrice の基準となる数量を定義します。「PriceBasisQuantity [356 ページ]」を参照してください。

Classification

類似するカテゴリのグループです。

ManufacturerPartID

品目の製造メーカーが品目を識別する ID です。

ManufacturerName

品目の製造メーカー名です。

Dimension

品目の次元です。「Dimension [182 ページ]」を参照してください。

ItemDetailIndustry

業種別品目の詳細情報です。「ItemDetailIndustry [141 ページ]」を参照してください。

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 値が予測されます。

説明
UNDGUnited Nations Dangerous Goods
IMDGInternational Marine Organization Dangerous Goods
NAHGNorth American Hazardous Goods
13.5.3.7.3 SupplierBatchID または Batch

任意設定の SupplierBatchID または Batch 要素を指定して、商品のバッチを識別できます。
SupplierBatchID は、同時に作成または製造された商品のバッチ番号 (“ロット番号” または “バリアント” とも呼ばれます) を指定します。たとえば、サプライヤはバッチ番号をコンピュータのハードドライブに割り当てることができます。
Batch は、1 回の生産実行で生産される品目または商品のバッチ情報を指定します。「Batch [184 ページ]」を参照してください。

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 [183 ページ]」を参照してください。
PromotionDealID販売促進活動に関連するサプライヤによって割り当てられる ID が指定されます。販売促進は将来の計画やオーダープロセス (および関連価格) に影響します。
PromotionVariantID商品の 1 つまたはいくつかのバリアントのみが推奨される場合に、特定の ID が指定されます。製品バリアントは、製品の特性 (色や形状など) を指定する特定のコードです。
13.5.3.8 ReferenceDocumentInfo

追加のドキュメント参照情報が含まれます。「ReferenceDocumentInfo [132 ページ]」を参照してください。

13.6 ReceiptRequest

ReceiptRequest は、バイヤー企業からサプライヤに送信された注文書または主契約に対する受領書の詳細を表します。1 つまたは複数の注文書の全明細または選択された明細の任意の部分を対象にこれを使用できます。

注記
このトランザクションの DTD は、cXML.dtd ではなく、Fulfill.dtd に含まれます。

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

要素説明
ReceiptRequestHeader
(必須)
この受領書のヘッダー情報が含まれます。「ReceiptRequestHeader [335 ページ]」を参照してください。
ReceiptOrder
(必須)
注文書または主契約に関連する情報を定義します。「ReceiptOrder [336 ページ]」を参照してください。
Total
(必須)
すべての受領書明細金額の合計金額です。

ReceiptRequest の例を次に示します。

13.6.1 ReceiptRequestHeader

ReceiptRequestHeader には、この受領書のヘッダー情報が含まれます。この要素には、次の属性があります。

属性説明
receiptID
(必須)
バイヤーがこの受領書に対して生成した一意の識別子。
receiptDate
(必須)
バイヤー企業が品目またはサービスを受け入れた日時。この日時はドキュメントのタイムスタンプよりも前である必要があります。
operationこの receipt ドキュメントで記述される処理。使用可能な値は、”new” (通常設定) と、DocumentReference 要素で指定された既存の受領書をキャンセルする”delete” です。”delete” 操作は、構成品目受領書でのみサポートされます。

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

要素説明
DocumentReference以前の ReceiptRequest への参照。属性ReceiptRequestHeader@operation が “delete” である場合は、DocumentReference 要素が必要となり、この要素は同じ受領書プロセスで元のReceiptRequest ドキュメントを参照する必要があります。
ShipNoticeIDInfoバイヤーの入庫の受領書が含まれます。通常の設定は、サプライヤの出荷通知 ID になります。
Commentsこのオブジェクトに関連するコメントが含まれます。
Extrinsicこのオブジェクトに関連するすべての追加情報が含まれます。

以下の例は、ShipNoticeIDInfo を含む ReceiptRequestHeader を示します。

以下の例は、構成品目受領書をキャンセルする方法を示します。

13.6.2 ReceiptOrder

ReceiptOrder は、注文書または主契約に関連する情報を定義します。ReceiptRequest ドキュメントには、複数のReceiptOrder 要素が含まれることがあります。ReceiptOrder には次の属性があります。

属性説明
closeForReceivingyes に設定して、この受領書の承認時に、基となるオーダーまたは主契約を終了し、今後の受け入れを不可とするかを指定します。

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

要素説明
ReceiptOrderInfo
(必須)
注文書または主契約の参照情報が含まれます。「ReceiptOrderInfo [336 ページ]」を参照してください。
ReceiptItem
(必須)
注文書または主契約からの情報を使用して、受領書明細を定義します。「ReceiptItem[336 ページ]」を参照してください。
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 だけで
あったことが判明したので、負の数による受入処理を実行して、この間違いを修正することができます。

typeバイヤーが、サプライヤからの品目を受け入れたのか、または返品したのかを示します。この属性に対して次の値を指定できます。
● received: バイヤーが商品を受け入れたことを示します。
例:
● returned: バイヤーが商品を返品したことを示します。
例:
parentReceiptLineNumber受領申請の親明細の明細番号。
itemType品目の種類を指定します。使用可能な値は次のとおりです。
● composite – 品目グループを識別します。
● item – 独立した明細を識別します。
● lean – 明細で予定されている子品目がないことを示します。
compositeItemType親品目でグループごとの価格設定が使用されるかどうかを指定します。使用可能な値は”groupLevel” または “itemLevel” です。
completedIndicator“yes” に設定すると、構成品目出荷通知明細が終了とみなされ、構成品目受領はこれ以降行われなくなります。

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

要素説明
ReceiptItemReference
(必須)
参照される明細の明細番号を示します。「ReceiptItemReference [339 ページ]」を参照してください。
UnitRate
(必須)
指定数量単位当たりの支払額。
ReceivedAmount
(必須)
受領書明細の受入済み商品またはサービスの金額です。受入済み金額の合計は、quantity と UnitRate の積に等しくなる必要があります。
AssetInfo各受領書明細の数量ごとの任意設定の資産データが含まれます。
DeliveryAddress商品が受領される住所。
Commentsこのオブジェクトに関連するコメントが含まれます。
Batch1 回の生産実行で生産される品目または商品のバッチ情報を含む要素。
Classification受領書の分類。たとえば、受領書明細移動の種類または在庫の種類。複数の分類をサポートするために複数回使用できます。
Extrinsicこのオブジェクトに関連するすべての追加情報が含まれます。

ReceiptItem の例を次に示します。

13.6.2.2.1 ReceiptItemReference

参照される明細の明細番号を示します。ReceiptItemReference には次の属性があります。

属性説明
lineNumber
(必須)
OrderRequest ドキュメントからコピーされた現在の明細の明細番号です。この明細番号は、ShipNoticeReference によって参照される構成品目出荷通知の明細を参照することもできます。

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

要素説明
ItemIDOrderRequest ドキュメントからコピーされた現在の明細のサプライヤ品番です。
DescriptionOrderRequest ドキュメントからコピーされた明細の説明です。
ManufacturerPartID製造メーカーの品番です。
ManufacturerName製造メーカーの名前です。
ShipNoticeReferenceこの品目が出荷されたときにサプライヤから送信された ShipNoticeRequest ドキュメントへの参照です。
ShipNoticeIDInfoバイヤーシステムで認識される ShipNoticeRequest の ID です。この ID はShipNoticeReference を省略する際に使用されます。
ShipNoticeLineItemReference前の ShipNoticeRequest ドキュメントの明細への参照です。
ReferenceDocumentInfo追加のドキュメント参照情報が含まれます。「ReferenceDocumentInfo [132 ページ]」を参照してください。