この記事でわかること
EC-CUBEで領収書の発行依頼に個別対応している場合、マイページから購入者自身がPDFを取得できる仕組みが選択肢になります。この記事では、プラグインと個別開発の選び方、決済別の発行条件、宛名変更・再発行・返金時の扱いを整理します。
最初に確認したいのは、減らしたい作業です。毎回のPDF送付が負担なのか、宛名の訂正が多いのか、発行できる注文の確認に時間がかかるのかによって、必要な機能が変わります。
EC-CUBEに領収書ダウンロードを追加する方法
まず、利用中のEC-CUBEのバージョンと、導入済みの帳票・決済プラグインを確認します。すでに管理画面で領収書を出力できても、購入者がマイページから取得する機能まで備わっているとは限りません。
| 方法 | 検討する場面 | 確認すること |
|---|---|---|
| 現在の機能・設定を使う | 導入済みの帳票機能に、購入者向けの出力機能がある | 対象の決済、表示条件、宛名や帳票項目が運用に合うか |
| プラグインを導入する | 既製品の機能で発行ルールを満たせる | 対応バージョン、マイページへの対応、既存改修との併用 |
| 個別カスタマイズする | 独自の発行条件、宛名訂正、法人会員の権限などが必要 | 決済情報・発行履歴・権限判定を含む改修範囲 |
製品の例として、オーナーズストアにはマイページ帳票PDF出力プラグイン［EC-CUBE4.2/4.3］が掲載されています。注文履歴から納品書・領収書のPDFを取得する機能が案内されていますが、本記事で挙げる発行条件や再発行管理をすべて満たすという意味ではありません。採用時は、対応する細かなバージョンと必要な機能を確認し、自社環境で検証します。
構築や既存サイトの改修を含む対応範囲は、EC-CUBE構築・カスタマイズサービスをご覧ください。
発行条件は、決済方法と入金確認を組み合わせる
「発送済みになったら表示する」といった注文ステータスだけで判断すると、実際の支払状況とずれる場合があります。どの情報を入金・決済確認の根拠にするかを、決済方法ごとに決めます。
| 決済・取引の例 | 実装前に確認する点 |
|---|---|
| クレジットカード | 与信と売上確定を区別し、どの決済状態を参照するか。取消・返金の通知を反映できるか |
| 銀行振込 | 入金の確認・消込を誰が行い、EC-CUBEへどう反映するか |
| 代引き・外部の後払い | 決済事業者などの書類発行との役割分担と、自社での発行対象をどう定めるか |
| 法人の掛け払い・月締め | 複数注文への一括入金や一部入金を、注文単位の出力とどう対応させるか |
これは機能設計の確認表であり、決済方法ごとの一律の発行可否を示すものではありません。発行主体・記載内容・発行日は、経理担当者と決済事業者の運用を確認して決めます。
発行条件を満たさないときは、ボタンを隠すだけでなく「入金確認後に取得できます」など、実際の状態に合った案内を用意します。条件が成立してから表示されるまでに時間差がある場合も、案内に含めます。
宛名変更は、初回発行前と発行後を分ける
個人名で注文し、会社名での領収書を希望するなど、購入者が宛名を入力したい場面があります。初回発行前の入力と、発行した後の訂正を同じ処理にしないことがポイントです。
- 初期表示する宛名を、注文者名・会社名のどちらにするか
- 空欄、長すぎる文字、帳票に表示できない文字をどう扱うか
- 発行前に宛名と金額を確認できる画面を設けるか
- 発行後の訂正を購入者に許可するか、運営側で受け付けるか
- 訂正前後の情報を、管理画面から確認する必要があるか
入力した宛名で発行した後、次回のダウンロードで注文者名に戻ってしまわないよう、どの値を保存して再利用するかも決めます。変更回数を制限する場合は、入力ミスへの問い合わせ窓口も用意します。
再ダウンロードと、内容を変える再発行を区別する
同じPDFをもう一度取得することと、宛名や金額を変えて発行し直すことは別の操作です。「2回目だからすべて同じ再発行処理」と決める前に、次の違いを整理します。
- 同一内容の再取得：保存済みPDFを渡すか、保存した発行データから生成するか
- 内容を訂正した発行：変更理由や変更前後の情報をどう残すか
- 管理画面での発行：購入者側の発行履歴と共通で管理するか
現在の受注データを読み直してPDFを作る方式では、注文内容の変更により前回と異なる内容になる場合があります。発行時の内容を再現したいなら、PDFまたは発行データを保存する設計が必要です。再発行の表示や発行番号の扱いも、運用ルールに合わせて決めます。
キャンセル・返金後の扱いも決めておく
発行前の注文取消、発行後の全額返金、一部商品の返品では、必要な対応が異なります。注文と決済の状態が変わったときに、発行可能な状態を見直せるようにします。
たとえば、一部返金後に現在の注文金額をそのまま表示すると、当初発行した内容との関係が分かりにくくなります。訂正や返金に関する書類をどう扱うか、誰が内容を確認し、購入者へ何を案内するかを整理します。
すでに購入者が保存したPDFは、サイト側で回収・書き換えできません。発行済みの記録を残し、必要な訂正や案内を行える運用を用意します。ダウンロードボタンを消すだけで、過去に発行した内容の処理が完了するわけではありません。
本人の注文だけ取得できる仕組みを確認する
マイページに表示するボタンだけでなく、PDFを取得する処理でも、ログイン中の会員がその注文を取得できるかを確認します。注文番号やURLを変えて他の会員の帳票を取得できないこと、ログアウト後に取得できないことを検証します。
法人アカウントを複数の担当者で使うサイトでは、自分の注文だけか、同じ会社の注文も取得できるかを決めます。PDFの保存先にも同じ考え方を適用し、ログイン確認を通らず直接ファイルを取得できる状態にしない設計が必要です。
ゲスト購入はマイページの運用と分けて扱います。個別対応を残すか、本人確認を伴う別の取得方法を用意するかを決め、注文番号だけで取得できる仕組みにしないようにします。
見積もり前に用意する情報と、公開前の確認
現在の領収書見本と発行の手順が分かると、開発範囲を整理しやすくなります。実在する顧客情報は、サンプルの氏名・住所などに置き換えてください。
- EC-CUBEのバージョン、帳票・決済プラグイン、マイページの改修内容
- 対象の決済方法と、入金・売上確定を確認する方法
- 宛名・但し書き・金額など、必要な出力項目とその保存場所
- 初回発行、再取得、訂正、キャンセル・返金の運用ルール
- 会員・法人担当者・ゲストそれぞれの取得範囲
- 現在の発行依頼件数、対応時間、希望する公開時期
公開前には、発行対象と対象外の決済、未入金、キャンセル、全額・一部返金、宛名訂正、同時操作による重複処理を確認します。加えて、別会員からのアクセス、複数ページの帳票、スマートフォンでの保存も試します。
費用はPDFの見た目だけでなく、決済情報の連携、履歴の保存、権限管理、既存改修との調整範囲によって変わります。調査・実装・テスト・本番反映・更新時の確認が見積もりに含まれるかを確認しましょう。
導入後は、定型の発行依頼と例外対応を分けて件数や対応時間を見ます。問い合わせが多い理由が「ボタンが見つからない」「発行できない理由が分からない」であれば、案内文や表示位置の改善も必要です。
関連する帳票カスタマイズ
よくある質問
EC-CUBEでマイページから領収書をダウンロードできますか？
プラグインや個別カスタマイズで対応を検討できます。利用中のEC-CUBEのバージョン、決済プラグイン、マイページの改修状況を確認し、必要な発行条件や帳票形式を満たせる方法を選びます。
領収書の宛名を購入者が変更できるようにできますか？
機能として検討できます。初回発行前に入力できる範囲と、発行後の訂正手続きを分けて決めます。発行後も変更できる場合は、変更前後の宛名や発行履歴を確認できるようにするか、運営側で訂正を受け付けるかを整理します。
同じ領収書を再ダウンロードすることと、再発行は同じですか？
同じ内容の保存済みPDFを再取得することと、宛名・金額などを変更して発行し直すことは分けて設計します。再取得時に毎回現在の注文データから生成すると内容が変わる場合があるため、保存する内容と再出力方法を決めます。
キャンセルや返金後は、領収書をどう扱いますか？
発行前か発行後か、全額返金か一部返金かによって処理を分けます。未発行分の発行を止める条件、発行済み分の訂正や案内、返金内容の記録を整理します。すでに購入者が保存したPDFを、サイト側で回収・書き換えすることはできません。
プラグインだけで対応できますか？
必要な決済条件・宛名入力・再発行・帳票形式を満たし、既存環境と併用できる場合は候補になります。管理画面からの出力と購入者向けのダウンロードは別の機能なので、マイページへの対応を確認してください。
領収書ダウンロードを導入すれば、問い合わせはなくなりますか？
定型の発行依頼を減らすことを目指せますが、宛名訂正、返金後の対応、ゲスト購入などの例外は残る場合があります。発行できない理由と問い合わせ先を案内し、導入前後の依頼件数や対応時間で効果を確認します。
EC-CUBEの領収書発行・ダウンロード機能をご相談ください
マイページでの発行、宛名変更、再発行など、現在の個別対応から必要な機能を整理します。お使いの決済方法と領収書の見本、担当者が手作業で確認している内容をお知らせください。
投稿者プロフィール
- サンクユーのEC-CUBE担当。15年以上にわたりEC-CUBE開発に従事し、2系・3系・4系すべてに精通。難易度の高いカスタマイズや、他社構築サイトの改修・再設計も多数対応しています。
Javaでの業務システム開発を起点に、PHP・Perl・フロントエンド・CMSまで横断的に対応。基幹システム連携や業務フローを踏まえた設計を得意とし、複雑な要件にも柔軟に対応可能です。
ChatGPT CODEXを活用し、開発スピードと品質の両立を実現しています。
