返金を発行する画面のまま、対象商品に割引を 追加・更新・削除 できる。残高はその場で再計算され、割引後の金額で返金できる。注文編集ページへ行き来する手間が消える。
返金前に割引したい → 注文編集ページへ移動して割引を適用 → 返金ページに戻って返金。余計なステップが挟まる。
返金ページを離れずに対象商品の割引を追加・更新・削除。残高が即再計算され、割引後の金額でそのまま返金できる。
| 項目 | 従来 | 今回（返金ページで割引適用） |
|---|---|---|
| 割引を適用する場所 | 注文編集ページ へ移動して適用 | 返金ページ内 で直接適用 |
| 画面遷移 | 往復あり 編集ページ ↔ 返金ページ | 往復なし 1 画面で完結 |
| 割引の操作 | 編集ページ側で実施 | 追加・更新・削除 が返金ページで可能 |
| 残高（未払い額）の反映 | 画面を戻ってから確認 | 即時 ページがその場で更新 |
| 売上・税レポート | 値引きを反映し忘れると不正確になりうる | 正確 割引を反映して返金できる |
| 対象 | — | eligible items（対象商品）。条件の定義は記載なし |
記事の「Why it matters」より ： 従来は返金前の割引に注文編集ページへの移動が必要で、不要なステップが増えていた。今は返金ページから直接適用できる。
記事の明記事項 ： 割引を適用しておくことで、返金発行時の 売上・税レポートが正確 になる。
推測を避けるため、元記事に明記されている事実と、触れられていない点を分けて整理する。
新しい機能というより「返金ページに割引操作を持ち込んだ」UI 改善。バックエンドの新 API についての記載はない。
割引の追加・更新・削除に応じて outstanding balance がページ内で再計算され、その金額に対して返金を発行する流れ。
割引を反映した状態で返金を計上 → 売上・税レポートが正確に。記事が明記する効果はここ。
eligible items とだけ表現され、判定条件は未記載。対象外の商品が存在しうる前提で運用設計する。
Admin GraphQL の refund / discount まわりでこの操作がどう表現されるか、既存の返金自動化やレポート連携にどう響くかは触れられていない。自動化フローを持つストアはサンドボックスで挙動を検証してから本番に展開すること。