Phase 0: 販売帳票PDF・値引・納品書連携・端数統一

joe commented

2026-09-20 05:58:59 +00:00

Owner

概要

販売管理の実務フロー（見積→受注→納品→請求→適格請求書）を弥生販売に並ぶ水準へ。帳票PDF・値引・端数統一を実装。

対応内容

共通PDF基盤＋発行者設定（InvoiceSetting 拡張、/invoice-settings 画面・API）
見積書PDF GET /api/quotations/{id}/pdf
納品書PDF GET /api/delivery-notes/{id}/pdf ＋納品書一覧API・画面・ナビ
請求書（通常）PDF GET /api/billing/{id}/pdf（適格請求書は維持）
値引・端数調整の共有計算サービス（明細額/率・伝票額/率は置換・端数調整、h1仕様）
見積/受注/請求/適格請求書へ値引を反映（total = subtotal - discount + tax）
受注 deliver で納品書を自動作成・紐付け（二重計上防止: source=sales_order, completed）
消費税端数処理を税率グループ1回丸めに統一（InvoiceSetting.rounding_method 準拠）

テスト結果

全 5733 passed（主要サブセット再確認 67 passed）
migration 4本 upgrade/downgrade 検証済み（a3f8c1d20b47, b8e2d6f0a4c1, d4b7e2c9f0a1, e1a2b3c4d5f6）
docs/openapi.json 再生成済み

既知の設計課題（次フェーズ）

在庫減算の責務が未統一（納品 vs 出庫完了）
Customer と Counterparty の二重管理
受注キャンセル時に納品書が残る

次のステップ

入金消込の専用UI（Phase 0 の残り）
Phase 1（h1⇔o2 同期＋監査）設計：ADR＋詳細設計

## 概要販売管理の実務フロー（見積→受注→納品→請求→適格請求書）を弥生販売に並ぶ水準へ。帳票PDF・値引・端数統一を実装。 ## 対応内容 - [x] 共通PDF基盤＋発行者設定（`InvoiceSetting` 拡張、`/invoice-settings` 画面・API） - [x] 見積書PDF `GET /api/quotations/{id}/pdf` - [x] 納品書PDF `GET /api/delivery-notes/{id}/pdf` ＋納品書一覧API・画面・ナビ - [x] 請求書（通常）PDF `GET /api/billing/{id}/pdf`（適格請求書は維持） - [x] 値引・端数調整の共有計算サービス（明細額/率・伝票額/率は置換・端数調整、h1仕様） - [x] 見積/受注/請求/適格請求書へ値引を反映（`total = subtotal - discount + tax`） - [x] 受注 `deliver` で納品書を自動作成・紐付け（二重計上防止: `source=sales_order`, completed） - [x] 消費税端数処理を税率グループ1回丸めに統一（`InvoiceSetting.rounding_method` 準拠） ## テスト結果 - 全 5733 passed（主要サブセット再確認 67 passed） - migration 4本 upgrade/downgrade 検証済み（`a3f8c1d20b47`, `b8e2d6f0a4c1`, `d4b7e2c9f0a1`, `e1a2b3c4d5f6`） - `docs/openapi.json` 再生成済み ## 関連コミット - `c141999` 販売帳票PDF・値引・納品書連携 - `ebd0c75` 請求書・適格請求書への値引反映 - `16d8963` 消費税端数処理の統一 - main マージ `c4f1b9a`（push 済み） ## 既知の設計課題（次フェーズ） - 在庫減算の責務が未統一（納品 vs 出庫完了） - `Customer` と `Counterparty` の二重管理 - 受注キャンセル時に納品書が残る ## 次のステップ - 入金消込の専用UI（Phase 0 の残り） - Phase 1（h1⇔o2 同期＋監査）設計：ADR＋詳細設計

joe commented

2026-09-20 05:59:05 +00:00

Author

Owner

完了

Phase 0 を main にマージ（--no-ff, c4f1b9a）し、origin/main へ push 済み。

全テスト: 5733 passed
migration 4本（upgrade/downgrade 検証済み）
OpenAPI 再生成済み

