ユーザーと青色申告書
現実世界では、青色申告書に相当するモデルを検討する。
青色申告書そのものをモデル化するのではなく、会計年度ごとにデータをまとめるモデルとして、会計年度モデル(FiscalYear)を用意する。
User has many FiscalYear
FiscalYear belongs to User青色申告書と決算書
青色申告書を作成するための書類として、決算書が必要。
決算書は「一般用」「農業所得用」「不動産所得用」の3つがあり、ユーザーによっては3つの決算書を扱う必要がある。
会社の部門的なニュアンスなので、決算書はBusinessUnitモデルと命名する。
人によっては、複数の決算書を管理する必要があるが、多くの人は「一般用」もしくは「農業所得用」のどちらか1つが使えれば十分なはずなので、まずは1ユーザー1決算書のケースに対して実装を進める。
FiscalYear has many BusinessUnits
BusinessUnit belongs to FiscalYear仕訳帳と仕訳
1枚の仕訳帳を Transaction モデルとする。
仕訳帳の中の貸方、借方は、それぞれ JournalEntry モデルとする。
複合簿記に対応するため、貸方・借方は複数扱える。
FiscalYear has many Transactions
Transaction belongs to FiscalYearTransaction has many JournalEntries
JournalEntry belongs to FiscalYear仕訳と勘定科目
勘定科目を Account モデルとする。
仕訳ごとに勘定科目に紐づける。
Account has many JournalEntries
JournalEntry belongs to Account勘定科目とユーザーと決算年度とBusinessUnit
ここの設計はかなり悩ましい。
基本的な勘定科目はシステム全体として持っておくのもありだが、データベース上での集計の速さや、ユーザーごとのカスタマイズ(追加, 年度による利用/未利用, 一般/農業で違う勘定科目セット)などを考えると、ユーザーごとにデータを持つのが良いと思われる。
BusinessUnitは一年ごとに作成されるインスタンスなので、BusinessUnitに「その年に使う勘定科目」を管理させたい。
BusinessUnitごとに新たに勘定科目セットを持たせるのが一番簡単だが、年をまたいでの分析をするためには、年が違っていても同じ勘定科目は同一のインスタンスで扱いたい。
ので、Userごとに「使えるすべての勘定科目」を持たせておき、BusinessUnitごとに「自分が使える勘定科目」をセットすることにする。
User has many Accounts
Accounts many-to-many BusinessUnits勘定科目の分類と区分
これは、3つのモデルを has_many, has_many で管理するのが正しい方針だと思うが、分類は固定であり、かつ、個人事業主レベルで区分のカスタマイズは不要と割り切ることにして、Accountモデル内のenumで管理することにする。