# コード照合：店販・配送・返金・利益

確認版：`source-index.md` の F・B（2026-09-20）。原本p.63〜71と併用する。コード断片は T1〜T5。

## 発送ボタンと状態

入口：「売上向上 → 店販提案 → 注文履歴」。注文番号・顧客・商品・数量・決済状態・受取方法を照合する。

| 現在の状態 | 管理画面の操作と結果 |
| --- | --- |
| 配送・決済済み／発送準備中 | 操作権限がある場合「発送手続きをする」を表示。「ヤマト公式で発送コードを作る」へ進み、実際に荷物を預けた後に「発送完了にしてLINEを送る」→「発送完了にする」。 |
| 発送済み | 発送LINE再送と「手動で配達完了」の操作を表示。荷物の再発送を意味しない。配達完了は実際の配達結果を確認して記録する。 |
| 店頭受取・決済済み | 「受取準備完了」を表示。 |
| 店頭受取・受取準備完了 | 実際に商品を渡してから「受取完了」。 |
| 未決済／全額返金済み | サーバーは発送・状態変更を拒否する。ボタンがない原因を権限だけと断定しない。 |

画面の状態とサーバーの決済状態は別の検証。表示された操作だけで決済済みと決めつけず、対象注文の決済結果を照合する。

## 追跡番号の入力欄がない

この固定版の発送フォームにあるのは「発送メモ（任意）」。送信される内容も配送会社と発送メモで、追跡番号を入力させる処理ではない。過去に登録された番号を「過去の追跡番号」として表示する箇所はある。

説明文の一部に「発送後に追跡番号を登録します」と残っているが、実際の入力フォームと処理は一致していない。存在しない入力欄や「追跡番号CSVの取込」ボタンを創作しない。サーバーに過去の取込処理があることを、現在の管理画面から使える根拠にしない。

## 一括処理とLINE

- 「一括で発送準備」は選択した配送注文のうち決済済みを対象に、発送準備中へ変更する。発送済みや配達完了にはしない。
- 発送登録の保存とLINE送信は別。画面には「発送情報は保存しましたが、LINE送信に失敗しました」と表示する分岐がある。
- この場合は発送済みの状態を確認し、「発送LINEを再送」を案内する。注文を新規作成し直させたり発送準備へ戻させたりしない。
- 再送時も送信済みなら重複防止の結果が返る場合がある。ボタンを押しただけで必ず再送されたとは言わず、結果表示を確認する。

## 返金と履歴削除

- 管理画面の「返金」は残りの返金対象額の全額。入力した任意額を返金する画面ではない。
- B `RetailRefundService.create_refund` に金額指定の引数があっても、F `RetailProposalPanel.refundOrder` は `refundable_amount` を送る。この違いから「店舗画面で部分返金できる」と案内しない。
- 返金可能な決済状態と残額を確認し、確認画面で注文番号・商品・金額を照合して「返金する」。受付表示だけで銀行への着金まで完了したとは言わない。
- 管理画面からは発送前・未受取なら在庫を戻す指定を送り、発送済み・配達完了・受取完了なら戻す指定をしない。実際の在庫加算にも全額返金成功・在庫追跡などの条件がある。返品後は実物と在庫を確認する。
- 削除ボタンは受取完了・配達完了・取消・返金済みの注文に表示される。履歴整理であり返金ではない。削除しても決済・売上の取消にはならない。

## 利益が未算出・入金日が不明

「送料・利益・入金」で確認する。利益は「手数料・返金控除後の受取額 − 商品原価 − 実送料」。送料としてお客様から受け取る金額と、店舗が負担した実送料は別。

1. 「原価・実送料を登録」で商品原価は注文全体、実送料は店舗負担額を入力して「保存する」。0円なら0、不明なら空欄。
2. 「入金情報を更新」で受取額・利益・入金の表示を確認する。

原価や実送料が未登録なら利益は未算出。Stripe側の受取額取得中、返金後の未確定、更新エラーでも計算値を確定表示しない分岐がある。未算出を0円と解釈しない。「目安」「Stripe予定」「Stripe入金済み」を区別し、実データにアクセスできないプラグインが金額や入金日を補完しない。