青色申告をベースに考えると、FiscalYear has many BusinessUnit なんだけど、実務としては BusinessUnit has many FiscalYear ですね。 勘定科目との関連を考えて […]

ユースケースとして、 まで、考えてみる。 ユーザー新規登録 会計年度作成 BusinessUnit作成 BusinessUnit が作られるタイミングで、デフォルトの Account, SubAccount も作成する。

勘定科目だけでなく、補助科目(SubAccount)も用意したい。 みたいなイメージ。 ただ、集計時は Account でグルーピングして集計するし、SubAccount を持たない Journal Entry も存在す

「勘定科目」です。 のいずれかに所属する。 グループは5つで固定なので、 enum:AccountType として管理する。 デフォルトで用意する勘定科目は、税務署でもらう[ 令和xx年分所得税青色申告決算書(一般用)]

いわゆる「貸方」「借方」 ここで問題なのは消費税。 税込の金額だと本則課税に対応できないので、データとしては「金額」「消費税」を別々に管理しておき、入力の煩雑さはUIで解消することとする。

実世界でのいわゆる「伝票」(赤伝、青伝、振伝)に相当。 貸方のJournalEntry と 借方の JournalEntry を持つ。 貸方と借方の値が一致しないと登録できないようにする。 idはシステム全体のidだが、

の3つがあるので、内部のenumで3つを区別するようにする。 AbstractClassにした方が良いかどうかは、悩ましいところ。 プロパティ

プロパティ 個人事業主向けの会計ソフトなので、期間は1/1〜12/31で固定。必要なのは「年」のみ。 複数年度を切り替えて使う時ように、activeフラグを用意しておく。 userとのリレーションのため、user_id

ユーザーと青色申告書 現実世界では、青色申告書に相当するモデルを検討する。 青色申告書そのものをモデル化するのではなく、会計年度ごとにデータをまとめるモデルとして、会計年度モデル(FiscalYear)を用意する。 青色

1サーバー1ユーザーにするか、マルチユーザーにするかは悩ましいところです。ただ、(実装するかどうかは別として) などのシチュエーションを考えると、将来的にマルチユーザーは必要になるはず。 後からマルチユーザーにするコスト