MAS-082: 計画B/Sに仕訳振替ペアのB/S表示を追加

概要

調査で確定した修正対象: 当初の案件想定では 600_report/604_datamart_bs.js が対象と推測されていたが、Phase 1 のコードReadで判明した通り、604_datamart_bs.js は ctx.martBs を消費するのみで仕訳振替判定は一切行わない。実際に「仕訳振替 INV を計画B/S から除外している」ロジックは 600_report/601_datamart_ingest.js の dmIngestPlanData_() 関数に存在するため、本仕様書では同関数を修正対象とする。

目的

HC（給与 RPA）が 32_wrk_invoice に書き込んだ「預り金（源泉所得税・住民税・社保）」等の仕訳振替 INV が、計画B/S（73/73b タブ）に一切反映されていない問題を修正する。

給与支払日に 預り金 +金額 を計上する仕訳振替 INV（401_rpa_hc.js L282-334 Row 2a/Row 3a/Row 4a）と、納付日に 預り金 -金額 を計上する仕訳振替 INV（Row 2b/Row 3b/Row 4b）は、どちらも 決済手段 === '仕訳振替' であるため、現状の dmIngestPlanData_() L318 の if (pm === '仕訳振替') continue; によって一律除外されている。その結果、期末の未納付残高（＝預り金の残高）が計画B/S に表れず、B/S の完全性が損なわれている。

本案件では、B/S 科目に該当する仕訳振替 INV を計画B/S の集計対象に追加し、預り金等の負債残高が計画 B/S に正しく表示されるようにする。

現在のコード

600_report/601_datamart_ingest.js L277-354 dmIngestPlanData_()

計画B/S のデータ源である planUnionData は以下の関数で生成される。仕訳振替 INV の扱いが該当箇所（抜粋）:

// L295-308: 仕訳振替INVのB/S科目ペアマップを構築（ORD+科目名 → 仕訳振替あり）
var jePairSet = {};
for (var ji = 1; ji < invData.length; ji++) {
  if (idxFlag !== -1 && (invData[ji][idxFlag] === false || ...)) continue;
  var jpm = idxPay !== -1 ? String(invData[ji][idxPay]).trim() : '';
  if (jpm !== '仕訳振替') continue;
  var jacc = String(invData[ji][idxAcc]).trim();
  var jmapped = acctMap[jacc];
  var jIsBs = jmapped ? (jmapped.stmt === 'B/S' || ...) : false;
  if (!jIsBs) continue;
  var jord = idxOrd !== -1 ? String(invData[ji][idxOrd]).trim() : '';
  if (jord) jePairSet[jord + '|' + jacc] = true;
}

for (var i = 1; i < invData.length; i++) {
  // ...(有効フラグチェック)
  // L317-318: 仕訳振替INVを一律除外
  var pm = idxPay !== -1 ? String(invData[i][idxPay]).trim() : '';
  if (pm === '仕訳振替') continue;     // ← 預り金等がここで落ちる

  // ...(発生年月・科目マッピング)
  // L333-337: 非仕訳振替のB/S INVも jePair があれば除外
  if (isBs && pm !== '資産計上') {
    var ordId = idxOrd !== -1 ? String(invData[i][idxOrd]).trim() : '';
    if (ordId && jePairSet[ordId + '|' + acc]) continue;
  }
  // ...
}

問題の構造

現状、Row 2a〜4b の全てが L318 で除外されるため、計画B/S の「流動負債 › 預り金」行は常にゼロ。実績B/S（601_datamart_ingest.js L212-246 の仕訳振替認識ロジック）では 33_wrk_bank の消込済 STL 経由で認識されているのに対し、計画B/S では一切反映されない不整合が発生している。

修正方針

変更対象

600_report/601_datamart_ingest.js の dmIngestPlanData_() 関数のみ。他ファイルへの変更は不要。

追加するロジック

dmIngestPlanData_() のメインループ（L310-351）で L318 の if (pm === '仕訳振替') continue; を撤廃せず、代わりに仕訳振替 INV のうち B/S 科目に該当するものを 別途集計対象に追加する分岐を設ける。アプローチとしては以下のいずれか:

• 案A: L318 の continue 直前で「仕訳振替 かつ B/S 科目」なら planData に push した後に continue する（最小差分）
• 案B: 既存のメインループの後ろに、仕訳振替 B/S INV 専用の追加ループを設ける（副作用が少ない）