次の対応

入金消込の専用UI（Phase 0 の残り）
Phase 1: h1⇔o2 同期＋監査アーキテクチャ（ADR＋詳細設計）

## 完了 Phase 0 を main にマージ（`--no-ff`, `c4f1b9a`）し、`origin/main` へ push 済み。 - 全テスト: **5733 passed** - migration 4本（upgrade/downgrade 検証済み） - OpenAPI 再生成済み ## 次の対応 - 入金消込の専用UI（Phase 0 の残り） - Phase 1: h1⇔o2 同期＋監査アーキテクチャ（ADR＋詳細設計）

joe commented

2026-09-20 07:34:10 +00:00

Author

Owner

追記: 入金消込（Phase 0 完了）

入金消込の専用UIと自動割当APIを追加し、main にマージ（--no-ff, ad9720f）・push 済み。

allocate_receipt: 1回の入金を未収の複数請求へ期日順に自動割当、仕訳は1本（貸方売掛金 / 借方現金・預金）
GET /api/billing/outstanding / POST /api/billing/receipts/allocate
/receipts 画面（自動割当プレビュー・部分入金・消込実行）＋ナビ「入金消込」
全テスト: 5757 passed

これで Phase 0（販売管理の実務フロー）完了。次は Phase 1（h1⇔o2 同期＋監査）の設計。

## 追記: 入金消込（Phase 0 完了）入金消込の専用UIと自動割当APIを追加し、main にマージ（`--no-ff`, `ad9720f`）・push 済み。 - `allocate_receipt`: 1回の入金を未収の複数請求へ期日順に自動割当、仕訳は1本（貸方売掛金 / 借方現金・預金） - `GET /api/billing/outstanding` / `POST /api/billing/receipts/allocate` - `/receipts` 画面（自動割当プレビュー・部分入金・消込実行）＋ナビ「入金消込」 - 全テスト: **5757 passed** これで Phase 0（販売管理の実務フロー）完了。次は Phase 1（h1⇔o2 同期＋監査）の設計。

joe commented

2026-09-20 21:47:53 +00:00

Author

Owner

追記: ドキュメント整備

Phase 0/1 の実装を反映してドキュメントを整備し、main にマージ・push 済み（--no-ff, 55962c6）。

README.md: 販売管理の重複セクション統合、帳票PDF/値引/納品書/入金消込/端数統一を追記、h1-c2 連携・同期・監査(Phase 1)節、テスト数(5810)・画面一覧更新
docs/ARCHITECTURE.md: 同期・監査(Phase 1)節と新モジュール
docs/OPERATIONS.md: 端末トークン・同期・監査の運用手順
AGENTS.md: 販売計算・帳票(Phase 0)／同期・監査(Phase 1)の規約、h1 連携を現行化
docs/README.md: ADR/specs/Phase 1 設計への索引
新規設計文書: docs/adr/0001-sync-audit-mode-issuance.md、docs/specs/sales-calculation.md、docs/superpowers/specs/2026-09-20-phase1-sync-audit-design.md

残（後続）: h1 側 Dart 実装、型付きモデルへの射影、DocumentIssuance＋Google OAuth/Gmail、e-Tax。

## 追記: ドキュメント整備 Phase 0/1 の実装を反映してドキュメントを整備し、main にマージ・push 済み（`--no-ff`, `55962c6`）。 - `README.md`: 販売管理の重複セクション統合、帳票PDF/値引/納品書/入金消込/端数統一を追記、h1-c2 連携・同期・監査(Phase 1)節、テスト数(5810)・画面一覧更新 - `docs/ARCHITECTURE.md`: 同期・監査(Phase 1)節と新モジュール - `docs/OPERATIONS.md`: 端末トークン・同期・監査の運用手順 - `AGENTS.md`: 販売計算・帳票(Phase 0)／同期・監査(Phase 1)の規約、h1 連携を現行化 - `docs/README.md`: ADR/specs/Phase 1 設計への索引 - 新規設計文書: `docs/adr/0001-sync-audit-mode-issuance.md`、`docs/specs/sales-calculation.md`、`docs/superpowers/specs/2026-09-20-phase1-sync-audit-design.md` 残（後続）: h1 側 Dart 実装、型付きモデルへの射影、`DocumentIssuance`＋Google OAuth/Gmail、e-Tax。

