返金ページ上で 商品に「割引」を直接適用できるようになった

図解 ： 返金ページ上で商品に割引を適用できるようになった Admin / 機能改善 返金ページ上で 商品に「割引」を直接適用できるようになった 返金を発行する画面のまま、対象商品に割引を 追加・更新・削除 できる。残高はその場で再計算され、割引後の金額で返金できる。注文編集ページへ行き来する手間が消える。 このページの構成 そもそも何が変わるのか（30秒で理解） 操作の流れ（4ステップ図解） 従来 vs 今回 の比較 なぜ重要か ： 売上・税レポートの正確性 記事に「書いてあること／記載なし」の整理 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか 返金を発行する 返金ページ（refund page） 上で、対象商品（eligible items）に 割引を追加・更新・削除 できるようになった。 これまで「返金前に値引きする」には、いったん 注文編集ページ に移動する必要があった。その往復が不要になる。 従来 ： 画面を行き来 返金前に割引したい → 注文編集ページへ移動して割引を適用 → 返金ページに戻って返金。余計なステップが挟まる。 今回 ： 返金ページ内で完結 返金ページを離れずに対象商品の割引を追加・更新・削除。残高が即再計算され、割引後の金額でそのまま返金できる。 2 操作の流れ（4ステップ図解） 4 ステップとも 返金ページを離れずに 完結する。割引を触ると残高（outstanding balance）が即座に再計算され、その割引後の金額に対して返金を発行する。 3 従来 vs 今回 の比較 項目 従来 今回（返金ページで割引適用） 割引を適用する場所 注文編集ページ へ移動して適用 返金ページ内 で直接適用 画面遷移 往復あり 編集ページ ↔ 返金ページ 往復なし 1 画面で完結 割引の操作 編集ページ側で実施 追加・更新・削除 が返金ページで可能 残高（未払い額）の反映 画面を戻ってから確認 即時 ページがその場で更新 売上・税レポート 値引きを反映し忘れると不正確になりうる 正確 割引を反映して返金できる 対象 — eligible items（対象商品）。条件の定義は 記載なし 4 なぜ重要か ： 売上・税レポートの正確性 手間が減る（運用面） 記事の「Why it matters」より ： 従来は返金前の割引に注文編集ページへの移動が必要で、不要なステップが増えていた。今は返金ページから直接適用できる。 数字が正しくなる（会計面） 記事の明記事項 ： 割引を適用しておくことで、返金発行時の 売上・税レポートが正確 になる。 ポイントは「返金額をいくらにするか」だけでなく、 割引を正しく反映した状態で返金を計上できる こと。これにより売上・税の集計が実態と合う。具体的な税計算ロジックや対象税種別は記事に 記載なし 。 5 記事に「書いてあること／記載なし」の整理 推測を避けるため、元記事に明記されている事実と、触れられていない点を分けて整理する。 記載あり 返金ページから割引の 追加・更新・削除 ができる 対象は eligible items（対象商品） 操作するとページが 更新され残高が再計算 される 割引後の金額に対して 返金を発行 できる 従来は 注文編集ページ への移動が必要だった 割引適用で 売上・税レポートが正確 になる 分類は Feature / Admin 記載なし 「eligible items（対象商品）」の 具体的な判定条件 対応 プラン・国／地域 権限・スタッフ権限 に関する要件 Admin API / GraphQL / Webhook での扱い 適用できる 割引の種類・上限 （％/定額など） 既存の返金・割引 自動化への影響 提供開始日・ロールアウト範囲 の詳細 「記載なし」の項目は導入前に管理画面・公式ヘルプで実機確認すること。特に「どの商品が対象になるか」は運用手順に直結する。 6 技術者が押さえるべき5つのポイント 1. 本質は Admin UI の操作改善 新しい機能というより「返金ページに割引操作を持ち込んだ」UI 改善。バックエンドの新 API についての記載はない。 2. 残高は「適用→即再計算」 割引の追加・更新・削除に応じて outstanding balance がページ内で再計算され、その金額に対して返金を発行する流れ。 3. 狙いは会計データの整合 割引を反映した状態で返金を計上 → 売上・税レポートが正確に。記事が明記する効果はここ。 4. 「対象商品」の条件は要確認 eligible items とだけ表現され、判定条件は未記載。対象外の商品が存在しうる前提で運用設計する。 5. API / Webhook / 自動化への影響は記載なし Admin GraphQL の refund / discount まわりでこの操作がどう表現されるか、既存の返金自動化やレポート連携にどう響くかは触れられていない。 自動化フローを持つストアはサンドボックスで挙動を検証 してから本番に展開すること。 7 業務に活かせる3つのユースケース USE CASE 1 CS 窓口の「一部返金＋値引き対応」を1画面で完結 課題 「届いた商品に軽微な傷 → 一部返金しつつ値引き対応」のようなケースで、注文編集ページに移動して割引 → 返金ページに戻る、と画面を行き来していた。 打ち手 返金ページ上で対象商品に割引を直接適用し、再計算された残高に対してそのまま返金を発行する運用に切り替える。 効果 1 件あたりの操作ステップ削減・処理時間短縮、画面往復による戻し忘れ／適用漏れの減少。 技術メモ 「対象商品（eligible items）」の判定条件は記載なし。運用前に対象になる／ならない商品を管理画面で確認しておく。 USE CASE 2 返金時の「売上・税レポートずれ」を構造的に防ぐ 課題 値引きを反映せずに返金すると、売上・税の計上額が実態とずれ、月次締めや税務データの整合が崩れる。 打ち手 「返金前に返金ページで割引を適用 → 割引後の金額で返金」を標準手順として固定し、計上を実態に合わせる。 効果 売上・税レポートの精度向上、経理・会計連携の手戻り削減（記事が明記する効果に直結）。 技術メモ 具体的な税計算ロジック・対象税種別は記載なし。会計ツール／外部連携への反映タイミングは別途検証。 USE CASE 3 返品繁忙期に向けた返金オペレーションの標準化 課題 セール後・年末など返品が集中する時期に、画面遷移の多い手順がスループットのボトルネックになり、対応品質もばらつく。 打ち手 「返金ページで割引適用 → 残高確認 → 返金発行」の単一フローを手順書化し、CS／オペレーターに展開・教育する。 効果 処理スループット向上、新人教育コスト削減、オペレーター間の対応品質の均一化。 技術メモ API / Webhook によるバルク自動化の可否は記載なし。大量処理が必要なら Admin API 側の対応可否を先に検証する。 8 提案で使える1行サマリ 「返金時の『先に値引き』を、 注文編集ページに戻らず返金ページ内で完結 。 残高はその場で再計算され、 割引後の金額で返金 。画面の往復を無くしつつ 売上・税レポートも正確に保てる 、小粒だが現場で効く Admin の運用改善。」 source ： changelog.shopify.com / apply-discounts-to-items-on-the-refund-page published 2026-05-04 ／ 分類 ： Feature・Admin