顧客マスタと共通設定

顧客は TCA（Trading Community Architecture）で管理します。**パーティ（法人・個人）→ 顧客アカウント（取引条件）→ アカウントサイト → サイト用途（Bill-To など）**の階層で、取引には請求先（Bill-To）用途が必須です
顧客の取引条件の多く（支払条件、明細書サイクル、AutoCash ルールセット、送付方法、残高繰越請求など）は顧客プロファイルに持たせ、プロファイルクラスで既定値を配ります
共通設定の中心は システムオプション（BU 単位）、Receivables 活動、AutoAccounting、取引タイプ、取引ソース、支払条件 です。取引タイプはクレジットメモ用から作ります
顧客の移行は FBDI の Customer Import（Import Trading Community Data in Bulk）で行います

全体像

共通設定と顧客マスタの関係は次のとおりです。

システムオプション（BU）
  └─ 取引・入金の既定動作、丸め、割引、メール送付など
参照データセット（Common または BU 固有）
  └─ 取引タイプ・取引ソース・支払条件・送付先住所・メモ明細・AutoCash ルールセット など
顧客（TCA）
  └─ パーティ → 顧客アカウント → アカウントサイト（BU 固有のセット）→ サイト用途
        └─ 顧客プロファイル（プロファイルクラスから既定値）

顧客マスタ（TCA の構造）

TCA は、法的な主体（パーティ）と、商取引の関係（顧客アカウント）と、所在地（サイト）を分けて管理します。

パーティ（組織または個人）
├─ パーティサイト（所在地） ─ ロケーション（住所）
├─ パーティ関係（子会社・関連会社など）
├─ 連絡先
└─ 顧客アカウント（取引条件）
     ├─ アカウント連絡先
     ├─ アカウントサイト（このアカウントで使うパーティサイト）
     │    └─ サイト用途（Bill-To、Ship-To など）
     └─ アカウント関係（請求・出荷・支払情報の共有）

オブジェクト	意味	主なテーブル
パーティ（Party）	取引の相手となる組織・個人。関係が切れても存在し続ける	HZ_PARTIES
パーティサイト・ロケーション	パーティの所在地と住所	HZ_PARTY_SITES、HZ_LOCATIONS
顧客アカウント（Customer Account）	取引条件の単位。1 パーティに複数持てる	HZ_CUST_ACCOUNTS
アカウントサイト（Account Site）	アカウントで使う所在地	HZ_CUST_ACCT_SITES_ALL
サイト用途（Site Use）	請求先・出荷先などの目的	HZ_CUST_SITE_USES_ALL

設計のポイントは次のとおりです。

アカウントを分ける基準：取引条件（支払条件・与信・請求方法）が違う場合に分けます。例えば同じ会社でも「物販」と「保守サービス」で請求条件が違えば、別アカウントにします
サイトは BU 固有：顧客サイトは BU 固有の参照データセットに割り当てます。アカウントは全社で共有し、請求する BU ごとにサイトと Bill-To 用途を用意します
連絡先と責任（Responsibility）：メールで請求書を送るには、メールアドレスと Bill-To の責任を持つ有効な連絡先が必要です。明細書には Statement の責任が要ります。Collections や Dunning の責任を持つ連絡先は、請求書のメール送付先から除かれます
アカウント関係：関係を設定したアカウント間では、請求・出荷・支払の情報を共有できます（例：親会社のアカウントが子会社の請求書を支払う）

顧客プロファイルとプロファイルクラス

プロファイルクラスは、顧客を「期日どおりに払う顧客」「遅延が多い顧客」のように分類し、取引条件の既定値をまとめて配る仕組みです。

顧客アカウントを作ると DEFAULT プロファイルクラスが割り当てられます。Edit Account で変更できます
サイトには自動では割り当てられません。サイト単位の条件が必要な場合は Create Site Profile で最初のプロファイルを割り当てます
アカウントやサイトで個別に値を上書きしても、プロファイルクラス自体は変わりません
プロファイルは有効日付の範囲で管理され、取引や入金の日付でどのプロファイルが使われるかが決まります。プロファイル履歴で過去の版を確認できます

プロファイルで管理する主な項目は次のとおりです。

分類	主な項目	関連ページ
請求	支払条件、条件の上書き可否（Override terms）、残高繰越請求（有効化・Bill Level・Bill Type）	請求
送付	送付方法（Preferred Delivery Method：Email、XML、Portal Upload など）、印刷オプション（Print Option）	請求
入金	AutoCash ルールセット、割引の猶予日数、主たる入金方法と支払手段、最低入金額	入金
明細書・督促	明細書サイクル、督促の設定、回収者	回収
与信	与信限度、与信チェックの設定	—

共通設定

システムオプション（BU 単位）

Receivables システムオプションは BU ごとの基本設定です。事前に方針を決めておくべき主な項目は次のとおりです。

