is_planned の仕訳ができたので、Summary を の2つ別々に集計を出すことに変更。 今まで実装していたのは”実績”で、 [‘actual’] で返す。

いくつかの会計ソフトを使っていて不満に思っていたのが、固定費の管理が面倒なこと。 「水道費、ちゃんと一年分入れてたっけ？」みたいな時に、[水道光熱費]の勘定科目を引っ張ってきて、その中から水道代を目で探して・・・・ とい

サマリーとしては が分かれば、(事業としての)バランスはOK. FiscalYear に calculateSummary メソッドとして追加する。

自分が免税業者なので税込経理しか考えてなかったけど、課税業者は消費税を含まない金額で計算する必要があるので、そっちの対応もできるようにしないと、ということに気づいた。 減価償却期間中に課税業者/免税業者が変わると、またさ

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

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

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

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

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

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