仕訳のバランスを見たり、バリデーションチェックをしたりと、結構重要。最初の計画では を考えていたけど、FIscalYear の責務が重くなる可能性が高いので、TransactionRegistrar サービスクラスを作っ […]

青色申告をベースに考えると、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)を用意する。 青色