本仕様では**案A（最小差分）**を採用する。

処理ルール

1. 決済手段 === '仕訳振替'（完全一致）のINV を対象にする（CLAUDE.md 規約）
2. 科目マスタ（ctx.acctMap）を引き、stmt === 'B/S'（または 'BS'、または '貸借' を含む）なら B/S 科目と判定する
3. B/S 科目の場合のみ planData.push(...) する。符号は 税込金額_計画 の符号を維持する（HC Row 2a は正、Row 2b は負）
4. pYm = sYm = 発生日(P/L計上日) のB/S イベントとして追加（仕訳振替は決済日を持たないため期ずれは発生しない）
5. isBsForce: true を設定（B/S 直接計上イベントであることを明示）
6. booked: false のまま（計画イベントなので既存の非仕訳振替 B/S と同一扱い）
7. 既存の非仕訳振替 B/S INV の集計ロジック（L333-337 の jePair 除外）は一切変更しない（二重計上防止）

金額符号と残高計算

• 計算は既存の dmProcessAllEvents_()（602/602_datamart_main.js で呼ばれる）→ dmCalcBs_()（604_datamart_bs.js L38）に完全準拠する
• martBs['liab_cl']['預り金'] に月次で加算・減算され、dmCalcBs_() の bsBal 累積計算で期末残高が算出される
• 新たな符号反転やロジック追加は行わない

影響範囲

影響を受ける出力タブ:

呼び出し元:

• 600_report/602_datamart_main.js L269 の dmIngestPlanData_(ctx, sheetInv) — 変更不要

注意事項

1. 判定は完全一致: 決済手段 === '仕訳振替' の完全一致のみ（CLAUDE.md 規約）。部分一致・大文字小文字違い・前後空白は String(...).trim() で正規化されるが、判定自体は厳密一致。
2. フィールド名の区別: InvoiceDTO（32_wrk_invoice）では 決済手段 フィールドに '仕訳振替' が入る。JournalEntryDTO（42_trn_journal）の 仕訳ステータス とは別フィールド。本案件では 32_wrk_invoice が対象なので 決済手段 を参照する。
3. 科目マスタ未登録は黙って除外: acctMap[acc] が undefined の場合はスキップ（エラーにしない）。既存の非仕訳振替処理と同じ挙動を維持。
4. P/L 科目の仕訳振替は除外: stmt !== 'B/S' の仕訳振替 INV は除外（現状通り）。本案件スコープ外。
5. jePairSet は既存のまま温存: L295-308 の jePairSet 構築と L333-337 の除外ロジックは一切変更しない。仕訳振替側を追加するだけなので jePair の除外対象（非仕訳振替 B/S）との整合性は保たれる。
6. 資産計上との混同禁止: 決済手段 === '資産計上' は別枠（即時 B/S 計上・CAPEX 初回仕訳）。仕訳振替とは判定順序で分岐済み。

エッジケース

実データ検証

実装前に以下を MCP 経由で確認すること（Phase 1 の MCP 確認は未実施）:

科目マスタ（11_mst_account）の確認

• 「預り金」の 諸表区分 が 'B/S' であること
• 「預り金」の 大分類 が '負債' または '流動負債' であること
• 仕訳振替 B/S 科目候補（「預り金」「仮払金」「仮受金」等）の 諸表区分 を一覧化

32_wrk_invoice の実データ確認

• 決済手段 = '仕訳振替' かつ 科目名 = '預り金' のレコードが実在するか
• 上記レコードの 発生日(P/L計上日)・税込金額_計画・親発注ID(ORD) の分布を確認
• Row 2a（正値）と Row 2b（負値）の件数がおおむね対応しているか（期末時点で差額=未納付分）

実装後の計画B/S出力検証

• 73_bs_plan / 73b_bs_plan_ytd の「流動負債」セクションに「預り金」行が表示されること
• 月次の増減が HC RPA の Row 2a/2b/3a/3b/4a/4b の入力と一致すること
• ✨ 負債 合計 と ✨ 資産 合計 が月末時点で貸借一致（差額0）であること
• 実績B/S（71/71b）の預り金残高と、計画B/S（73/73b）の同月残高が境界月付近で連続していること

関連ドキュメント

人間が検討すべき事項

TODO_future.md 記載の「表示対象とする B/S 科目の範囲」に加え、以下を確認する。

