問題
Universal Containers社(UC)には、販売店を通じて製品を販売する大口の顧客が数社あります。各顧客と販売店には、UCと直接仕事をする個別の担当者がおり、それぞれ別々に請求されます。アプリケーション構築者は、これらの要件をどのように実装すればよいでしょうか。
- 顧客と販売店の両方を取引先として作成し、各取引先に取引先チームを作成し、販売店のレコードを親取引先に関連付けます。
- 単一の親レコードを作成し、各担当者を取引先責任者として親取引先に追加し、各販売店を子レコードとして追加します。
- 顧客と販売店の両方を取引先として作成し、各担当者を対応する取引先の取引先責任者として追加し、取引先階層を作成します。
- 単一の取引先レコードを作成し、各担当者を取引先責任者として追加し、カスタム販売店オブジェクトを作成します。
正解
- 顧客と販売店の両方を取引先として作成し、各取引先に取引先チームを作成し、販売店のレコードを親取引先に関連付けます。
- 単一の親レコードを作成し、各担当者を取引先責任者として親取引先に追加し、各販売店を子レコードとして追加します。
- 顧客と販売店の両方を取引先として作成し、各担当者を対応する取引先の取引先責任者として追加し、取引先階層を作成します。
- 単一の取引先レコードを作成し、各担当者を取引先責任者として追加し、カスタム販売店オブジェクトを作成します。
解説
今回のUniversal Containers社の要件をまとめると以下の通りです。
- 大口顧客とそれらの顧客の販売店を管理する。
- それぞれの顧客と販売店に対して個別の担当者を割り当てる。
- 顧客と販売店を別々に請求できるシステムを実装する。
それぞれの選択肢の理由について説明します。
□ 顧客と販売店の両方を取引先として作成し、各取引先に取引先チームを作成し、販売店のレコードを親取引先に関連付けます。
これは不正解です。取引先チームは、Salesforceで取引先情報を複数のユーザーと共有し、共同で管理する機能ですが、Universal Containers社の要件には直接必要ではありません。今回の要件は、大口顧客と販売店を個別に管理し、それぞれに対して担当者を割り当て、別々に請求するシステムを実装することです。
□ 単一の親レコードを作成し、各担当者を取引先責任者として親取引先に追加し、各販売店を子レコードとして追加します。
これは不正解です。このアプローチでは、顧客と販売店が同一の取引先として扱われるため、それぞれの独立した管理と請求が困難になります。UCの要件には、顧客と販売店を別々に扱うことが含まれており、この方法ではそれを満たせません。
□ 顧客と販売店の両方を取引先として作成し、各担当者を対応する取引先の取引先責任者として追加し、取引先階層を作成します。
これは正解です。この方法はUCの要件を完全に満たします。顧客と販売店を別々の取引先として扱い、各取引先に対応する担当者を取引先責任者として割り当てることで、それぞれの独立した管理と請求が可能になります。取引先階層の使用により、顧客と販売店間の関連性を保持しつつ、個別の取引先としての管理を効率的に行うことができます。
□ 単一の取引先レコードを作成し、各担当者を取引先責任者として追加し、カスタム販売店オブジェクトを作成します。
これは不正解です。この方法では、顧客と販売店が単一の取引先レコードとして扱われるため、個別の管理と請求が難しくなります。カスタム販売店オブジェクトの作成は、販売店の詳細情報を管理するために有用かもしれませんが、主要な要件である独立した請求の管理に直接対応しているわけではありません。
コメント