項目	内容・注意点
Require salesperson	収益会計（収益・営業クレジットの調整）を使うなら有効にする
Use header level rounding	ヘッダーで丸め、差額を Header Rounding Account に計上。保存後は無効化できない
Allow change to printed transactions	印刷済み取引の変更可否。入金・クレジットメモ・修正・会計・残高繰越請求への組み込みなどの活動がある取引は、この設定に関係なく変更できない
Allow unearned discounts / Discount on partial payment	割引期間後の割引、一部入金時の割引を認めるか
Enable recurring billing	定期請求（Recurring Bill Plan）を使う場合に有効化
メール送付（Transaction / Statement Delivery Using Email）	差出人名・アドレス・件名・本文（Billing and Revenue のタブ）

Receivables 活動（Receivables Activities）

取引・入金以外の活動の既定勘定を定義します。主な活動タイプは次のとおりです。

Adjustments：修正。最低 1 つ必要
Earned Discount / Unearned Discount：割引期間内・期間後の割引
Miscellaneous Cash：雑入金。最低 1 つ必要
Receipt Write-off：入金の未消込額や入金不足の償却
Refund / Credit Card Refund：返金。Refund は BU で有効なものが 1 つだけ
Late Charges：延滞料
Prepayments / Payments / Credit Card Chargeback：前受金、入金同士の消込、カードのチャージバック。いずれも BU で有効なものは 1 つだけ
Bank Error / Claim Investigation / Short Term Debt など：銀行エラー、差額の調査、手形割引の短期借入

AutoAccounting

AutoAccounting は、取引の既定の勘定科目を勘定タイプごとに導出するルールです。取引を入力する前に定義が必要で、入力時に上書きもできます。

勘定タイプ	主な導出元（セグメントごとに指定）
Receivable（売掛金）	Bill-to Site、Salesperson、Transaction Types、定数
Revenue（収益。延滞料を含む）	Bill-to Site、Salesperson、Standard Lines（メモ明細・品目）、Transaction Types、定数
Tax（税）	上記に加え Tax（税率コードの税勘定）
Freight（運賃）	Bill-to Site、Salesperson、Standard Lines、Transaction Types、定数
Unearned Revenue / Unbilled Receivable	前受収益（In Advance）・未請求売掛金（In Arrears）
AutoInvoice Clearing	取込取引の差額（取引ソースで有効にした場合のみ使用）

定数（Constant value）は、そのセグメントの有効値でなければなりません
手形（Bills Receivable）関連の勘定タイプでは Drawee Site や Remittance Banks を導出元に使います
例：会社セグメント＝Bill-to Site、勘定セグメント＝Transaction Types、部門セグメント＝Salesperson、補助セグメント＝定数「000」

取引タイプ（Transaction Types）

取引タイプは、取引のクラス（Invoice、Credit Memo、Debit Memo、Chargeback など）と、残高・会計への影響を決めます。

項目	内容
Transaction Class	Invoice、Credit Memo、Debit Memo、Chargeback など
Open Receivable	顧客残高を更新するか
Post to GL	GL への会計の対象にするか
Natural Application Only / Allow Overapplication	残高をゼロまでしか消し込めないか、ゼロを超えて消し込めるか
Creation Sign、Transaction Status、Generate Bill、Print Option	金額の符号、既定の状態（Open・Closed・Pending・Void）、請求書の作成・印刷
Reference Accounts	収益・売掛金などの勘定（AutoAccounting の導出元として使う）

作成順：クレジットメモ用 → 請求書用 → デビットメモ用 → チャージバック用。取引ソースで使う取引タイプは、取引ソースより先に作ります
延滞料を請求するには、デビットメモとして出すなら Debit Memo クラス、利息請求書として出すなら Invoice クラスの取引タイプを作り、売掛金・収益の勘定を指定します。延滞料の作成時は AutoAccounting ではなくこの勘定が使われます
Open Receivable は有効、Post to GL は無効の組み合わせにすると、GL に影響させずに顧客残高だけを確認・更新する使い方ができます。組み合わせの詳細はリリースにより異なるため公式ドキュメントで確認してください
Natural Application Only の請求書が全額入金済みの場合、クレジットメモを作る前に入金の消込を外す必要があります

取引ソース（Transaction Sources）

取引ソースは、取引の作り方（Manual＝手入力、Imported＝AutoInvoice で取込）と採番、取込時の検証方法を決めます。

項目	内容
Type	Manual または Imported
Automatic transaction numbering / Last Number	自動採番と開始番号
Standard Transaction Type	既定の取引タイプ
Invalid Line	不正な明細があったとき請求書全体を拒否する（Reject Invoice）など
Accounting Date in a Closed Period	会計日がクローズ済み期間のとき日付を調整する（Adjust）か拒否するか
Grouping Rule	AutoInvoice が明細を請求書にまとめる規則
Receipt Handling for Credits	入金済み請求書へのクレジットメモ取込時の扱い