1. 表示対象とするB/S科目の範囲（TODO_future.md 記載の主要検討事項）
   • HC RPA 由来の「預り金」のみを対象にするか、すべての B/S 仕訳振替 INV を対象にするか
   • 将来追加される可能性のある B/S 仕訳振替（例: 他のRPA で発生する仕訳振替ペア）も自動的に拾いたいため、科目マスタの stmt === 'B/S' で一律判定する方針を推奨する
2. 実績B/S の仕訳振替認識ロジックとの整合性
   • 実績B/S（dmIngestData_() L212-246）は 33_wrk_bank の消込済 STL をトリガーに仕訳振替 INV を認識する
   • 計画B/S では STL がないため 発生日(P/L計上日) をトリガーにする → 実績と計画で認識タイミングが異なる点を許容できるかユーザー確認
3. 期ずれの扱い
   • 仕訳振替 INV は 決済日_計画 を持たない想定だが、万が一セットされている場合にどう扱うか
   • 本仕様では pYm = sYm = 発生日 として期ずれなしで計上する（最シンプル）
4. 将来の 42_trn_journal への移行
   • 現状は 32_wrk_invoice を参照しているが、JournalEntryDTO.仕訳ステータス を使う方式に将来移行する可能性があるか
5. 73/73b タブが DDL 管理外の動的生成タブである場合の影響
   • 計画B/S 出力先タブが DDL で定義されているか、動的生成されているかを 100_config/101_sys_config.js の setupAllSchemas で確認
   • DDL 管理外であれば setupAllSchemas 実行後の空白化リスクに留意

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

あなたはGAS会計システム(bizlp-gas-accounting)のシニア開発者です。
CLIエージェントである「Claude Code」として、以下の指示に従い、
案件 MAS-082「計画B/Sに仕訳振替ペアのB/S表示を追加」を実装してください。

## 実行前タスク（コンテキストの読み込み）

実装前に必ず以下のファイルを読み込み、現在の実装を把握してください。

1. 修正対象: `600_report/601_datamart_ingest.js` — `dmIngestPlanData_()` の
   L277-354 全体を把握。特に L295-308 の jePairSet 構築、L318 の
   `if (pm === '仕訳振替') continue;`、L333-337 の jePair 除外を確認。
2. 呼び出し元（変更不要・参照のみ）: `600_report/602_datamart_main.js` L269
   の `dmIngestPlanData_(ctx, sheetInv)`、および同ファイル L278-283 の
   `dmProcessAllEvents_ → dmCalcBs_ → dmBuildBsOutput_` のチェーン。
3. 下流の集計ロジック: `600_report/604_datamart_bs.js` `dmCalcBs_()`・
   `dmBuildBsOutput_()`（変更不要。martBs を読むだけ）。
4. 参考: `400_domain/401_rpa_hc.js` L282-445 — HC RPA が 32_wrk_invoice に
   書き込む預り金の仕訳振替 INV（Row 2a/2b, 3a/3b, 4a/4b）。
5. プロジェクト規約: `CLAUDE.md`
6. 開発仕様書（本ドキュメント）: `docs/dev/dev_mas-082_plan_bs_journal_pair.md`

## 修正対象ファイル

`600_report/601_datamart_ingest.js` の `dmIngestPlanData_()` 関数のみ。
他ファイルの変更は不要。

## 実装内容

### 1. 仕訳振替 B/S INV の取込分岐を追加

`dmIngestPlanData_()` のメインループ（L310-351）内、L317-318 の
`if (pm === '仕訳振替') continue;` の行を次のように書き換える:

```js
// 仕訳振替のうち B/S 科目は planData に追加（S-10: 預り金等を計画B/Sに反映）
if (pm === '仕訳振替') {
  var accJe = String(invData[i][idxAcc]).trim();
  var mappedJe = accJe ? acctMap[accJe] : null;
  var isBsJe = mappedJe ? (mappedJe.stmt === 'B/S' || mappedJe.stmt === 'BS' || mappedJe.stmt.includes('貸借')) : false;
  if (!isBsJe) continue;  // P/L 仕訳振替は従来通り除外
  var pStrJe = Utils.parseDateToYm(invData[i][idxDate]);
  if (!pStrJe) continue;
  var amtJe = Utils.parseAmt(invData[i][idxAmt]);
  if (amtJe === 0) continue;
  planData.push({
    pYm: pStrJe,
    sYm: pStrJe,     // 仕訳振替は決済日なし → 期ずれなし
    acc: accJe,
    amt: amtJe,
    booked: false,
    isBsForce: true
  });
  continue;
}
```

