• #CF精算表
  • #Python
  • #openpyxl
  • #貸付金
  • #固定資産
  • #運転資本
  • #Excel自動化
開発eurekapu-nuxt4メモ

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テストを書いてから、運転資本モジュールの残りを埋めていく。