joe commented

2026-09-21 02:11:16 +00:00

Author

Owner

追記: Phase 1d（帳票発行一元化・Google OAuth/Gmail）

main にマージ・push 済み（0cf5ef5, ドキュメント c1e1f0c）。全 5864 passed。

1d-1 発行一元化

DocumentIssuance（発行者/端末/チャネル/方法/状態）＋ migration d1e2f3a4b5c6
POST/GET /api/issuance・/summary、担当者端末へ SyncOutbox 通知、/issuance 発行履歴画面
請求発行フックで記録（PDFダウンロードは過剰計上のため見送り）

1d-2 Google/Gmail

GoogleCredential（テナント×用途、トークン Fernet 暗号化）＋ migration a7b8c9d0e1f2
google_oauth_service（認可URL・state検証・コード交換・refresh）、gmail_service（帳票PDF添付送信）
/api/google/{authorize,callback,status,disconnect}、POST /api/issuance/send、/google-settings 画面、請求一覧のメール送信ボタン
httpx を実行時依存に追加

注意

Google API は fake 注入でテスト済み・実接続は未検証（OAuth クライアント登録・コールバックのトークン引き回しは運用時に対応）

残（後続）

h1 側 Dart 実装、型付きモデルへの射影、Drive/Sheets、手動名寄せUI、e-Tax（最後）

## 追記: Phase 1d（帳票発行一元化・Google OAuth/Gmail） main にマージ・push 済み（`0cf5ef5`, ドキュメント `c1e1f0c`）。全 **5864 passed**。 ### 1d-1 発行一元化 - `DocumentIssuance`（発行者/端末/チャネル/方法/状態）＋ migration `d1e2f3a4b5c6` - `POST/GET /api/issuance`・`/summary`、担当者端末へ `SyncOutbox` 通知、`/issuance` 発行履歴画面 - 請求発行フックで記録（PDFダウンロードは過剰計上のため見送り） ### 1d-2 Google/Gmail - `GoogleCredential`（テナント×用途、トークン Fernet 暗号化）＋ migration `a7b8c9d0e1f2` - `google_oauth_service`（認可URL・state検証・コード交換・refresh）、`gmail_service`（帳票PDF添付送信） - `/api/google/{authorize,callback,status,disconnect}`、`POST /api/issuance/send`、`/google-settings` 画面、請求一覧のメール送信ボタン - `httpx` を実行時依存に追加 ### 注意 - **Google API は fake 注入でテスト済み・実接続は未検証**（OAuth クライアント登録・コールバックのトークン引き回しは運用時に対応） ### 残（後続） - h1 側 Dart 実装、型付きモデルへの射影、Drive/Sheets、手動名寄せUI、e-Tax（最後）

joe commented

2026-09-21 03:21:50 +00:00

Author

Owner

h1 ⇄ o2 実通信を確認（2026-09-21）

h1 と o2 の Phase 1 同期の実通信に成功しました。

h1 側実装（別リポジトリ joe/h1-c2）: 端末登録 / push / pull / 承認キュー / 発行報告（POST /api/issuance 直呼び＋o2_issuance_queue 退避、o2_api_key で api-key-login 再取得）
発行報告は 方式(a)（/api/issuance 直呼び）に一本化。o2 側で試作した push 取込は二重経路回避のため revert（1ccd027）
ドキュメント: ADR-0001 を Accepted（Phase 1a〜1d 実装済み・実通信確認）に更新、README/ARCHITECTURE/設計書に実装状況を追記（4635025）

残（後続）

型付きモデルへの射影、SyncOutbox 自動生成（監査/修正の自動配信）、Drive/Sheets、Google 実接続検証、e-Tax。