取込用の取引ソースでは、顧客・品目・勘定などを ID・番号・値のどれで渡すかも指定します。外部システムのコード体系に合わせて決めてください。

支払条件（Payment Terms）

分割：期日の異なる複数の分割（Installment）に請求額を分けられます
割引：期日前の支払に割引を付けられます。割引の計算基準（Discount Basis）も指定します
残高繰越請求用の支払条件：請求サイクル（Billing Cycle）を指定した支払条件です。例えば「月末締め、翌月 15 日払い」は、月末締めのサイクルと Due By Day of Month＝15 で表します
印刷のリードタイム：支払条件の印刷リード日数を指定すると、期日から逆算した日に請求書を印刷できます

送付先住所・承認限度・明細書

送付先住所（Remit-to Addresses）：顧客に支払先を示す住所です。取引の完了に必須で、AutoInvoice は送付先住所を決められない取引を拒否します
承認限度（Approval Limits）：ユーザーごとに、文書タイプ（Adjustment、Receipt Write-off、Credit Memo Refund）・通貨・金額範囲で承認できる範囲を決めます。範囲外の修正は承認待ち（Pending Approval）になります
明細書（Statements）：明細書サイクルをプロファイルに割り当て、Create Customer Statements で作成します。明細書サイト（Statement Site）を設定すると、アカウント配下の全請求先サイトをまとめた 1 通の明細書になります
督促（Dunning）・回収者：回収と請求書管理を参照してください

設定・実装の手順

機能設定マネージャで Receivables のオファリング（Financials）の機能を有効化し、タスクを確認する（FSM）
Manage Receivables System Options で BU ごとのシステムオプションを設定する
Receivables 活動、AutoAccounting、入金区分・入金方法、送付先住所、承認限度、明細書サイクルを設定する
支払条件 → 取引タイプ → 取引ソースの順に作る
回収者・督促の設定を済ませてから、プロファイルクラスを作る
顧客を FBDI で移行する
1. 『File-Based Data Import for Financials』の Customer Import から CustomerImportTemplate.xlsm をダウンロードする
2. 列の順序を変えずに入力する（列は削除せず、不要な列は空欄のままにする）。プロファイルの既存値を消すには ! を入れる
3. CSV（ZIP）を作成し、UCM アカウント fin/receivables/import にアップロードする
4. Load Interface File for Import を実行し、Import Process に Import Trading Community Data in Bulk を指定する
5. エラーを確認し、件数と主要項目を照合する
Receivables のデータだけを登録したい場合（TCA のパーティ情報を細かく指定しない場合）は、簡易版の Upload Customers from Spreadsheet も使えます

コード例

移行後に、請求先用途がないアカウントを洗い出す SQL の例です（BI Publisher のデータモデルで使う想定）。

SELECT hp.party_name,
       hca.account_number
FROM   hz_cust_accounts hca
JOIN   hz_parties hp ON hp.party_id = hca.party_id
WHERE  hca.status = 'A'
AND    NOT EXISTS (
         SELECT 1
         FROM   hz_cust_acct_sites_all cas
         JOIN   hz_cust_site_uses_all csu
                ON csu.cust_acct_site_id = cas.cust_acct_site_id
         WHERE  cas.cust_account_id = hca.cust_account_id
         AND    csu.site_use_code = 'BILL_TO'
         AND    csu.status = 'A')
ORDER  BY hp.party_name

実務では、移行元の件数（パーティ・アカウント・サイト・用途）と取込後の件数を突き合わせ、差異のある顧客を一覧にします。

落とし穴とベストプラクティス

プロファイルクラスは「支払・請求の条件のパターン」ごとに少数にし、顧客個別の上書きは例外にします
AutoAccounting は COA 設計と同時に決めます。導出元が増えるほど保守とテストが重くなります
取引タイプ・取引ソースは、レポートや会計の切り口として本当に必要な単位に絞ります

試験対策ポイント

対応する試験：AR 模擬テストの「Setting up common configurations in the Customer Invoice to Receipt process」
覚えるポイント
- TCA の階層（パーティ → アカウント → サイト → 用途）と、取引に Bill-To 用途が必須であること
- 顧客サイトと顧客アカウント関係は BU 固有の参照データセットのみ
- 新規アカウントには DEFAULT プロファイルクラス、サイトには自動で付かない
- AutoAccounting の勘定タイプと導出元（Unbilled Receivable は In Arrears、Unearned Revenue は In Advance）
- 取引タイプの作成順（クレジットメモ → 請求書 → デビットメモ → チャージバック）
- 承認限度の文書タイプ（Adjustment、Receipt Write-off、Credit Memo Refund）
- 顧客の FBDI は Import Trading Community Data in Bulk