はじめに
色々やってきて思うことを雑多に書いていきます。
一応、SaaSを想定。
SFで組む場合のオブジェクト構成
見積を脇に置いて、契約・売上・請求という所で話をすると、一般に売上や請求のデータ生成は契約情報を起点としてなされます。
従って、オブジェクト構成を考えた場合、契約・売上・請求の各情報を管理するための理論上の最小構成は「契約」＋「売上＆請求」です。
つまり、契約レコードの下に月単位でのレコードをぶら下げる構成です。
とはいえ、このような構成は現実には運用に耐え得るものではありません。
なぜなら、同一のレコードが複数の目的で利用され、それぞれが競合しあうことになってしまうからです。
具体的には、売上管理・売上予測・請求管理・予実管理・外部の請求系ソフトとの連携・従量課金に関する実績値の格納・変動型原価の実績値の格納などがそれぞれ競合してしまいます。
従って、現実には売上と請求を分ける必要があり、その場合、下記３パターンの構成が考えられます。
パターン１
パターン２
パターン３
それぞれの特徴を見ていきます。
パターン１に関しては、この構成が現実に採用されることはありません。
なぜなら、この構成にすると請求情報と売上を紐づけることができなくなってしまい、結果として文字通り請求書情報と売上情報との比較チェックや監査時のバウチング業務に支障をきたすようになってしまうからです。
販売管理がこの構成で作られているDBは明確に「設計ミス」と言えます。
パターン２が最も採用されることの多い構成です。
自然なかたちで売上データと請求データを紐づけることができます。
デメリットとしては、売上計上日が未確定のまま前受金が発生するパターンに対応することができないという点が挙げられます。
パターン３は採用されることはほぼないですが、パターン１と異なり実務運用が全く不可能というわけではありません。
下記の条件を満たす場合のみ、採用候補に挙がります。
①売上データの生成と同じタイミングで請求データを作ってOKな場合
②外部システム連携の仕様が将来に渡って変更される可能性がない場合
※パターン１で外部システム連携する場合は↓のようなイメージ
なお最後に、商談と契約、商談と売上の区別について一言述べておくと、それらを区別しておかないと、新規・アップセル・クロスセル・ダウンセル・更新・チャーンのいずれかが集計不可能になります。