## h1 ⇄ o2 実通信を確認（2026-09-21） h1 と o2 の Phase 1 同期の**実通信に成功**しました。 - h1 側実装（別リポジトリ `joe/h1-c2`）: 端末登録 / push / pull / 承認キュー / 発行報告（`POST /api/issuance` 直呼び＋`o2_issuance_queue` 退避、`o2_api_key` で `api-key-login` 再取得） - 発行報告は **方式(a)（`/api/issuance` 直呼び）に一本化**。o2 側で試作した push 取込は二重経路回避のため revert（`1ccd027`） - ドキュメント: ADR-0001 を **Accepted**（Phase 1a〜1d 実装済み・実通信確認）に更新、README/ARCHITECTURE/設計書に実装状況を追記（`4635025`） ### 残（後続）型付きモデルへの射影、`SyncOutbox` 自動生成（監査/修正の自動配信）、Drive/Sheets、Google 実接続検証、e-Tax。

joe commented

2026-09-22 05:29:58 +00:00

Author

Owner

追記: Phase 1e（h1 データの射影・会計統合・監督）

main にマージ・push 済み。全 5958 passed。

1e-1 マスタ射影: push の accepted 時に Product/Counterparty へ upsert（論理キー code or id）
1e-2 統合伝票ビュー: GET /api/h1-documents（読み取り専用）＋ /h1-documents 画面
1e-3 会計射影: h1 伝票 → o2 仕訳（salesSlip→売掛金/売上、paymentReceipt→現金/売掛金）。H1JournalLink(tenant_id, source_uuid) で冪等（二重計上なし）。migration e2f3a4b5c6d7
1e-4 監督: GET /api/sync/supervision/{summary,duplicates} / POST .../scan、端末間重複検出＋AuditFinding(kind=duplicate)、/h1-supervision 画面
実データ検証で判明した不具合修正: 集約キーを code→id フォールバックに（0a39f19）
開発用テストクレデンシャル発行: scripts/issue_test_credentials.py（8473c50）
設計書: docs/superpowers/specs/2026-09-21-phase1e-projection-design.md（二重計上ポリシー含む）
ドキュメント: ADR-0001 実装状況に 1e-1〜1e-4 を追記（4ce8c12）

残（後続）

SyncOutbox 自動生成（監査/修正の自動配信）、Drive/Sheets、Google 実接続検証、e-Tax（最後）。

## 追記: Phase 1e（h1 データの射影・会計統合・監督） main にマージ・push 済み。全 **5958 passed**。 - **1e-1 マスタ射影**: push の accepted 時に `Product`/`Counterparty` へ upsert（論理キー `code or id`） - **1e-2 統合伝票ビュー**: `GET /api/h1-documents`（読み取り専用）＋ `/h1-documents` 画面 - **1e-3 会計射影**: h1 伝票 → o2 仕訳（`salesSlip`→売掛金/売上、`paymentReceipt`→現金/売掛金）。`H1JournalLink(tenant_id, source_uuid)` で冪等（二重計上なし）。migration `e2f3a4b5c6d7` - **1e-4 監督**: `GET /api/sync/supervision/{summary,duplicates}` / `POST .../scan`、端末間重複検出＋`AuditFinding(kind=duplicate)`、`/h1-supervision` 画面 - 実データ検証で判明した不具合修正: 集約キーを `code`→`id` フォールバックに（`0a39f19`） - 開発用テストクレデンシャル発行: `scripts/issue_test_credentials.py`（`8473c50`） - 設計書: `docs/superpowers/specs/2026-09-21-phase1e-projection-design.md`（二重計上ポリシー含む） - ドキュメント: ADR-0001 実装状況に 1e-1〜1e-4 を追記（`4ce8c12`） ### 残（後続） `SyncOutbox` 自動生成（監査/修正の自動配信）、Drive/Sheets、Google 実接続検証、e-Tax（最後）。

joe commented

2026-09-22 15:04:43 +00:00

Author

Owner

追記: G3（Google）拡張と競合自動配信

main にマージ・push 済み。全 5998 passed。

