MAS-118: 20番台予算タブに「起票ターゲット月」列を追加

概要

目的

20番台予算タブの「最終起票年月日」列の意味が曖昧（実績なのか指示なのか）で、RPA実行時に「どこまで起票するか」がわかりにくい問題を解消する。「起票ターゲット月」列を新設し、実績と指示を分離する。

背景

現状の「最終起票年月日」列は、タブによって意味が異なる:

つまり全タブで「最終起票年月日」は実質的に指示（ここまで起票してほしい）として使われているが、列名は実績（ここまで起票した）を示唆しており、混乱の原因になっている。

現在のRPA対象月決定ロジック

1. UIダイアログで targetOverride が指定された場合 → それを使う
2. targetOverride がない場合 → deriveTargetYmFromSheet_() で
   最終起票年月日の最大値を取得し、+1ヶ月したものを使う
   ※ ただし 22/23/24 タブは +1ヶ月しない（手入力をそのまま使う）
3. 行ごとの起票では row[idxLastBilled] を上限として使用

この「+1ヶ月する/しない」の分岐がタブごとに異なり、コードの可読性を下げている。

修正方針

列の役割分離

変更概要

Step 1: DDLスキーマに「起票ターゲット月」列を追加

101_sys_config.js の全20番台タブの DDL headers に 起票ターゲット月 を追加。配置は 最終起票年月日 の直前。

Step 2: RPA のターゲット月決定ロジックを変更

401_bat_rpa.js の各 RPA 関数で:

1. 起票ターゲット月 列が存在すればそれを使用（targetOverride より優先度低、行単位の上限として使用）
2. 起票ターゲット月 が空の行はスキップ（明示的な指示がない = 起票不要）
3. RPA 実行後に 最終起票年月日 を起票完了月で自動更新

// 変更前（22/23/24 タブ）
// 最終起票年月日が手入力=「ここまで作成」の意味なのでそのまま使う

// 変更後
// 起票ターゲット月を参照し、そこまで起票。完了後に最終起票年月日を更新
var targetCol = h.indexOf('起票ターゲット月');
var rowTarget = targetCol !== -1 ? Utils.parseDateToYm(row[targetCol]) : null;
if (!rowTarget) continue; // ターゲット未指定はスキップ
// ... 起票処理 ...
// 起票完了後:
if (targetCol !== -1) {
  sheet.getRange(rowIdx + 1, idxLastBilled + 1).setValue(rowTarget);
}

Step 3: deriveTargetYmFromSheet_() の変更

起票ターゲット月 列が存在する場合はそちらから対象月を算出する。+1ヶ月する/しない の分岐を不要にする。

移行戦略

既存データとの互換性を維持するため、段階的に移行する:

1. Phase A（本案件）: DDL に列追加 + RPA に「起票ターゲット月があればそちらを優先」のフォールバック付きロジックを実装
2. Phase B（後日）: 運用で「起票ターゲット月」の運用が定着したら、「最終起票年月日」の手入力運用を廃止

Phase A では「起票ターゲット月」が空の場合、既存の「最終起票年月日」ベースのロジックにフォールバックするため、既存運用を壊さない。

影響範囲

注意事項

1. DDL変更のタイミング: setupAllSchemas 実行で列が追加される。既存データの列ズレに注意（起票ターゲット月 は 最終起票年月日 の前に挿入するため、既存データの列位置が1列ずれる可能性がある）。CLAUDE.md の「28_bud_allocation はDDLスキーマが3列のみ」の注意事項に留意
2. フォールバック必須: Phase A では「起票ターゲット月」が空の場合に既存ロジックで動作すること
3. 行単位のターゲット: 全タブで行ごとに異なる起票ターゲット月を指定可能にする（既に最終起票年月日が行単位で参照されているパターンを踏襲）
4. 日付形式: 起票ターゲット月 は yyyy-MM 形式（年月のみ）。最終起票年月日 は yyyy-MM-dd 形式（年月日）。列名で区別を明確化
5. テスト: T1（HC RPA）, T5（SaaS RPA）で起票ターゲット月を設定した場合の動作を確認すること

関連ドキュメント

人間が検討すべき事項