### 2. 既存ロジックは一切変更しない

- L295-308 の jePairSet 構築: 変更なし
- L320-337 の非仕訳振替 B/S INV の処理: 変更なし（jePair 除外で二重計上防止）
- L341 の `if (amt === 0) continue;`: 変更なし
- L343-350 の `planData.push(...)`: 変更なし

## 制約

- `600_report/601_datamart_ingest.js` 以外のファイルを変更しない
- 既存の `決済手段 !== '仕訳振替'` を処理する集計ロジックを変更しない
- 判定は `=== '仕訳振替'` の完全一致のみ（CLAUDE.md 規約）
- 列参照はヘッダー名ベース（`indexOf`）で既存の `idxPay`・`idxAcc`・
  `idxDate`・`idxAmt` を使用する。列番号ハードコード禁止
- 科目マスタ未登録の科目はスキップ（`mappedJe` が falsy なら除外）

## エッジケース

| 条件 | 動作 |
|------|------|
| 科目マスタ未登録の科目名 | スキップ（エラーなし） |
| `stmt !== 'B/S'`（P/L科目等） | スキップ |
| 金額がマイナス値 | そのまま計算に含める（HC Row 2b の -withholdingTax 等） |
| `発生日(P/L計上日)` が未入力 | スキップ |
| 対象月のデータが0件 | 0または空白（既存ロジック準拠） |
| 有効フラグ = FALSE | 既存の L311-314 でスキップ |

## 動作確認

1. `npm run push:dev` で開発環境にデプロイする
2. GAS スプレッドシートで `🚀 BizLP` → `操作パネルを開く` からサイドバーを
   表示し、マート更新を実行する（または GAS エディタから
   `updateAllDatamarts()` を直接実行）
3. 73_bs_plan タブの「流動負債」セクションで「預り金」行が表示されている
   ことを確認。月次の増減が HC RPA 由来の仕訳振替金額と一致するか確認する
4. 73b_bs_plan_ytd タブで「預り金」行の OBからの累積変動が正しいか確認する
5. 各月の『✨ 資産 合計』と『✨ 負債・純資産 合計』が一致すること（貸借差額 = 0）
   を確認する
6. `Logger.log` で新たに集計対象となったレコードを出力し、
   取引ID・発生日(P/L計上日)・科目名・税込金額_計画を目視レビューする
7. 実績B/S（71タブ）の預り金残高と、計画B/S（73タブ）の同月残高が
   境界月前後で連続していることを確認する（大きな段差がないこと）

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

| フェーズ | 拡張思考 | 備考 |
|---------|---------|------|
| 実行前タスク（Read） | あり | L277-354 の全体構造と jePairSet 構築の意図を把握 |
| 実装（Edit） | なし | 仕様書のコード例をそのまま書き下す |
| 動作確認レビュー | ユーザー手動 | GAS エディタでの実行と計画B/S 目視確認 |

推奨実行モデル

変更履歴

仕様書作成プロンプト

【タイムアウト回避・実行原則（v1.7・必ず遵守すること）】
1. **拡張思考の使い分け**: Phase 1（設計）では拡張思考をフル活用し、ファイル名・エッジケース・Step分割粒度・固有名詞（関数名/シート名/列名/行番号）を完全に確定させる。Phase 2（清書）の各Step内では拡張思考を最小限に抑え、Phase 1で確定済みの内容の書き下しに徹する。出力途中で再考しない。
2. **テキスト報告の禁止**: 「〜を作成します」等のtextのみでtool_useなしに終了するturnを作らない。説明は1文以内。直ちにtoolを呼ぶ。
3. **4-5分割のWrite/Edit実行**: 2-1(骨格 ~20行)/2-2(概要〜注意事項 ~300行)/2-3a(エッジケース〜人間検討事項 ~200行)/2-3b(実装プロンプト〜変更履歴 ~250行)/2-4(`<details>`プロンプト全文記録)に分割。1回のWrite/Editは300行以内を目安にする。
4. **各Stepで何を書くかを具体指示**: 各Step内で設計判断を再考しない。Phase 1で確定した内容のみ書き下す。

======================================================================
あなたはGAS会計システム(bizlp-gas-accounting)のシニア開発者兼仕様書ライターです。
案件 S-10「計画B/Sに仕訳振替ペアのB/S表示を追加」の開発仕様書を作成してください。
開発仕様書を新規作成した場合は、`docs/_config.json` の `nav` 配列の適切なセクションにも必ず追記してください。

