DOCS

Classification readiness

Classification readiness

HS コードをリクエストする前に、品目の情報が分類に十分詳細かどうかを確認します。

GraphQL

customsDescriptionValidate mutation は、分類を実行する 前に、品目の情報が 6 桁の HS コード を自信を持って割り当てるのに十分かどうかを確認します。readiness ステータスを返し、お客様独自のポリシーを適用できます — 分類に進む、警告する、購入者または販売者により詳細を求める、品目を拒否する。

これはプレフライトチェックであり、分類ではありません。customsDescriptionValidate は品目を分類せず、HS コードも返しません。最終的に Classify に送信する説明が、正確で前提のない結果を生み出すよう、最初から薄いまたは使用不能な説明をキャッチするために使用してください。

readiness チェックは用途の一つに過ぎません。同じ品目データが Zonos の customs description および classification サービスを駆動するため、この mutation はより広範な Customs Description ワークフローのエントリーポイントです — データ品質をゲートし、品目からコンプライアンスに準拠した customs description を生成します。分類ゲート以上の機能 については以下をご覧ください。

Readiness ステータス 

各検証は 1 つの status を返します。ステータスは助言的であり、統合側が各値の結果を決定します。

StatusMeaningSuggested action
READY情報は前提なしで 6 桁の HS コードを自信を持って割り当てるのに十分です。分類に進みます。
INCOMPLETE品目は識別可能ですが、決定的な属性が欠落しているため、分類は前提に依存します。missingAttributes で指定された属性を求め、再試行します。
UNRECOGNIZABLEテキストは品目が本質的に何であるかを確立していません — 空の値、SKU または内部コードのみ、または意味不明な文字列。ユーザーに品目の再入力を求めます。

ステータスが INCOMPLETE の場合、missingAttributes フィールドは欠落している属性を短いフレーズ(例: "fiber content" または "material, construction")で返し、ユーザー向けメッセージの作成に適しています。他のステータスでは null です。

API 経由で品目を検証 

品目フィールドを直接提供します — 少なくとも 1 つの説明フィールドが必要です。以下の例では、名前と説明が t-shirt として識別されるが分類に必要な fiber content が省略されている品目を検証し、mutation は INCOMPLETE を返します。

1mutation CustomsDescriptionValidate(
2$input: CustomsDescriptionValidationInput!
3) {
4 customsDescriptionValidate(input: $input) {
5 id
6 status
7 missingAttributes
8 content {
9 name
10 description
11 material
12 categories
13 existingItemId
14 }
15 createdAt
16 }
17}

入力フィールド

FieldTypeDescription
nameString品目の名前。
descriptionString品目の人間が読める説明。
materialString品目の素材または構成(既知の場合)。例: "55% cotton, 45% polyester"
categories[String!]品目に関連付けられ説明するカテゴリ。
existingItemIdID検証する既存 Item の ID。提供された場合、保存された品目のフィールドが使用され、ここで提供されたフィールドは保存された値を上書きします。

existingItemId または品目フィールドを直接提供してください — 少なくとも 1 つの説明フィールドが必要です。

既存品目の検証 

品目が Zonos に既に存在する場合、すべてのフィールドを再送信する代わりに ID を existingItemId として渡します。保存された品目のフィールドが検証の基礎として使用され、同じ入力で提供されたフィールドは保存された値を上書きします — 編集が薄い品目を classification-ready にするかどうかをテストするのに便利です。

レスポンスの content は検証された品目データをエコーバックし、existingItemId が解決されるため、保存された各 CustomsDescriptionValidation は自己記述的です。

分類ゲート以上の機能 

readiness ステータスは助言的であるため、同じチェックは複数のワークフローに供給されます — 分類するかどうかを決めることだけではありません。customsDescriptionValidate は Zonos の classification および customs description サービスが消費する同じ品目データを評価するため、より広範な Customs Description ワークフローの自然な最初のステップとなります。

  • データ品質ゲート — PIM、カタログインポート、チェックアウトの入力時点で薄いまたは使用不能な品目情報を表面化し、missingAttributes を使用して不足している内容を正確に求め、そのデータが下流に流れる前に対処します。
  • Customs description の生成 — 品目が READY になったら、同じデータを customsDescriptionsCreate mutation に渡し、Zonos に品目から簡潔で通関および ICS2 に準拠した customs description を生成させます — 同じ呼び出しで HS コードをリクエストすることもできます。最初に readiness を検証することで、生成された説明は前提ではなく完全な情報から構築されます。
  • 自信を持って Classify — 説明が 6 桁の HS コードを推測なしで正確に割り当てるのに十分詳細であることを確認して Classify に進みます。

典型的なエンドツーエンドのフローは次のとおりです: readiness を検証 → missingAttributes を収集 → コンプライアンスに準拠した customs description(および HS コード)を生成 → 分類または申告。

GraphQL API ReferenceTypes, inputs, and operations used in this guide

このページは役に立ちましたか?