• DDL 列追加による既存データの列ズレ影響の事前検証（dev 環境で setupAllSchemas 実行後に確認）
• 「起票ターゲット月」が空の場合の挙動: スキップ（起票しない）vs フォールバック（既存ロジック）のどちらが望ましいか
• 「最終起票年月日」の自動更新を有効にするか（現状の手入力運用を変更することになる）

実装プロンプト（Claude Code 用）

あなたはGAS会計システム(bizlp-gas-accounting)のシニア開発者です。
案件 MAS-118「20番台予算タブに起票ターゲット月列を追加」を実装してください。

## 背景

20番台予算タブの「最終起票年月日」列が実績と指示の両方の意味で使われており、
RPA実行時に「どこまで起票するか」がわかりにくい。
「起票ターゲット月」列を新設し、指示（ここまで起票してほしい）と
実績（ここまで起票した）を分離する。

## 実行前タスク

以下のファイルを読み込み、現状を把握すること:
- `400_domain/401_bat_rpa.js` — 全RPA関数の最終起票年月日の参照パターン
  特に L173-201（deriveTargetYmFromSheet_, ensureLastBilledCol_）、
  L291（SaaS: +1ヶ月しない）、L564（HC: +1ヶ月しない）、L1055（CAPEX: +1ヶ月しない）
- `100_config/101_sys_config.js` — 全20番台タブの DDL headers 定義
- `docs/dev/dev_mas-118_rpa_target_month_col.md` — 修正方針の詳細

## 修正対象ファイル

1. `100_config/101_sys_config.js` — DDL headers に列追加
2. `400_domain/401_bat_rpa.js` — RPA のターゲット月取得ロジック変更

## 実装内容

### Step 1: DDL スキーマ変更

全20番台タブの DDL headers に「起票ターゲット月」を追加。
配置は「最終起票年月日」の直前。
対象: BUD_PIPE, BUD_HC, BUD_SUBS, BUD_CAPEX, BUD_FIN, BUD_ADHOC

### Step 2: RPA ターゲット月ロジックの変更

各RPA関数（generateSaasInvoices, generateHcInvoices, generateCapexInvoices,
generateFinanceInvoices, generateAdhocInvoices, generatePipelineInvoices）で:

1. 「起票ターゲット月」列のインデックスを取得
2. 列が存在し値が入っていれば、それを行単位のターゲット月として使用
3. 列が存在しないか空の場合は、既存の「最終起票年月日」ベースのロジックにフォールバック
4. RPA起票完了後に「最終起票年月日」をターゲット月の値で自動更新

### Step 3: deriveTargetYmFromSheet_() の変更

「起票ターゲット月」列が存在する場合はそちらから対象月を算出。
+1ヶ月する/しないの分岐を不要にする。

## 制約

- Phase A（フォールバック付き）として実装。「起票ターゲット月」が空でも既存ロジックで動作すること
- 既存テスト（T1〜T8）が回帰しないこと
- 列参照はヘッダー名ベース（indexOf）。列番号ハードコード禁止
- 600_report/ 配下のファイルは変更しない

## 動作確認

1. `npm run push:dev` で開発 GAS にデプロイ
2. GAS エディタで setupAllSchemas を実行 → 全20番台タブに「起票ターゲット月」列が追加されること
3. 23_bud_subscription の「起票ターゲット月」に `2026-05` を入力
4. SaaS RPA を実行 → 2026-05 まで起票されること
5. 「最終起票年月日」が自動更新されること
6. 「起票ターゲット月」が空の行 → 既存ロジックで動作すること（フォールバック確認）
7. runAllTests で T1〜T8 が回帰していないこと

### 拡張思考の使用状況

| フェーズ | 拡張思考 | 備考 |
|---------|:--------:|------|
| DDL スキーマ変更 | なし | headers 配列への文字列追加のみ |
| RPA ロジック変更 | あり | 6つのRPA関数の分岐パターンが微妙に異なるため、各関数での適用方法を慎重に判断 |
| deriveTargetYmFromSheet_ | あり | +1ヶ月ロジックの廃止判断と、フォールバック時の互換性確保 |

### 推奨実行モデル

| 工程 | 推奨モデル | 理由 |
|------|----------|------|
| 全工程 | **Claude Opus 4.6** | 6つのRPA関数を横断的に理解し、タブごとに異なるロジックを統一する設計判断が必要 |

推奨実行モデル

変更履歴