---

## Phase 1: 実行前タスク（テキスト報告禁止。全項目をツールで順次実行）

### 1-A: 案件定義の読み込み
`docs/_internal/TODO_future.md` を検索し、S-10 の「案件名・概要・期待される効果・人間が検討すべき事項」を取得する。

### 1-B: プロジェクト規約の読み込み
`CLAUDE.md` を読み込み、コーディング規約・テスト手順・ファイル番号体系・会計ロジックのルールを把握する。
特に以下のルールを確認する:
- 「仕訳振替の判定は `=== "仕訳振替"` の完全一致」
- 「科目マスタ(11_mst_account)に未登録の科目名はエラー。キーワード推測による自動分類禁止」
- 「列参照はヘッダー名ベース(`indexOf` / `buildHeaderIndex_`)。列番号ハードコード禁止」

### 1-C: 既存仕様書テンプレートの読み込み
`docs/dev/dev_mas-093_cf_actual_only.md` を読み込み、セクション構成・実装プロンプト形式・推奨実行モデルテーブルの書き方を把握する。

### 1-D: 関連コードの調査（Grepは発見のみ。固有名詞の確定は必ずReadで行う）

以下のファイルをすべてReadし、**Phase 2で使う固有名詞（関数名・変数名・シート名・列名・行番号）をここで完全に確定させる**。

#### (a) `000_infra/003_contracts.js`
以下を確認する:
- `InvoiceDTO`（32_wrk_invoice）のフィールド一覧。`仕訳ステータス` フィールドが存在するか。
  - **重要**: 提供されたコードでは `InvoiceDTO` に `仕訳ステータス` は定義されていない。このフィールドは `JournalEntryDTO`（42_trn_journal）に存在する（値域: "自動計上" | "手動" | "仕訳振替"）。データソースが `32_wrk_invoice` か `42_trn_journal` かを次の(b)で必ず確認する。
- `JournalEntryDTO`（42_trn_journal）の全フィールドと `仕訳ステータス` の値域を確認する。

#### (b) `600_report/604_datamart_bs.js`（最重要・最初にReadすること）
以下をすべてReadで確認し、Phase 2の記述に向けて固有名詞を確定させる:
- 計画B/Sを生成している**実際の関数名**（`dmBuildPlannedBs_` は未確認の推測名のため、実在する関数名に置き換える）
- 計画B/Sの出力先シート名（`73_bs_plan` は未確認のため、実在するシート名またはシステムキーを確認する）
- データソースは `InvoiceRepository.findAll()`（32_wrk_invoice）か `JournalRepository.findAll()`（42_trn_journal）か
- 現在の `仕訳ステータス` フィルタ条件の実装箇所と行番号
- `AccountRepository.findAsMap()` の呼び出し箇所と、戻り値 `{ stmt, cat }` の利用方法（`stmt` が諸表区分に対応）
- B/S残高の金額符号・加減算ロジック（`借方/貸方区分` という列名は未確認のため、実在する列名・ロジックを確認する）
- `onOpen()` 内のメニュー名（動作確認手順に実在する文字列のみ記載するため）

#### (c) `200_data/202_repository.js`
以下を確認する:
- `JournalRepository.findAll()` が参照するシートキー（`TRN_JOUR`）と対応シート名（`42_trn_journal`）
- `AccountRepository.findAsMap()` の戻り値構造（`{ [科目名]: { stmt: 諸表区分, cat: 大分類 } }`）

#### (d) `400_domain/401_rpa_hc.js`
以下を確認する:
- 給与支払い処理で `仕訳ステータス = "仕訳振替"` となるレコードが `InvoiceDTO`（32_wrk_invoice）と `JournalEntryDTO`（42_trn_journal）のどちらに書き込まれるか
- 書き込まれる科目名（「預り金」等）と金額の符号を確認する

#### (e) MCPで実データ確認（実装前の必須確認）
- `11_mst_account` シートで「預り金」等の科目の `諸表区分` が `'B/S'` であることを確認する
- (b)で特定したデータソースシートに `仕訳ステータス = '仕訳振替'` のサンプルレコードが存在するか確認する

---

## Phase 2: 仕様書の作成

出力先: `docs/dev/dev_mas-082_plan_bs_journal_pair.md`

