顧客

販売パートナーやディストリビュータの顧客を表すエンティティ。

JSON 表現 

{
  "name": string,
  "orgName": string,
  "postalAddress": {
    object(PostalAddress)
  },
  "primaryContactName": string,
  "primaryContactEmail": string,
  "primaryContactTitle": string,
  "primaryContactPhone": string,
  "createTime": string,
  "updateTime": string,
  "alternateEmail": string
}
フィールド
name

string

顧客のリソース名。形式は "accounts/{account_id}/customers/{customer_id} で、読み取り専用です。

orgName

string

顧客エンティティの組織の名前。

postalAddress

object(PostalAddress)

顧客エンティティの組織の住所。米国の法律や禁輸措置を適用するには、地域コードと郵便番号が必要です。

primaryContactName

string

顧客アカウントのメインの連絡先の詳細情報。

primaryContactEmail

string
primaryContactTitle

string
primaryContactPhone

string
createTime

string（Timestamp 形式）

読み取り専用。

RFC3339 UTC 「ズールー」形式でナノ秒の精度のタイムスタンプ。例: "2014-10-02T15:01:23.045123456Z"
updateTime

string（Timestamp 形式）

RFC3339 UTC「ズールー」形式でナノ秒の精度のタイムスタンプ。例: "2014-10-02T15:01:23.045123456Z"

alternateEmail

string

予備の連絡先メールアドレス。

PostalAddress

郵便配達や支払いの住所などの住所を表します。住所を指定すると、郵便サービスは、アイテムを施設、私書箱などに配達することができます。地理的な場所（道路、町、山）をモデル化することを意図していません。

一般的な使い方で、住所はプロセスのタイプに応じて、ユーザー入力または既存のデータのインポートによって作成されます。

住所の入力や編集に関するアドバイス: i18n 対応の住所ウィジェット（たとえば https://github.com/google/libaddressinput）を使用します。ユーザーが住所を入力または編集するときに、その国にはない項目の UI 要素が提示されることがないようにしてください。

このスキーマの使用方法の詳細については、https://support.google.com/business/answer/6397478 をご覧ください。

JSON 表現 

{
  "revision": number,
  "regionCode": string,
  "languageCode": string,
  "postalCode": string,
  "sortingCode": string,
  "administrativeArea": string,
  "locality": string,
  "sublocality": string,
  "addressLines": [
    string
  ],
  "recipients": [
    string
  ],
  "organization": string
}
項目
revision

number

PostalAddress のスキーマ リビジョン。これは、最新のリビジョンである 0 に設定する必要があります。

新しいリビジョンはすべて、古いリビジョンと下位互換性があることが必要です。
regionCode

string

必須。住所の国 / 地域に対応する CLDR 地域コード。これは推測されず、値が正しいことを確認するのはユーザー次第です。詳細については、http://cldr.unicode.org/ と http://www.unicode.org/cldr/charts/30/supplemental/territory_information.html をご覧ください。例: スイスの場合は「CH」。

languageCode

string

省略可。この住所の内容の BCP-47 言語コード（分かっている場合）。これは、入力フォームの UI 言語であることが多く、住所の国/リージョンで使用されている言語のいずれか、またはそれらの文字変換された同等語と一致することが期待されます。これは、特定の国の書式設定に影響する可能性がありますが、データの正確性には重要ではなく、検証やその他の書式設定関連でないオペレーションに影響しません。

この値が不明な場合は、省略してください（正しくない可能性のあるデフォルトを指定するのではなく）。

例: 「zh-Hant」、「ja」、「ja-Latn」、「en」。
postalCode

string

省略可。住所の郵便番号。すべての国で郵便番号の使用や存在を必要としているわけではありませんが、使用されている場合は、住所の他の部分で追加の確認が行われることがあります（例: 米国での州 / 郵便番号の確認）。

sortingCode

string

省略可。追加の国固有の並べ替えコード。ほとんどの地域では、これは使用されていません。使用される場合、値は「CEDEX」のような文字列で、その後に必要に応じて数字を付けたもの（例: 「CEDEX 7」）や、数字だけのものがあります。たとえば、ジャマイカの「セクターコード」、マラウイの「配達区域インジケータ」、コートジボワールの「郵便局インジケータ」などです。

administrativeArea

string

省略可。国または地域の住所に使用される最高の行政下位地域区分。たとえば、州、省、都道府県などがあります。具体的には、スペインの場合、これは自治州ではなく、県になります（例:「カタルーニャ」ではなく、「バルセロナ」）。州や県などの行政区画が住所表記に使用されない国もあります。たとえば、スイスではこれは未入力のままする必要があります。

locality

string

省略可。一般的に住所の市町村部分を指します。たとえば、米国の市、イタリアのコムーネ、英国のポスト町。地域区分が適切に定義されていない地域や、この構造にうまく適合しない世界の地域では、locality を空のままにして addressLines を使用します。

sublocality

string

省略可。住所の市町村部分の下位の区画。たとえば、町、区、地区などがあります。

addressLines[]

string

住所の下位部分を記述する非構造化の住所行。

addressLines の値は型情報を持たず、単一の項目に複数の値を含めることがあるため（例: 「Austin, TX」）、行の順序が明確であることが重要です。住所行の順序は、その住所の国 / 地域の「封筒順」であることが必要です。これが一定ではない可能性のある場所（たとえば日本）では、address_language を使用して明示的に指定します（例: 大から小の順序の場合は「ja」、小から大の場合は「ja-Latn」または「en」）。このように、住所の最も詳細な部分の行を言語に基づいて選択できます。

住所の最小許容構造化表現は、addressCode と addressLines に残りのすべての情報が格納されて構成されます。そのような住所を、ジオコーディングなしできわめて正確に近く書式設定することも可能ですが、住所の構成要素についての意味的な推論は、少なくとも部分的に解決されるまでは不可能です。

構造化されていない住所を完全に処理するためには、regionCode と addressLines のみを含むアドレス住所を作成してからジオコーディングを行うことをおすすめします（住所のどの部分が地域区分であるか、行政区域であるかを推測するのではなく）。
recipients[]

string

省略可。その住所で受け取る人。この項目は、状況によって複数の情報を含むことがあります。たとえば、「様方」情報が含まれる場合があります。

organization

string

省略可。その住所にある組織の名前。