競合修正の自動配信（SyncOutbox 自動生成）: POST /api/sync/corrections/dispatch（集約の端末間マスタ競合を LWW 勝者に揃えて h1 承認キューへ。pending 冪等）
G3 Google 拡張:
- Gmail 帳票送信（/api/issuance/send）
- Drive 帳票保管（/api/issuance/archive、purpose=drive）
- Sheets エクスポート（POST /api/export/sheets/h1-documents、purpose=sheets）
- purpose 別スコープ（gmail/drive/sheets）
実接続検証ツール: scripts/verify_google_connection.py（--check-config / --send-to）
ドキュメント: ADR-0001 実装状況に G3 と自動配信を追記（3c3b4be）

残

e-Tax（最後。実提出は電子証明書・国税庁接続が外部依存）。Google 実接続検証はクレデンシャル設定後に実施。

## 追記: G3（Google）拡張と競合自動配信 main にマージ・push 済み。全 **5998 passed**。 - **競合修正の自動配信（`SyncOutbox` 自動生成）**: `POST /api/sync/corrections/dispatch`（集約の端末間マスタ競合を LWW 勝者に揃えて h1 承認キューへ。pending 冪等） - **G3 Google 拡張**: - Gmail 帳票送信（`/api/issuance/send`） - Drive 帳票保管（`/api/issuance/archive`、`purpose=drive`） - Sheets エクスポート（`POST /api/export/sheets/h1-documents`、`purpose=sheets`） - purpose 別スコープ（gmail/drive/sheets） - **実接続検証ツール**: `scripts/verify_google_connection.py`（`--check-config` / `--send-to`） - ドキュメント: ADR-0001 実装状況に G3 と自動配信を追記（`3c3b4be`） ### 残 **e-Tax**（最後。実提出は電子証明書・国税庁接続が外部依存）。**Google 実接続検証**はクレデンシャル設定後に実施。

joe commented

2026-09-22 17:18:32 +00:00

Author

Owner

追記: e-Tax（棚卸しと統合修正）

main にマージ・push 済み。全 6012 passed。

棚卸し（`docs/superpowers/specs/2026-09-21-etax-status.md`）

実装済み: XML 生成（青色/消費税/法人）、簡易検証、RSA-2048/SHA-256 署名（フェイルクローズ）、提出準備の永続化、送信、参考様式 PDF、独自 XBRL
外部依存でブロック: 電子証明書読取（PKCS#11/PKCS#12）、国税庁 API 実接続、公式 xsd/タクソノミ検証、XMLDSig 正式署名（現状は XML 末尾コメント付加で非準拠）、eLTAX/光ディスク

今回の統合修正（外部非依存）

提出準備で summary_data を永続化 → XBRL 付表連携が成立
送信結果を TaxReturn.status/submission_log_id に連動（SENT→SUBMITTED、ACCEPTED→ACCEPTED、ERROR→PREPARED）
送信 endpoint を O2_ETAX_ENDPOINT で設定可能に（未設定はダミー）
ドキュメント: README/AGENTS/docs索引に e-Tax 節を追記（fc64377）

残（別フェーズ）

XMLDSig 正式署名化、公式スキーマ検証、電子証明書読取、国税庁 API 実接続。実提出は不可（外部依存）。

## 追記: e-Tax（棚卸しと統合修正） main にマージ・push 済み。全 **6012 passed**。 ### 棚卸し（`docs/superpowers/specs/2026-09-21-etax-status.md`） - 実装済み: XML 生成（青色/消費税/法人）、簡易検証、RSA-2048/SHA-256 署名（フェイルクローズ）、提出準備の永続化、送信、参考様式 PDF、独自 XBRL - **外部依存でブロック**: 電子証明書読取（PKCS#11/PKCS#12）、国税庁 API 実接続、公式 xsd/タクソノミ検証、**XMLDSig 正式署名**（現状は XML 末尾コメント付加で非準拠）、eLTAX/光ディスク ### 今回の統合修正（外部非依存） - 提出準備で `summary_data` を永続化 → XBRL 付表連携が成立 - 送信結果を `TaxReturn.status`/`submission_log_id` に連動（SENT→SUBMITTED、ACCEPTED→ACCEPTED、ERROR→PREPARED） - 送信 endpoint を `O2_ETAX_ENDPOINT` で設定可能に（未設定はダミー） - ドキュメント: README/AGENTS/docs索引に e-Tax 節を追記（`fc64377`） ### 残（別フェーズ） XMLDSig 正式署名化、公式スキーマ検証、電子証明書読取、国税庁 API 実接続。**実提出は不可**（外部依存）。