### Step 2-1: 骨格の作成（File Write、~20行）
以下の見出しのみを書く（本文は空で可）:

    # S-10: 計画B/Sに仕訳振替ペアのB/S表示を追加
    ## 概要
    ## 目的
    ## 現在のコード
    ## 修正方針
    ## 影響範囲
    ## 注意事項
    ## エッジケース
    ## 実データ検証
    ## 関連ドキュメント
    ## 人間が検討すべき事項
    ## 実装プロンプト（Claude Code 用）
    ## 推奨実行モデル
    ## 変更履歴
    ## 仕様書作成プロンプト

### Step 2-2: 概要〜注意事項の追記（File Edit または Bash heredoc、~300行）
Phase 1で確定した固有名詞のみ使用する。推測で固有名詞を書かない。

- **概要テーブル**: 案件ID=S-10、カテゴリ=データマート・財務諸表、対象ファイル=`600_report/604_datamart_bs.js`、前提案件=なし
- **目的**: 給与支払い処理で生成される仕訳振替ペアのうちB/S科目（預り金等）が計画B/Sに反映されていない問題を修正する
- **現在のコード**: Phase 1(b)で確認した実際の関数名・行番号・フィルタ条件をコードスニペット付きで記載する
- **修正方針**:
  - 修正対象: `600_report/604_datamart_bs.js` 内のPhase 1(b)で確認した実際の関数名と行番号
  - データソース: Phase 1(b)/(d)で確認した実際のRepository（`InvoiceRepository` または `JournalRepository`）
  - 追加するロジック: `仕訳ステータス === '仕訳振替'`（完全一致）のレコードのうち、`AccountRepository.findAsMap()` で `stmt === 'B/S'` となる科目のものを計画B/S集計対象に追加する
  - 既存の非振替レコード（`仕訳ステータス !== '仕訳振替'`）の集計ロジックは一切変更しない（二重計上防止）
  - 金額符号・残高計算の扱いはPhase 1(b)で確認した既存B/S集計ロジックに完全準拠する
- **影響範囲**: `600_report/604_datamart_bs.js` のみ。他ファイルへの変更なし
- **注意事項**:
  - `仕訳振替` 判定は `=== '仕訳振替'` の完全一致（CLAUDE.md規約。部分一致・大文字小文字違いは不可）
  - `AccountRepository.findAsMap()` の戻り値は `{ [科目名]: { stmt, cat } }` 形式。`stmt === 'B/S'` でB/S科目を判定する
  - 科目マスタ未登録の科目はスキップする（エラーにしない）
  - `仕訳振替` 以外のステータスを持つ既存集計ロジックには手を触れないこと

### Step 2-3a: エッジケース〜人間検討事項の追記（File Edit または Bash、~200行）

- **エッジケーステーブル**（`| 条件 | 動作 | 理由 |` 形式）:
  - `仕訳ステータス === '仕訳振替'` だが `科目名` が科目マスタ未登録: 集計から除外、ログなし
  - `仕訳ステータス === '仕訳振替'` だが `stmt !== 'B/S'`（P/L科目等）: 集計から除外
  - 金額がマイナス値: そのまま計算に含める（B/S上の反対残高として扱う）
  - 対象月のデータが0件: 該当月のB/S行は 0 または空白（既存ロジックの挙動に準拠）
  - 貸借不一致の仕訳振替ペア: 本案件スコープ外。入力データの正しさを前提とする

- **実データ検証**:
  - Phase 1(e)で確認した内容（「預り金」の `諸表区分`、サンプルレコードの有無）を記載する
  - 確認できなかった項目は「実装前にMCPで確認すること」として残す

- **関連ドキュメント**: CLAUDE.md（仕訳振替判定ルール）、`docs/dev/dev_mas-093_cf_actual_only.md`（横展開参考）

- **人間が検討すべき事項**: Phase 1-Aで取得したTODO_future.md記載の内容をそのまま転記し、調査で判明した追加事項を補足する

