MAS-336: 仕訳振替INV PHASE 1 同月計上 (案2・会計本位)

概要

設計原則: 中小企業会計指針 §第30項 (経過勘定) に準拠し、預り金等の振替仕訳は計算月末 (targetMonthEnd) に計上する。給与支払日 (salaryPayDate) まで認識を遅延させる現行設計は会計指針に反するうえ、未処理 ステータス残存時に取込空振りが発生する構造的脆弱性を持つ。

目的

main ワークスペース実装担当からの起票依頼で 71_bs (実績B/S) 2026-04 の現預金が銀行残高 1,680,108 円より 98,837 円少ない 事象を調査した結果、3 件の根本原因が特定された。本案件はこのうち 97,837 円分 (#1, #2) の構造的解消を行う。残 1,000 円分 (#3) は別案件 (新規 MAS-XXX) で切り出す方針。

構造的脆弱性 (現行設計の問題)

現行設計は仕訳振替 INV を「STL 消込時の PHASE 2 で初めて拾う」二段階処理である:

1. 仕訳振替 INV (預り金 +) は 給与支払日 (salaryPayDate) に発生
2. PHASE 1 (600_report/601_datamart_ingest.js line 71-73 の if (pm === '仕訳振替') continue;) で SKIP される
3. PHASE 2 (line 212-244) で給与 STL 消込時に同一 ORD の仕訳振替 INV を pickup して計上
4. → 仕訳振替 INV のステータスが 未処理 のまま放置されると invIdxMap/invOrdMap から除外され pickup 空振り
5. → 中小企業会計指針 第30項 (経過勘定) では預り金は給与計上日 (targetMonthEnd) に計上すべきだが、現設計では給与支払日まで認識されない
6. → 結果として B/S の現預金見合いの預り金が当月末に立たず、現預金が過小評価される

あるべき会計処理 (中小企業会計指針 §第30項準拠)

役員報酬 50万円・源泉 21,220・社保 74,575・手取 404,205 のケース:

■ 給与計上日 (発生月末・targetMonthEnd) — 1 仕訳で完結
(借) 役員報酬     500,000   |   (貸) 預り金(源泉) 21,220
                              |   (貸) 預り金(社保) 74,575
                              |   (貸) 未払費用    404,205

■ 役員報酬 STL 消込 (翌月15日・salaryPayDate)
(借) 未払費用 404,205   |   (貸) 普通預金 404,205

■ 源泉所得税納付 (翌月10日・別STL)
(借) 預り金(源泉) 21,220   |   (貸) 普通預金 21,220

■ 社保納付 (翌々月末・別STL)
(借) 預り金(社保) 74,575   |   (貸) 普通預金 74,575

本案件はこの会計本位の起票を、(a) RPA 起票時の発生日変更 + (b) ingest の PHASE 1 取込切替 + (c) 既存データの遡及移行、の 3 領域で実現する。

現在のコード

400_domain/401_rpa_hc.js — Row 別の発生日 現状

600_report/601_datamart_ingest.js — PHASE 1 / PHASE 2 / 計画の現状

PHASE 1 (実績 P/L・B/S 即時計上ループ・line 71-80 付近)

// line 71-73 — 仕訳振替を一律スキップ (本案件で削除対象)
var pm = ...;
if (pm === '仕訳振替') continue;

// line 75-80 — B/S は資産計上のみ即時計上 (本案件で '仕訳振替' を追加)
if (isBs && pm !== '資産計上') continue;

PHASE 2 (実績 STL 消込時の仕訳振替 pickup・line 212-244)

// 同一 ORD の仕訳振替 INV を pickup して計上するロジック
// 仕訳振替 INV のステータス = 承認済 のみ invOrdMap に入る
// → 未処理 のまま残ると pickup 空振り (今回の現預金乖離の根本原因)

計画 (dmIngestPlanData_・line 277-392)

// line 302-315 — jePairSet 構築 (B/S 同 ORD ペア除外用・MAS-082 で導入済)
// line 323-325 — 仕訳振替を一律スキップ (本案件で削除対象)
if (pm === '仕訳振替') continue;

注意: line 302-315 に既存の jePairSet (B/S 同 ORD ペア除外ロジック・MAS-082 由来) があり、PHASE 1 仕訳振替取込後の挙動と整合性検討必須。本案件では MAS-082 の jePairSet を温存し、仕訳振替側を計画 PHASE 1 で正規取込みにすることで、jePair 機能 (非仕訳振替 B/S INV の二重計上防止) を活かしたまま実績側に同等のロジックを実装する。

修正方針

5 つの領域に分けて修正する。Step ごとにリリース順序を厳守すること (詳細は §11 実装プロンプト)。

Step A: RPA 起票の発生日修正 (400_domain/401_rpa_hc.js)

Row 1b / 2a / 2b / 3a / 4a の 発生日 を salaryPayDate から targetMonthEnd に変更する。具体的には各 Row の 発生日(P/L計上日) カラム書き込み箇所で salaryPayDate 参照を targetMonthEnd 参照に置換する。

Step B: PHASE 1 で仕訳振替 B/S INV を取込 (600_report/601_datamart_ingest.js)

• line 71-73: if (pm === '仕訳振替') continue; を 削除
• line 75-80: if (isBs && pm !== '資産計上') continue; を if (isBs && pm !== '資産計上' && pm !== '仕訳振替') continue; に変更
• これにより仕訳振替 P/L (Row 1b) は PHASE 1 ループ通常分岐へ・仕訳振替 B/S (Row 2a/2b/3a/4a) は B/S 即時計上分岐へ流れる

Step C: PHASE 2 仕訳振替 pickup の削除 (600_report/601_datamart_ingest.js)

• line 212-244: 仕訳振替 INV pickup ロジック → 完全削除
• 削除しないと PHASE 1 で計上済の仕訳振替 INV が STL 消込時に再度 pickup されて二重計上発生
• (フラグ案 [USE_JE_PHASE1_RECOGNITION 等] による段階移行は不採用 — §10-Q3 参照)

Step D: 計画 ingest の修正 (600_report/601_datamart_ingest.js dmIngestPlanData_)

• line 323-325: if (pm === '仕訳振替') continue; を 削除
• 既存の jePairSet (line 302-315) ロジックは MAS-082 で導入済。これは温存
• 仕訳振替 INV は PHASE 1 で取込・jePair 効果で対応する非仕訳振替 B/S INV (給与本体の B/S 計上分等) は二重計上回避される

Step E: 既存データの遡及移行 (800_ops/822_migration_je_inv_pym.js 新規作成)

過去全月分 (2025-11〜現在) の仕訳振替 INV (Row 1b, 2a, 2b, 3a, 4a 該当) の 発生日(P/L計上日) を salaryPayDate から targetMonthEnd に書き換える冪等な移行スクリプトを新設する。

• ファイル名: 800_ops/822_migration_je_inv_pym.js
• 関数名: migrationJeInvPym()
• 冪等性: 「発生日 ≤ targetMonthEnd かつ ステータス 承認済」の行は touch しない
• ログ出力: Utils.logInfo + SpreadsheetApp.getUi().alert の両方
• メニュー登録: 101_sys_config.js の「🔧 マイグレーション」メニューに追加 (sub では仕様書記載のみ・実装は main 担当)

連携必須項目: applyBankSettlement の合算時差額自動記録 (1,000 円差問題・#3) は本仕様の対象外だが、現預金一致を完成させるため 新規 MAS-XXX として別途起票 することを「修正方針」として明記する。本案件のリリース後に分割案件として実装する。

影響範囲

修正ファイル一覧

影響を受ける出力タブ

影響を受けない出力タブ

• 31_wrk_order (発注残高): 仕訳振替 INV は ORD 残高に影響しないため不変 (§6 注意事項 #7 参照)
• 32_wrk_invoice (INV 一覧): 発生日 列のみが migration で書き換わる
• 33_wrk_bank (STL): 列・値とも変更なし
• 42_trn_journal (仕訳): 既存仕訳の値は不変 (新規発生のみが新ロジックで起票)

注意事項

1. Step A (migration) と Step B (コード変更) を同 PR にしない: prod では migration 未実行のまま新コードが動き、過去仕訳振替 INV が「発生日 = salaryPayDate」のまま PHASE 1 で取込まれて二重計上のリスク。順序は Step E (migration script 実装) → dev 検証 → Step A-D (コード変更 PR) → prod migration 実行 → prod デプロイ の順守が必須。
2. 冪等性: migration script は「発生日 ≤ targetMonthEnd かつ ステータス 承認済 なら touch しない」前提。複数回実行で安全。
3. ロールバック手順を明文化: コードを git revert した場合、PHASE 2 pickup が再活性化して既に PHASE 1 で計上済の仕訳振替が再 pickup される。migration を inverse (発生日を salaryPayDate に戻す) しないと二重計上発生 → revert 手順を仕様書末尾に明記し、PR 説明にも記載必須。
4. 失敗パターン #34 (計画 B/S 構造的乖離) との関係: 本案件は実績側の同種問題 + 計画側 (dmIngestPlanData_) も併修正で計画/実績の整合性維持。決済日_実績 ベースの期ずれ解消ロジック (失敗パターン #34 対策) は温存。
5. Action A との関係: 案 A (RPA 起票時 承認済) を推奨するが、既存 Action A 運用 (給与 INV の人間レビュー workflow) との相互作用の検証が必要 (§10-Q1 参照)。
6. Pass 2.5 ソフト合算差額の落ち穂: 1,000 円差は本仕様 (MAS-336) では対象外。新規 MAS-XXX で別途起票推奨。applyBankSettlement で合算時の差額を 差額(手数料等) 列に自動記録する仕組みを別案件で。本仕様マージ後に prod で 71_bs 検証を行うと、現預金は 1,000 円差 (97,837 円分は解消・1,000 円分は残) となる旨をリリースノートに記載。
7. 31_wrk_order の発注残高との整合性: 仕訳振替 INV は 31_wrk_order 発注残高を減らさない (未決済残高(自動計算) は預り金の累計だが ORD 残高には影響なし) ため、本変更で発注残高は不変。dev 検証で 31_wrk_order の表示値が変わっていないことを確認すること。
8. MAS-090 受取利息源泉の扱い: 受取利息系の源泉所得税 (仮払法人税振替) は別実装 (MAS-090) で扱われるが、設計原則 (発生月計上) は同等であるべき。本案件で給与系のみ修正・MAS-090 系は別途検討 (TODO_future.md にメモ)。
9. 会計指針 §第30項の引用: 経過勘定 (預り金・未払費用) は計算月末に計上する原則 (中小企業会計指針 §30項)。
10. テストランナー追加: 900_test/901_test_runner.js に下記テストケース追加必須:
    • 仕訳振替 INV (Row 2a) が PHASE 1 で正常取込されること
    • PHASE 2 の旧 pickup ロジックが削除されたこと (二重計上回避)
    • migration script の冪等性 (2 回実行しても結果不変)
    • Row 1b 雑収入が前月末で P/L 計上されること
    • jePairSet との整合性 (給与本体 INV と仕訳振替 INV の両方計上時に二重計上しないこと)
11. 完全一致判定: 決済手段 === '仕訳振替' の完全一致 (CLAUDE.md 規約)。String(...).trim() で正規化後も完全一致を維持。
12. 科目マスタ未登録: acctMap[acc] が undefined の場合は黙ってスキップ (既存挙動を維持)。CLAUDE.md「キーワード推測による自動分類禁止」に準拠。
13. isBsForce フラグ: PHASE 1 で B/S 計上する仕訳振替 INV は isBsForce: true を設定。MAS-082 で計画側に導入済の慣例を実績側にも適用。
14. fromSTL フラグ: 旧 PHASE 2 pickup では fromSTL=true でマークしていた。PHASE 1 取込では fromSTL=false (= 通常 INV 扱い) になるため、74_cf_actual 等の集計で差異が出る可能性あり要検証 (§7 エッジケース #12)。
15. prod migration の操作主体: clasp push 後の prod 環境で migration script を実行するのは main ワークスペース実装担当。sub workspace では仕様書のみ作成・GAS 実行は行わない。

エッジケース

計算式 (発生日変更前後)

targetMonthEnd は給与計算月の月末日 (例: 2026-03 給与なら 2026-03-31)・salaryPayDate は支給日 (例: 2026-04-15)。

実データ検証

実装前後で以下のデータシナリオを検証する。dev 環境で先行実施し、検証結果を PR 説明に貼付すること。

シナリオ 1: 3月役員報酬 50万 (95,795 円差)

シナリオ 2: 3月角会計事務所 (2,042 円差)

シナリオ 3: 武生年金事務所 STL 合算 1,000 円差

シナリオ 4: 過去全月遡及 (2025-11〜2026-04)

dev 検証手順

1. dev 環境にデプロイ (npm run push:dev)
2. dev で migrationJeInvPym() 実行 → 実行ログ確認
3. dev で updateAllDatamarts() 再実行 → 71/72/73 タブ確認
4. 単体テスト (901_test_runner.js) 実行 → 全テスト Pass
5. シナリオ 1-4 の期待値を目視で照合
6. 31_wrk_order 発注残高が変わっていないことを確認 (§6-7)

関連ドキュメント

人間が検討すべき事項

Q1. 仕訳振替 INV のデフォルトステータス

推奨: 案A (RPA 起票時から 承認済)。

推奨理由: PHASE 1 で取込前提のため 未処理 残存リスク = 元バグ再発リスク。Action A は P/L 損益認識の人間レビュー (役員報酬妥当性等) の役割であり、預り金等の機械的振替仕訳は人間レビュー価値が低い。

トレードオフ: 「仕訳振替も含めて Action A 必須」運用に既に慣れている場合は案 B もあり。Action A の workflow から仕訳振替が除外されることでオペレータの「全件レビュー」感覚が薄れるリスクがあるため、運用ドキュメントに明記必須。最終判断はユーザー。

Q2. migration script の対象期間

推奨: 過去全月遡及。

推奨理由: 71_bs / 72_bs_snap が遡及的に整合する利点 + dev 環境で先行検証可能 + 過去の決算月を切ってしまうと年次推移グラフが断絶。冪等性確保 (§6-2) が前提。

トレードオフ: 過去の確定済決算 (2025-12 期末等) のデータを書き換えることに抵抗がある場合は案B も検討可。本仕様では monthly snapshot は不変 (72_bs_snap は migration 後に再生成) のため監査性は維持される。最終判断はユーザー。

Q3. PHASE 2 仕訳振替 pickup の処置

推奨: 完全削除 (フラグなし)。

推奨理由: PHASE 1 取込と PHASE 2 pickup の併存は二重計上の温床。フラグは「両方を生かして併存」が一時運用なら検討価値はあるが、全 INV 一括移行の本案件では migration → コード切替の同時リリースが本則。フラグ案は revert 容易性メリットあるがコード複雑性が上回る。

トレードオフ: revert する場合は migration を inverse する必要がある (§6-3 参照)。フラグ案なら code revert のみで戻せる。本仕様ではロールバック手順を明文化することで対応。

Q4. 1,000 円差問題 (Pass 2.5 ソフト合算 差額未記録) の同時対応

推奨: 別仕様で切り出す (新規 MAS-XXX 起票)。

推奨理由: 仕訳振替 PHASE 1 同月計上と Pass 2.5 ソフト合算差額記録は技術的に独立 (前者は ingest ロジック・後者は 502_bank_importer.js の applyBankSettlement) + スコープ肥大による migration リスク増 + ロールバック粒度が下がる。

注: 本仕様の「修正方針」セクション (§4 Step E) で連携必須として明記済。リリースノートでも 1,000 円差は別案件と説明。

Q5. テストケース粒度

901_test_runner.js のテストケース粒度を「単体 (関数レベル)」「統合 (datamart 再生成レベル)」「シナリオ (実データレベル)」のどこに置くか。

推奨: 単体 + 統合の 2 層 (シナリオは手動検証で代替)。

Q6. リリース後の dev/prod 検証期間

prod デプロイ後・migration 実行後の動作確認期間 (回帰検出ウィンドウ) をどれだけ取るか。

推奨: 最低 1 営業日 (1 日分の RPA 起票 + Action A/B + datamart 再生成を 1 サイクル回す)。

Q7. テンプレート v1.7 適用要否

本仕様書はテンプレート v1.7 の Step 分割方針に従わず 1 回出力としているが、後続改訂時に v1.7 ベースに作り直す必要があるか。

推奨: 不要 (テンプレート v1.7 は新規仕様書のサイズ削減目的・本仕様は既に書き終えているため)。

Q8. Action B との相互作用

Action B (33_wrk_bank の自動仕訳生成) は「消込済 かつ 自動仕訳JNL_ID あり」を条件とする (CLAUDE.md 記載)。本変更で仕訳振替 INV が PHASE 1 取込されると、Action B の動作には影響するか。

推奨: 影響なし (Action B は STL ベースで起動・仕訳振替 INV は STL を持たない)。dev 検証で念のため Action B 動作を確認すること。

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

あなたはGAS会計システム(bizlp-gas-accounting)のシニア開発者です。
CLIエージェントである「Claude Code」として、以下の指示に従い、
案件 MAS-336「仕訳振替INV PHASE 1 同月計上 (案2・会計本位)」を
実装してください。

## 重要なリリース順序 (絶対遵守)

本案件は **migration → コード切替** の順序を厳守する必要があります。
Step A-D を 1 つの PR に同梱**しないこと**。
Step E (migration 単独 PR) → dev 検証 → Step A-D (コード切替 PR) → prod 順次の順序です。

| リリース Step | 内容 | 環境 |
|--------------|------|------|
| E1. migration script 実装 PR | `800_ops/822_migration_je_inv_pym.js` 新規 + メニュー登録 | dev → prod |
| E2. dev で migration 実行 | dev データの仕訳振替 INV 発生日を遡及修正 | dev |
| A-D. コード切替 PR | RPA 修正 + ingest 修正 + テスト追加 | dev (PR 作成時) |
| F1. prod migration 実行 | prod データの遡及修正 | prod |
| F2. prod デプロイ | コード切替を prod に反映 | prod |

**Step F1 と F2 の順序を逆にすると prod で二重計上が発生します。**

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

1. 仕様書本体: `docs/dev/dev_mas-336_je_inv_phase1_recognition.md` を全行 Read
2. RPA: `400_domain/401_rpa_hc.js` の Row 1b (228-253) / Row 2a (282-307) /
   Row 2b (255-280) / Row 3a (336-361) / Row 4a (390-415) を Read。各 Row の
   「発生日 (P/L 計上日)」書き込み箇所の行番号を確定する
3. ingest: `600_report/601_datamart_ingest.js` の line 71-80 (PHASE 1 仕訳振替
   スキップ) / line 212-244 (PHASE 2 仕訳振替 pickup) / line 277-392
   (`dmIngestPlanData_` 計画 ingest) を Read
4. メニュー: `100_config/101_sys_config.js` のマイグレーションメニュー
   登録箇所 (804/805/806/807/808 と同パターン) を Read
5. テスト: `900_test/901_test_runner.js` の既存テストパターンを Read
6. プロジェクト規約: `CLAUDE.md`

## Step A: RPA 起票の発生日修正

`400_domain/401_rpa_hc.js` の以下 5 箇所で `発生日(P/L計上日)` カラムへの
書き込み値を `salaryPayDate` から `targetMonthEnd` に置換:

- Row 1b (line 228-253) — 免税事業者益税・雑収入
- Row 2b (line 255-280) — 源泉消費税仮払
- Row 2a (line 282-307) — 源泉所得税預り金
- Row 3a (line 336-361) — 住民税預り金
- Row 4a (line 390-415) — 社保預り金

既存の `targetMonthEnd` 変数を流用 (line 201-226 の Row 1 と同パターン)。
Row 2 (line 309-334) と Row 3 (line 363-388) の `tokureiDeadline` は維持。

## Step B: PHASE 1 で仕訳振替 B/S INV を取込

`600_report/601_datamart_ingest.js`:

- line 71-73: `if (pm === '仕訳振替') continue;` を削除
- line 75-80: `if (isBs && pm !== '資産計上') continue;` を
  `if (isBs && pm !== '資産計上' && pm !== '仕訳振替') continue;` に変更

## Step C: PHASE 2 仕訳振替 pickup の削除

`600_report/601_datamart_ingest.js` の line 212-244 を完全削除。
削除しないと PHASE 1 で計上済の仕訳振替 INV が再 pickup されて二重計上発生。

## Step D: 計画 ingest の修正

`600_report/601_datamart_ingest.js` の `dmIngestPlanData_`:

- line 323-325: `if (pm === '仕訳振替') continue;` を削除
- line 302-315 の `jePairSet` (MAS-082 由来) は温存
- 削除した分岐の代わりに、仕訳振替 B/S INV を planData に push する
  ロジックを追加 (MAS-082 と同パターン)

## Step E: 移行スクリプトの実装

`800_ops/822_migration_je_inv_pym.js` を新規作成:

```js
/**
 * MAS-336 仕訳振替INV PHASE 1 同月計上 移行スクリプト
 * 過去全月の Row 1b/2a/2b/3a/4a 該当 INV の発生日を
 * salaryPayDate から targetMonthEnd に書き換える。
 * 冪等性: 発生日 ≤ targetMonthEnd かつ ステータス 承認済 で skip。
 */
function migrationJeInvPym() {
  // 1. 32_wrk_invoice 全行を取得
  // 2. 決済手段 === '仕訳振替' AND 親発注ID(ORD) が HC ORD であるレコード抽出
  // 3. 各レコードの targetMonthEnd を ORD から逆算
  // 4. 発生日 が salaryPayDate のものを targetMonthEnd に更新
  // 5. ログ出力 (Utils.logInfo + UI alert 両方)
  // 6. 冪等性ガード: 発生日 ≤ targetMonthEnd ならスキップ
}
```

実装パターンは `800_ops/804_migration_d01_d03.js` を参照。
`100_config/101_sys_config.js` の「🔧 マイグレーション」メニューに追加。

## Step F: テストケース追加

`900_test/901_test_runner.js` に下記テストケースを追加:

1. 仕訳振替 INV (Row 2a) が PHASE 1 で正常取込されること
2. PHASE 2 の旧 pickup ロジックが削除されたこと (二重計上回避)
3. migration script の冪等性 (2 回実行で結果不変)
4. Row 1b 雑収入が前月末で P/L 計上されること
5. jePairSet との整合性

## 制約

- `400_domain/`, `600_report/`, `800_ops/`, `100_config/`, `900_test/` 以外
  触らない
- 列参照はヘッダー名ベース (`indexOf` / `buildHeaderIndex_`)
- `決済手段 === '仕訳振替'` 完全一致のみ (CLAUDE.md 規約)
- 科目マスタ未登録は黙ってスキップ (エラーにしない)

## ロールバック手順 (必読)

`git revert` 単独では prod で二重計上発生。手順:

1. prod の本コード切替 PR を `git revert`
2. `800_ops/822_migration_je_inv_pym.js` の inverse 関数
   (`migrationJeInvPymRevert()`) を新規作成し prod 実行
3. 71_bs / 72_bs_snap 再生成

## 動作確認

1. dev: `npm run push:dev` → `migrationJeInvPym()` 実行 → 実行ログ確認
2. dev: `updateAllDatamarts()` 実行 → 71/72/73 タブ確認
3. dev: `901_test_runner.js` 実行 → 全テスト Pass
4. dev: シナリオ 1-4 の期待値を目視で照合
5. dev: 31_wrk_order 発注残高が不変であることを確認
6. dev: Action B (33_wrk_bank 自動仕訳生成) 動作確認
7. PR レビュー → main マージ → prod 順次リリース (Step F1 → F2)

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

| フェーズ | 拡張思考 | 備考 |
|---------|---------|------|
| 実行前タスク (Read) | あり | 行番号と既存ロジックの理解 |
| Step A (RPA) | なし | 仕様書のコード例を書き下す |
| Step B-D (ingest) | あり | jePairSet との整合性確認のため |
| Step E (migration) | あり | 冪等性ガードの設計のため |
| Step F (テスト) | なし | 仕様書のテストケースを書き下す |
| 動作確認 | ユーザー手動 | dev/prod の実データ目視確認 |

推奨実行モデル

変更履歴

仕様書作成プロンプト

あなたは bizlp-gas-accounting プロジェクトの仕様書起票担当です。新規仕様書 **MAS-336: 仕訳振替INV PHASE 1 同月計上 (案2・会計本位)** の本体を起草し、ファイルに書き出してください。

## ゴール
`docs/dev/dev_mas-336_je_inv_phase1_recognition.md` を新規作成。約 600〜800 行・14 セクション全網羅・`docs/_internal/dev_spec_prompt_template.md` のテンプレート遵守。

## 背景 (起票依頼の要約)
main ワークスペース実装担当からの依頼。71_bs (実績B/S) 2026-04 で現預金が銀行残高 1,680,108 円 より **98,837 円少ない** 事象を調査し、3 件の根本原因を特定:

| # | 金額 | 原因 |
|---|---:|---|
| 1 | 95,795 | 3月役員報酬 仕訳振替 INV (源泉預り 21,220 + 社保預り 74,575) が `未処理` で `invOrdMap` から除外され、PHASE 2 仕訳振替 pickup が空振り |
| 2 | 2,042 | 3月角会計事務所 月額給与 仕訳振替 INV (源泉消費税益税 2,000 + 源泉所得税預り 42) も同様 |
| 3 | 1,000 | 武生年金事務所 STL 合算 (74,575+76,375=150,950) と銀行引落額 149,950 の差を `差額(手数料等)` 列に記録していない (Pass 2.5 ソフト合算消込時の落ち穂) |
| 計 | 98,837 | ✓ |

## 構造的脆弱性
現行設計は仕訳振替 INV を「STL 消込時の PHASE 2 で初めて拾う」二段階処理:
- 仕訳振替 INV (預り金+) は給与支払日 (`salaryPayDate`) 発生
- PHASE 1 (`600_report/601_datamart_ingest.js` line 71-73 の `if (pm === '仕訳振替') continue;`) で SKIP
- PHASE 2 (line 212-244) で給与 STL 消込時に同一 ORD の仕訳振替 INV を pickup して計上
- → 仕訳振替 INV のステータスが `未処理` のまま放置されると `invIdxMap`/`invOrdMap` から除外され pickup 空振り
- → 中小企業会計指針 第30項 (経過勘定) では預り金は給与**計上**日 (`targetMonthEnd`) に計上すべきだが、現設計では給与**支払**日まで認識されない

ユーザーは **案 2 (会計本位)** を選択 — 仕訳振替 INV を給与 INV と同月発生にし、PHASE 1 で B/S 即時計上に変更する。

## 検証済みの実装コード参照 (ここを正確に仕様書に記載すること)

### `400_domain/401_rpa_hc.js` (Row 別の 発生日 現状)
- **Row 1 (月額給与本体)** line 201-226: `発生日 = targetMonthEnd` ✅ (既に正しい)
- **Row 1b (免税事業者益税・雑収入)** line 228-253: `発生日 = salaryPayDate` ⚠️ → 要 `targetMonthEnd` 化 (P/L 雑収入も発生月計上)
- **Row 2b (源泉消費税仮払)** line 255-280: `発生日 = salaryPayDate` ⚠️ → 要 `targetMonthEnd` 化 (B/S 仮払消費税等)
- **Row 2a (源泉所得税預り金)** line 282-307: `発生日 = salaryPayDate` ⚠️ → 要 `targetMonthEnd` 化 (B/S 預り金+)
- **Row 2 (源泉所得税納付・-)** line 309-334: `発生日 = tokureiDeadline` ✅ (納付日でOK・別案件)
- **Row 3a (住民税預り金)** line 336-361: `発生日 = salaryPayDate` ⚠️ → 要 `targetMonthEnd` 化
- **Row 3 (住民税納付・-)** line 363-388: `tokureiDeadline` ✅
- **Row 4a (社保預り金)** line 390-415: `発生日 = salaryPayDate` ⚠️ → 要 `targetMonthEnd` 化

### `600_report/601_datamart_ingest.js`
- **PHASE 1 (line 71-73)**: `if (pm === '仕訳振替') continue;` → **削除**
- **PHASE 1 (line 75-80)**: `if (isBs && pm !== '資産計上') continue;` を `if (isBs && pm !== '資産計上' && pm !== '仕訳振替') continue;` に変更 (仕訳振替 BS も即時計上)
- **PHASE 2 (line 212-244)**: 仕訳振替 INV pickup ロジック → **削除** (PHASE 1 で計上済のため二重計上回避)
- **dmIngestPlanData_ (line 277-392・特に line 323-325)**: `if (pm === '仕訳振替') continue;` → **削除**
  - 注意: line 302-315 に既存の `jePairSet` (B/S 同 ORD ペア除外ロジック) あり・PHASE 1 仕訳振替取込後の挙動と整合性検討必須

## 案件番号・ファイル番号 (確定済)
- 案件 ID: **MAS-336** (max MAS-335・衝突なし)
- migration script: **`800_ops/822_migration_je_inv_pym.js`** (依頼の 810 は既使用・821 まで使用済・822 が次の空き)

## あるべき会計処理 (中小企業会計指針 第30項準拠)
役員報酬 50万円・源泉 21,220・社保 74,575・手取 404,205 のケース:

## sub 側で判断する論点 (4 項目)
仕様書「人間が検討すべき事項」または「修正方針」セクションに **推奨 + トレードオフ + 推奨理由** で記述:

### Q1. 仕訳振替 INV のデフォルトステータス
- 案A: RPA 起票時から `承認済`。Action A 不要
- 案B: Action A で給与INVと同期して承認済化
- **推奨**: 案A (RPA 起票時から `承認済`)。理由: PHASE 1 で取込前提のため `未処理` 残存リスク = 元バグ再発リスク。Action A は P/L 損益認識の人間レビュー (役員報酬妥当性等) の役割であり、預り金等の機械的振替仕訳は人間レビュー価値が低い。一方で「仕訳振替も含めて Action A 必須」運用に既に慣れている場合は案 B もあり。**最終判断はユーザー**

### Q2. migration script の対象期間
- 過去全月遡及 (2025-11〜現在)
- 特定月以降のみ (e.g., 2026-01以降)
- **推奨**: 過去全月遡及。理由: 71_bs / 72_bs_snap が遡及的に整合する利点 + dev 環境で先行検証可能 + 過去の決算月を切ってしまうと年次推移グラフが断絶。冪等性確保が前提

### Q3. PHASE 2 仕訳振替 pickup の処置
- 完全削除
- フラグ (`USE_JE_PHASE1_RECOGNITION` 等) で段階移行
- **推奨**: 完全削除 (フラグなし)。理由: PHASE 1 取込と PHASE 2 pickup の併存は二重計上の温床 + フラグは「両方を生かして併存」が一時運用なら検討価値はあるが、全 INV 一括移行の本案件では migration → コード切替の同時リリースが本則。フラグ案は revert 容易性メリットあるがコード複雑性が上回る

### Q4. 1,000 円差問題 (Pass 2.5 ソフト合算 差額未記録) の同時対応
- 本仕様で同時対応 (`applyBankSettlement` の合算時差額自動記録を含める)
- 別仕様で切り出す
- **推奨**: 別仕様で切り出す (新規 MAS-XXX 起票)。理由: 仕訳振替 PHASE 1 同月計上と Pass 2.5 ソフト合算差額記録は技術的に独立 (前者は ingest ロジック・後者は 502_bank_importer.js の applyBankSettlement) + スコープ肥大による migration リスク増 + ロールバック粒度が下がる。**ただし本仕様の「修正方針」セクションで連携必須として明記**

## 仕様書テンプレート構成 (14 セクション必須)

## frontmatter (先頭)
```yaml
---
id: MAS-336
aliases: ["JE-INV-PHASE1"]
type: Story
status: Open
---

</details>