まずは、SinglePairのみ 基本的には仕訳帳を使わないUIを目指しているので、まず、SinglePairの編集対象にはCounterparty（取引相手）も含めた。売上・経費どちらの編集でも、勘定科目と金額だけでな

固定資産と定期取引まわりの機能もいくつか進めていた。こちらは横断的な機械作業ではなく、それぞれ単独で会計ルールを詰める必要がある実装だった。 固定資産：中古車の簡便法耐用年数 固定資産はこれまで新車の普通車・軽自動車しか

UIを追加・修正していくにあたって、UIの色・角丸・影のルールを一気に整備した。それまでは画面を作るたびにbg-blue-500やrounded-xlをその場で書いていて、見た目の統一感がじわじわ崩れていた。 「層」では

初回セットアップウィザードを丸ごと再設計した。かなりボリュームが大きい作業で疲れた。 何が問題だったか これまでのSetupWizardは、銀行口座の有無・現金の扱い・固定資産の有無・取引先の有無・期首残高……といった項

昨日から今日にかけて、アプリ全体の操作に「誰が実行したか（actor）」を渡して認可するように直す作業をしていた。 やったことは単純で、「この操作は誰の権限で行われたのか」を引数として明示的に渡し、呼び出し側全部でチェッ

クレジットカード明細CSVの取込だけ先に作ってあったので、その次の段階として、CreditCardStatementLine から Transaction を登録できるようにした。 今回やりたかったのは、単に「明細から仕

クレジットカード明細CSVの取込の土台を実装した。今回は「画面からアップロードして使えるようにする」ところまでは進めず、まずはアプリケーション内部から安全に呼べる import サービスと、カード会社ごとの差異を吸収する

確定申告書（第一表・第二表）まわりのモデルを作り始めた。前回までは様式PDFに数字を重ねて出す「印字」の部分だけを作っていて、肝心の「その数字をどこから持ってくるか」がまだなかった。今回はそこに手を付けた回。 何を作った

確定申告書（第一表・第二表、令和5年分）のPDF出力に対応した。先日の青色申告決算書と同じく、国税庁の様式PDFに帳簿の数字を重ねて出力する方式。今回はこの作業のほとんどをOpus 4.8に任せてみたら、拍子抜けするくら

JournalEntryにtax_amount_sourceという項目を追加した。これは税区分（tax_type）とは別に、「そのtax_amountという数字がどうやって決まったのか」を記録するための項目。ここに落ち着