### Step 2-3b: 実装プロンプト〜変更履歴の追記（File Edit または Bash、~250行）
実装プロンプトはバッククォートで囲まず、行頭4スペースインデントで出力する:

    あなたはGAS会計システム(bizlp-gas-accounting)のシニア開発者です。
    案件 S-10「計画B/Sに仕訳振替ペアのB/S表示を追加」を実装してください。

    ## 実行前タスク
    - `600_report/604_datamart_bs.js` をReadし、計画B/S生成関数の実際の名前・行番号・
      現在のフィルタ条件を確認する
    - `000_infra/003_contracts.js` をReadし、データソース（InvoiceDTO または
      JournalEntryDTO）の `仕訳ステータス` フィールドの存在を確認する

    ## 修正対象ファイル
    `600_report/604_datamart_bs.js` のみ

    ## 実装内容
    （仕様書の「修正方針」セクションに記載した内容をコード例付きで転記する）
    - 仕訳ステータス === '仕訳振替' のレコードを抽出するフィルタ処理を追加
    - AccountRepository.findAsMap() の戻り値 { stmt, cat } を用いて stmt === 'B/S' を確認
    - 既存B/S集計ロジックと同一の金額符号・残高計算ロジックを適用
    - 既存の非振替集計ブロックには手を触れない

    ## 制約
    - `600_report/604_datamart_bs.js` 以外のファイルを変更しない
    - 既存の `仕訳ステータス !== '仕訳振替'` を処理する集計ロジックを変更しない
    - 判定は `=== '仕訳振替'` の完全一致のみ（CLAUDE.md規約）

    ## エッジケース
    | 条件 | 動作 |
    |------|------|
    | 科目マスタ未登録の科目名 | スキップ（エラーなし） |
    | stmt !== 'B/S'（P/L科目等） | スキップ |
    | 金額がマイナス値 | そのまま計算に含める |
    | 対象月データが0件 | 0または空白（既存ロジック準拠） |

    ## 動作確認
    1. `npm run push:dev` でデプロイする
    2. GASエディタまたはメニューから計画B/S再生成を実行する
       （メニュー名は 604_datamart_bs.js の onOpen() またはメニュー登録箇所を
        Readして実在する名称を使用すること）
    3. 計画B/S出力シートで「預り金」等の行に給与RPA由来の金額が計上されているか確認する
    4. 各月の資産合計と負債・純資産合計が一致していることを確認する
    5. 変更によって新たに集計対象となったレコードを Logger.log で出力し、
       取引ID・発生日・科目名・金額を目視レビューする

    ### 拡張思考の使用状況
    | フェーズ | 拡張思考 | 備考 |
    |---------|---------|------|
    | 実行前タスク（Read） | あり | 関数名・行番号の特定に使用 |
    | 実装（Edit） | なし | 仕様書の内容を書き下すのみ |

- **推奨実行モデルテーブル**:
  | 工程 | 推奨モデル | 理由 |
  |------|----------|------|
  | 実装 | Claude Sonnet | 修正対象ファイルと方針は仕様書で定義済みだが、挿入位置の特定と既存集計ロジックへの整合が必要 |

- **変更履歴テーブル**: `| 2026-04-19 | 初版作成 |`

### Step 2-4: 仕様書作成プロンプトの記録（File Edit または Bash）
末尾の `## 仕様書作成プロンプト` セクションに `<details><summary>展開して表示</summary>` ブロックで、この `<instruction>` タグの全文を追記する（最重量工程のため必ず独立Stepで実行する）。

---

## Phase 3: 後処理（全項目を実行してからコミットする）

### 3-A: `docs/_config.json` にナビゲーション登録（必須）
`docs/_config.json` の `nav` 配列の §E.4（データマート・財務諸表）セクションに追記する:

    { "file": "dev/dev_mas-082_plan_bs_journal_pair.md", "title": "E.4.X S-10 計画B/S仕訳振替ペア表示" }

### 3-B: `docs/_internal/changelog.md` への追記
先頭行（ヘッダーの直後）に追記する:

    | 2026-04-19 | [dev_mas-082_plan_bs_journal_pair.md](dev_mas-082_plan_bs_journal_pair.md) | 初版作成。計画B/Sに仕訳振替ペアのB/S科目集計を追加する仕様書 |

### 3-C: コミット＆プッシュ

    git add docs/dev/dev_mas-082_plan_bs_journal_pair.md docs/_internal/changelog.md docs/_config.json
    git commit -m "docs: S-10 計画B/Sに仕訳振替ペアのB/S表示を追加の開発仕様書を作成

    仕訳振替ペアのうちB/S科目（預り金等）を604_datamart_bs.jsの
    計画B/S集計ロジックに追加する仕様。データソース（32_wrk_invoice
    vs 42_trn_journal）はPhase 1調査で確定済み。

    https://claude.ai/code/session_XXXXX"
    git push -u origin docs/dev-S-10