joe commented

2026-09-22 18:21:42 +00:00

Author

Owner

追記: 既知の設計課題の修正と実データ取扱い

main にマージ・push 済み。全 6019 passed。

設計課題の修正

在庫減算の責務を統一: 受注 deliver で、在庫管理対象（在庫行あり）の通常商品を StockMovement(SALES_OUT) で減算。セット商品は構成商品のみ消費（排他）。在庫行が無い商品はスキップ、不足は OrderError（2ec37c7）
受注キャンセルと納品書: DELIVERED/INVOICED の cancel で受注由来納品書を取消＋売上仕訳の逆仕訳（借方売上 / 貸方売掛金）を作成し帳簿を整合（88602d7）
残: Customer/Counterparty 二重管理（未対応。マスタ射影は Counterparty）

実データの取扱い

.gitignore を強化: *.db.*（o2.db.bak-*）/*.db-wal|shm|journal/*.sqlite3、*.pem/*.key/*.p12/*.pfx、data//uploads//logs//*.log、.env（8f84826）
docs/OPERATIONS.md に「実データの取扱い」を追記（DB はリポジトリ外パス推奨、鍵は外パス）
ドキュメント: ADR 既知課題を更新（06b9c02）

次

残る設計課題は Customer/Counterparty 二重管理のみ（大規模・要設計）。

## 追記: 既知の設計課題の修正と実データ取扱い main にマージ・push 済み。全 **6019 passed**。 ### 設計課題の修正 - **在庫減算の責務を統一**: 受注 `deliver` で、在庫管理対象（在庫行あり）の通常商品を `StockMovement(SALES_OUT)` で減算。セット商品は構成商品のみ消費（排他）。在庫行が無い商品はスキップ、不足は `OrderError`（`2ec37c7`） - **受注キャンセルと納品書**: `DELIVERED`/`INVOICED` の cancel で受注由来納品書を取消＋売上仕訳の**逆仕訳**（借方売上 / 貸方売掛金）を作成し帳簿を整合（`88602d7`） - 残: **`Customer`/`Counterparty` 二重管理**（未対応。マスタ射影は `Counterparty`） ### 実データの取扱い - `.gitignore` を強化: `*.db.*`（`o2.db.bak-*`）/`*.db-wal|shm|journal`/`*.sqlite3`、`*.pem`/`*.key`/`*.p12`/`*.pfx`、`data/`/`uploads/`/`logs/`/`*.log`、`.env`（`8f84826`） - `docs/OPERATIONS.md` に「実データの取扱い」を追記（DB はリポジトリ外パス推奨、鍵は外パス） - ドキュメント: ADR 既知課題を更新（`06b9c02`） ### 次残る設計課題は `Customer`/`Counterparty` 二重管理のみ（大規模・要設計）。

joe commented

2026-09-22 19:41:28 +00:00

Author

Owner

追記: 残課題の自律対応

main にマージ・push 済み。全 6057 passed。

1. Customer/Counterparty 二重管理（段階解消）

Counterparty を正典とし、legacy Customer の create/update を同一 Tx で Counterparty に同期（customer_counterparty_sync）
既存 Customer を Counterparty へバックフィルする migration b1a2c3d4e5f6（冪等）
逆方向（Counterparty→Customer）と完全統合は今後（4d2b5be）

2. e-Tax 署名・証明書・スキーマ

XMLDSig 正式署名（xmldsig_service: enveloped / rsa-sha256 / exc-c14n）。証明書があれば XMLDSig、無ければ legacy コメント署名（フェイルクローズ維持）
PKCS#12 証明書読込（O2_ETAX_PKCS12_PATH/PASSWORD、O2_ETAX_CERT_PATH）
公式 xsd 検証フック（O2_ETAX_XSD_DIR/O2_ETAX_XSD_PATH。配置すれば検証、無ければスキップ）
signxml/lxml を依存に追加（87824f5, a116ba0）
到達点/不足を更新（68f9b10）

残（外部依存）

IC カード読取（PKCS#11）、国税庁 API 実接続、公式 xsd の入手、e-Tax 仕様への完全適合検証、Google 実接続（クレデンシャル）、Counterparty→Customer 逆同期。

## 追記: 残課題の自律対応 main にマージ・push 済み。全 **6057 passed**。 ### 1. Customer/Counterparty 二重管理（段階解消） - `Counterparty` を正典とし、legacy `Customer` の create/update を同一 Tx で `Counterparty` に同期（`customer_counterparty_sync`） - 既存 `Customer` を `Counterparty` へバックフィルする migration `b1a2c3d4e5f6`（冪等） - **逆方向（Counterparty→Customer）と完全統合は今後**（`4d2b5be`） ### 2. e-Tax 署名・証明書・スキーマ - **XMLDSig 正式署名**（`xmldsig_service`: enveloped / rsa-sha256 / exc-c14n）。証明書があれば XMLDSig、無ければ legacy コメント署名（フェイルクローズ維持） - **PKCS#12 証明書読込**（`O2_ETAX_PKCS12_PATH`/`PASSWORD`、`O2_ETAX_CERT_PATH`） - **公式 xsd 検証フック**（`O2_ETAX_XSD_DIR`/`O2_ETAX_XSD_PATH`。配置すれば検証、無ければスキップ） - `signxml`/`lxml` を依存に追加（`87824f5`, `a116ba0`） - 到達点/不足を更新（`68f9b10`） ### 残（外部依存） IC カード読取（PKCS#11）、国税庁 API 実接続、公式 xsd の入手、e-Tax 仕様への完全適合検証、Google 実接続（クレデンシャル）、Counterparty→Customer 逆同期。

joe commented

2026-09-27 13:26:35 +00:00

Author

Owner

追記: o2 を h1-c2 のスーパーセットへ（汎用伝票・弥生風フォーム・内税・事業所切替）

main に順次マージ・push 済み。全 6345 passed。

汎用伝票層（h1 DocumentModel を包含）

Document/DocumentItem＋DocType12種、h1 全項目（件名/案件/作業報告/明細のメーカー・型番・測定値・備考/content_hash/version/is_locked 等）
CRUD・プレビュー・PDF（12種・値引表示モード・内税・作業報告）・複写/変換・赤伝・ロック/解除
h1 の同期伝票を (tenant_id, uuid) で汎用層へ射影（冪等、delete=取消）

弥生風フォーム（全画面）

.doc-*（表題部/明細部/合計部/税計算）＋ o2.openRefModal ＋ o2.pageShortcuts（F2=新規/クリア, F8=参照, F12=登録）
見積/受注/請求/納品/発注/仕入請求/汎用伝票/得意先/仕入先/商品/勘定科目/倉庫/部門/PJ/銀行口座/経費/給与/在庫/棚卸/ロット/シリアル

h1 上位互換の残り

内税（include_tax）: 計算/プレビュー/フォーム/PDF（税率グループ round(incl*rate/(1+rate))）
値引表示モード: gross_only/net_amount/gross_with_note（PDF/画面）
商品の付帯項目: category/manufacturer/model_number/barcode/wholesale_price/supplier_id
参照先の追加: Project 顧客 / 経費の部門・取引先・PJ / 銀行口座の勘定科目

事業所（テナント）切替

GET /api/auth/tenants / POST /api/auth/switch-tenant、メニューバーの切替（PLATFORM_ADMIN は任意、一般は自事業所）

APIで全フィールド制御

更新を exclude_unset に統一（送信フィールドを設定・null で解除・省略は不変）。経費 PUT を新設、仕入先 counterparty_id を追加

docs

README 追補節、AGENTS に弥生風フォーム/汎用伝票/内税/表示モード/事業所切替/API制御の規約（bacd72b）

残（外部依存・任意）

電子証明書/PKCS#11・国税庁API（e-Tax）、Google実接続、伝票の不変版管理チェーン・分割請求、transfer_fee の会計分離。

## 追記: o2 を h1-c2 のスーパーセットへ（汎用伝票・弥生風フォーム・内税・事業所切替） main に順次マージ・push 済み。全 **6345 passed**。 ### 汎用伝票層（h1 DocumentModel を包含） - `Document`/`DocumentItem`＋`DocType`12種、h1 全項目（件名/案件/作業報告/明細のメーカー・型番・測定値・備考/`content_hash`/`version`/`is_locked` 等） - CRUD・プレビュー・PDF（12種・値引表示モード・内税・作業報告）・複写/変換・赤伝・ロック/解除 - h1 の同期伝票を `(tenant_id, uuid)` で汎用層へ射影（冪等、delete=取消） ### 弥生風フォーム（全画面） - `.doc-*`（表題部/明細部/合計部/税計算）＋ `o2.openRefModal` ＋ `o2.pageShortcuts`（F2=新規/クリア, F8=参照, F12=登録） - 見積/受注/請求/納品/発注/仕入請求/汎用伝票/得意先/仕入先/商品/勘定科目/倉庫/部門/PJ/銀行口座/経費/給与/在庫/棚卸/ロット/シリアル ### h1 上位互換の残り - **内税**（`include_tax`）: 計算/プレビュー/フォーム/PDF（税率グループ `round(incl*rate/(1+rate))`） - **値引表示モード**: `gross_only`/`net_amount`/`gross_with_note`（PDF/画面） - **商品の付帯項目**: category/manufacturer/model_number/barcode/wholesale_price/supplier_id - 参照先の追加: Project 顧客 / 経費の部門・取引先・PJ / 銀行口座の勘定科目 ### 事業所（テナント）切替 - `GET /api/auth/tenants` / `POST /api/auth/switch-tenant`、メニューバーの切替（PLATFORM_ADMIN は任意、一般は自事業所） ### APIで全フィールド制御 - 更新を `exclude_unset` に統一（送信フィールドを設定・`null` で解除・省略は不変）。経費 `PUT` を新設、仕入先 `counterparty_id` を追加 ### docs - README 追補節、AGENTS に弥生風フォーム/汎用伝票/内税/表示モード/事業所切替/API制御の規約（`bacd72b`） ### 残（外部依存・任意）電子証明書/PKCS#11・国税庁API（e-Tax）、Google実接続、伝票の不変版管理チェーン・分割請求、`transfer_fee` の会計分離。

Rows
Columns

Phase 0: 販売帳票PDF・値引・納品書連携・端数統一 #53

概要

対応内容

テスト結果

関連コミット

既知の設計課題（次フェーズ）

次のステップ

完了

次の対応

追記: 入金消込（Phase 0 完了）

追記: ドキュメント整備

追記: Phase 1d（帳票発行一元化・Google OAuth/Gmail）

1d-1 発行一元化

1d-2 Google/Gmail

注意

残（後続）

h1 ⇄ o2 実通信を確認（2026-09-21）

残（後続）

追記: Phase 1e（h1 データの射影・会計統合・監督）

残（後続）

追記: G3（Google）拡張と競合自動配信

残

追記: e-Tax（棚卸しと統合修正）

棚卸し（docs/superpowers/specs/2026-09-21-etax-status.md）

今回の統合修正（外部非依存）

残（別フェーズ）

追記: 既知の設計課題の修正と実データ取扱い

設計課題の修正

実データの取扱い

次

追記: 残課題の自律対応

1. Customer/Counterparty 二重管理（段階解消）

2. e-Tax 署名・証明書・スキーマ

残（外部依存）

追記: o2 を h1-c2 のスーパーセットへ（汎用伝票・弥生風フォーム・内税・事業所切替）

汎用伝票層（h1 DocumentModel を包含）

弥生風フォーム（全画面）

h1 上位互換の残り

事業所（テナント）切替

APIで全フィールド制御

docs

残（外部依存・任意）

棚卸し（`docs/superpowers/specs/2026-09-21-etax-status.md`）