CF精算表の論点展開 — 貸付金・固定資産・運転資本
前日までに全12論点のパイプライン骨格が立ち上がっていた。今日は手を動かして中身を埋める番だ。朝、貸付金の回収予定表を開いてセルをクリックしたら、数式ではなく値がベタ書きされていた。借入金側はとっくに数式化してある。この非対称に気づいた瞬間、今日の最初のタスクが決まった。
貸付金の回収予定表を数式ベースに書き直す
借入金の返済予定表は 元金 = 融資額 / 返済回数、利息 = 残高 × 年利率 × 日数 / 365 という数式で動いている。一方、貸付金側の回収予定表は金額がすべてリテラル値だった。借入金のテンプレートをミラーリングして、入力変数(貸付額・年利率・返済回数)を変えるだけで72行が再計算される構造に揃えた。
合わせて、短期貸付金の論点も追加した。借入金側には既に短期借入金の振替処理(決算整理仕訳 + 翌期振替仕訳)が組まれている。これを貸付金側にミラーリングし、集約シートの構成も同じ形に整えた。
未収収益がACCOUNT_DBに存在しない
貸付金の年次推移表を生成しようとしたら、KeyError: '未収収益' でスクリプトが止まった。ACCOUNT_DBに「未収収益」が登録されていなかった。
勘定科目マスタを確認すると、「その他流動資産」のカテゴリが丸ごと未登録だった。ACCOUNT_DBに「その他流動資産」を追加し、SUB_ACCOUNT_EXPANDにも「未収収益」を子科目として追加した。再実行すると年次推移表が最後まで通った。
補助科目あり版の年次推移表で sum_above が親行に止まる
補助科目を展開した年次推移表で、sum_above 関数が想定外の行を拾っていた。親行(「長期貸付金」など)の直下に補助科目行が展開されるが、sum_above は直上の空でないセルまで遡る仕様のため、展開された親行のラベルセルに到達した時点で止まってしまう。結果、補助科目の合計が親行の値を含まない不完全な集計になっていた。
原因は sum_above のセル走査ロジックが「空セル以外に当たったら停止」だったこと。展開後の親行はラベルだけ入っていて数値セルは空なので、ラベルセルを数値セルと誤認していた。修正として、走査対象を数値セル列に限定し、ラベル列は無視するようにした。
貸付金CFWSの生成 — int_table が None になるバグ
CFWS生成スクリプトで tpl_type == 'lending' を指定したとき、int_table(利息テーブル)が None で返ってくるバグに当たった。
原因を追うと、get_interest_table() の分岐が borrowing しか想定しておらず、lending のときは早期リターンで None を返していた。利息テーブルの取得ロジック自体は借入・貸付で共通なので、分岐条件に lending を追加して解決した。
# Before: borrowingのみ対応
if tpl_type == 'borrowing':
return _build_interest_table(...)
return None # lending がここに落ちていた
# After: lending も同じロジックで処理
if tpl_type in ('borrowing', 'lending'):
return _build_interest_table(...)
固定資産の取引モジュールを新規作成
車両運搬具150万円、定額法、4年後に40万円で売却(売却損5万円)という想定で固定資産ライフサイクルの取引モジュールを組んだ。
mf_journal.py に3関数を追加
gen_depreciation_journals()— 毎期の減価償却仕訳を生成gen_disposal_journals()— 売却時の仕訳(売却損益を含む)を生成gen_acquisition_journals()— 取得時の仕訳を生成
3つの関数を組み合わせることで、取得から売却までのライフサイクル全体の仕訳を一括生成できる。
gen_fixed_asset_lifecycle_xlsx.py の作成
上記の仕訳データを受け取り、減価償却スケジュール表・年次推移表・CFWSをExcelに出力するスクリプトを新規作成した。
Codexレビューでの指摘
計画段階でCodexにレビューを投げたところ、「E2E検証(年次推移表 → CFWSまでの一気通貫テスト)を計画に入れろ」と返ってきた。取引モジュール単体のテストだけでは、下流のCFWS生成で数値がずれても気づけない。この指摘を受けて、固定資産の完成後にE2Eテストケースを追加する計画に修正した。
運転資本モジュールの構築を開始
小売業を想定した運転資本モジュールの構築に着手した。
取引パターンの設計
以下3種類の売上と掛け仕入を組み合わせた。
- 現金売上 — 即時入金
- B2C掛売上 — 当月末締め翌月入金
- クレカ売上 — 月末締め翌15日入金
仕入側も掛け取引で、月末締め翌月末払い。この組み合わせで売掛金・買掛金・クレカ未収金が月をまたいで滞留し、運転資本の増減がCFWSに反映される構造になる。
日次取引データを3年分作成
日次の売上データを3年分(約1,000行)生成するスクリプトを書いた。曜日による売上変動と季節係数を入れて、実務に近い波を持たせている。
値ベタ書きから数式参照へ
売掛金・買掛金・クレカ決済の各シートが、最初は月次の金額をリテラル値で埋めていた。貸付金の回収予定表と同じ轍を踏むところだった。日次取引データシートを参照元にして、各シートの金額セルをすべて SUMIFS 数式に書き換えた。
小計行の廃止 — データとビューを分ける
当初、Excel上に月次小計行を挟んでいた。しかし小計行があると、データ範囲が不規則になり、下流のスクリプトでパースしにくくなる。
「データとビューを分ける」原則に従い、小計行をすべて廃止した。月次集計が必要な場面では、別セルに SUMIFS 関数を置いて対応する。データシートは純粋なトランザクションログとして、加工はビュー側に任せる構成に統一した。
振り返り
貸付金の値ベタ書きに気づいてから、固定資産モジュールの新規作成、運転資本モジュールの着手まで、一日で3つの論点を前に進めた。どの論点でも同じパターンが現れた。値ベタ書きを見つけたら数式に直す。未登録の勘定科目に当たったらマスタに追加する。sum_above のような汎用関数が特定の構造を想定しすぎていたら、走査ロジックを一般化する。
Codexから「E2Eテストを入れろ」と突き返されたのは正しい指摘だった。取引モジュール → Excel生成 → CFWS出力という3段のパイプラインは、途中で数値がずれても最終段まで見ないと気づけない。明日は固定資産のE2Eテストを書いてから、運転資本モジュールの残りを埋めていく。