これはプロトタイプ hkr では実装してなかった機能なので、ちょっと設計を考える必要がある。しかも面倒・・・・・ まず、定額法しか対応しない！(できない) で、決算書を読んでみる。 変わらないデータと、年ごとに変わるデー

現金を「レジ」「金庫」に分けて保存する場合、月末処理ではそれぞれの残高のチェックをしたい。 同様に、「その他の預金」も、A銀行とB銀行、それぞれの残高が帳簿と合っているかのチェックをしたい。 SubAccountを設定し

仕訳のバランスを見たり、バリデーションチェックをしたりと、結構重要。最初の計画では を考えていたけど、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にした方が良いかどうかは、悩ましいところ。 プロパティ