Run Rate Business における営業担当 KGI の集計方法（Salesforce 実装メモ）

## 1. 結論 ――“誰の手柄か”を決め切れればレポートは組める
- **One‑Time Business**（例：BtoB SaaS、プロジェクト系）  
  → 受注＝商談成立。商談（`Opportunity`）の所有者をそのまま KPI/KGI に使えば OK。
  ```mermaid
  flowchart TD
    %% ----- One‑Time Business -----
    subgraph OT["One‑Time Business<br>(スポット受注モデル)"]
        direction LR
        ot1([リード / 見込客])
        ot2([商談<br>Opportunity])
        ot3([Close Won])
        ot4([売上計上・終了])
        
        ot1 --> ot2 --> ot3 --> ot4
    end

- **Run‑Rate Business**（例：連続生産の製造業、消費財卸）  
  → 受注件数は商談より多い。商談は「導入フェーズ」の管理に留め、実売上は **注文（`Order`）** または外部システムで捕捉する。注文を誰の成果にするか？の考えで実装手段が変わる。

```mermaid
  flowchart TD
  
  %% ----- Run‑Rate Business -----
    subgraph RR["Run‑Rate Business<br>(継続受注モデル)"]
        direction LR
        rr1([リード / 見込客])
        rr2([商談<br>Opportunity<br>＝導入フェーズ])
        rr3([Close Won])
        rr4([注文<br>Order])
        rr5([売上計上])
        
        rr1 --> rr2 --> rr3 --> rr4 --> rr5
        rr4 -- "リピート注文" --> rr4 
    end

```

## 2. シナリオ別：担当営業をどう紐付けるか

| シナリオ | 推奨オブジェクト / 設計 | 実装ポイント |
|----------|-------------------------|--------------|
| **① 1アカウント＝1担当** <br>（専任営業制）| 取引先 (`Account`) を担当者の所有物にする | - 標準項目 **所有者** をそのまま使用<br>- レポートは Account, Opportunity, Order いずれも「所有者」で集計 |
| **② 1製品＝1担当** <br>（プロダクト営業制）| 商品 (`Product2`) を担当者所有にする | - `Product2.OwnerId` を編集可にしておく<br>- 商談商品／注文商品にカスタムユーザー項目を作成し、 **親商品の所有者** の値をフローでコピーすることで担当変更時に対応できる |
| **③ 同一アカウントに複数担当** <br>（案件単位の都度アサイン）| 商談 (`Opportunity`) を担当者所有にする | - One‑Time Business ならこれで終わり<br>- Run‑Rate Business だと「導入者 ≠ リピート受注者」問題が残る |
| **④ Run‑Rate × 複数担当 × 非製品担当制** | **価格表エントリ (`PricebookEntry`)** に「担当者」カスタム項目を追加。取引先毎にカスタム価格表を作成。 | - `PricebookEntry__c.Sales_Rep__c (Lookup<User>)` を追加<br>- 注文商品作成時、レコードトリガフローで `PricebookEntry__c.Sales_Rep__c` → `OrderItem.Sales_Rep__c` にコピー<br>- レポートは OrderItem をローデータに `Sales_Rep__c` で集計 |

> 💡 **ポイント**：Run‑Rate では「最初に導入させた人の功績を、後続の注文にも乗せるか？」をまず経営側で合意させる。ロジックが決まれば実装は難しくない。

## 3. 実装ステップ（ケース④の例）

1. **価格表エントリに担当者フィールドを追加**  
   - 型：`Lookup(User)`、API 名：`Sales_Rep__c`  
2. **注文商品に担当者フィールドを追加**  
   - 型：同上、API 名：`Sales_Rep__c`
3. **レコードトリガフロー**（オブジェクト＝Order Item）  
   - トリガ：作成のみ  
   - 取得：`[PricebookEntry].Sales_Rep__c`  
   - 代入：`$Record.Sales_Rep__c ← {取得値}`
4. **レポートタイプ**  
   - 主オブジェクト：Order Products  
   - 必要列：`Sales_Rep__c`, `Order.AccountId`, `TotalPrice`, `Quantity`, `CreatedDate` etc.

## 4. 実装で合わせて用意しておきたいフロー（一覧）

> ※ 本記事ではロジック詳細を割愛し、必要なフロー／オートメーションの全体像だけを整理します。  
> 詳細実装は別記事で順次解説予定。

| # | 目的 | トリガ & 処理概要 | 備考 |
|---|------|-----------------|------|
| 1 | **注文作成時に取引先専用の価格表を自動選択** | *Order* レコード生成時：<br>Lookup 先 `Account.Default_Pricebook__c` → `Order.Pricebook2Id` へ代入 | 価格表が複数ある環境の必須基盤 |
| 2 | **注文商品に担当営業をコピー** | *Order Item* 作成時：<br>`PricebookEntry.Sales_Rep__c` → `OrderItem.Sales_Rep__c` | 本記事の KGI 集計ロジックの肝 |
| 3 | **商談成立後に価格表エントリへ最終単価を転記** | *Opportunity* が Won になったら：<br>関連 *OpportunityLineItem* の金額 → `PricebookEntry.ListPrice` へ書込み | “アカウント専用単価” を PricebookEntry に残す |
| 4 | **価格改定時の履歴スナップショット** | *PricebookEntry* 更新時：<br>旧 `ListPrice` と更新者情報を履歴オブジェクトへ INSERT | データ監査＆過去受注金額の整合性維持 |
| 5 | **マルチ通貨下での Null ガード** | いずれかの BEFORE フローにて：<br>`ISBLANK(PricebookEntry.Id)` ならフロー停止 | 通貨別 PricebookEntry が存在しない場合の保険 |
| 6 | **権限監視のアラート** | 担当外ユーザーが *PricebookEntry* を更新したら Chatter 通知 | 権限セットが緩い組織向けの低コスト監査 |
| 7 | **定期バッチ：担当者未設定レコードの洗い出し** | スケジュールフロー | レポートだけでも良いが自動リマインド推奨 |


## 5. まとめ
- **Run‑Rate Business の KGI 集計は「どの場合で誰の成果にするか」を明確化するところが全て**。  
- シンプルなルックアップ＋フローだけで、大抵のシナリオはカバー可能。  
- 迷ったら「商談で導入を追跡、注文で売上を追跡」と割り切り、  
  売上側に *担当者を写しておく*――これが一番事故が少ない。