どうか教えて下さい！
| > フロント機能 > ダウンロード販売機能 |
フロント機能
 |
| スレッド表示 | 新しいものから | 前のトピック | 次のトピック | 下へ |
| 投稿者 | スレッド |
|---|---|
| ECCUORE |
投稿日時: 2010/9/27 11:44
対応状況: −−−
|
長老   登録日: 2009/10/22 居住地: 東京 投稿: 248 |
Re: ダウンロード販売機能 引用：
恐らく現在、「ダウンロード商品と実商品は同時にカートに入れられない」という仕様にはなっていないと思います。 現在は、「カートに、ダウンロード商品を含む場合は、オンライン決済以外で購入できない」という仕様になっております。
|
| nanasess |
投稿日時: 2010/9/27 12:20
対応状況: −−−
|
神   登録日: 2006/9/9 居住地: 投稿: 2311 |
Re: ダウンロード販売機能 引用：
認識ミスでした. 申し訳ございません. 実際に, ダウンロード商品と実商品を同時購入しようとした場合, 配送の有無なども絡んでくるので, カートの時点で, 購入フローを明確に分けてしまった方が良いのではと思っています. |
| ECCUORE |
投稿日時: 2010/9/27 15:13
対応状況: −−−
|
長老 登録日: 2009/10/22 居住地: 東京 投稿: 248 |
Re: ダウンロード販売機能 vw_download_class を使用しないように修正しました。
また、いつもコミットミスを修正して頂いて申し訳ございません。
|
| seasoft |
投稿日時: 2010/9/27 15:57
対応状況: −−−
|
神  登録日: 2008/6/4 居住地: 投稿: 7367 |
Re: ダウンロード販売機能 ご対応ありがとうございました。インストールが通ることを確認しました。
まだダウンロード周りの実装を十分に把握できておらず、丸投げになりまして恐縮です。
|
| ECCUORE |
投稿日時: 2010/10/12 13:02
対応状況: −−−
|
長老 登録日: 2009/10/22 居住地: 東京 投稿: 248 |
Re: ダウンロード販売機能 チェンジセット[18851]で修正を行いました。
http://svn.ec-cube.net/open_trac/changeset/18851 ・大容量ファイル対策（tao_sさんご提案） 様々な環境で試験する必要がありそうな箇所の修正ですので、不具合が出るかもしれません。 ・Safari対応 Safariでダウンロードすると日本語ファイルが文字化けするという現象が報告されましたので対応しました。 ・その他 オンライン決済時のお届け先を非表示にしました。
|
| ECCUORE |
投稿日時: 2010/11/4 13:28
対応状況: −−−
|
長老 登録日: 2009/10/22 居住地: 東京 投稿: 248 |
Re: ダウンロード販売機能 チェンジセット18882（http://svn.ec-cube.net/open_trac/changeset/18882
にて、商品種別が追加されましたが、商品種別によってカートを分けるとなると、通常商品とダウンロード商品を同時購入したケースで決済画面系の挙動はどのようになるのでしょうか？ １：カートが別なので、決済も別に。（２度の決済を行う） ２：カートが別だが、決済は同じ。（１度の決済を行う） 恐らくは、「２」だと思いますので「２」と想定して、もう一つ質問があります。 ※当方で、カートを別ける明確な理由を理解していませんので、不躾な質問、提案になってる可能性がありますので、ご了承ください。 カートが別になるという事は、支払い方法選択画面では、２種類のカート（商品種別）の支払い方法の論理積を表示する事になります。 カートを分けたもう一つの理由が商品種別毎の配送方法や送料の違いだと思いますが、こちらは送料は配送方法毎の計算になって、配送方法は論理積になります。 カートを別けたケースと別けないケースの双方で、「商品種別による支払い方法の論理積」、「商品種別による配送方法の論理積」の処理は必ず必要になると思います。 その場合、商品種別毎にカートを分けるというよりも「商品種別に紐づく配送方法」毎にカートを別けるのが良いのかなと思いますが如何でしょうか？ もしくはカートを別けないで、カート内の商品情報に「商品種別」、「配送方法」、「送料」、「支払い方法」を持たせて方法系は、論理積を行い、送料は合算を行う。
|
| nanasess |
投稿日時: 2010/11/4 14:44
対応状況: −−−
|
神 登録日: 2006/9/9 居住地: 投稿: 2311 |
Re: ダウンロード販売機能 引用：
説明不足で申し訳ございません. 決済画面は 1 の挙動になります. 商品種別を設けた理由は, ダウンロード販売の他, 定期購入など, 通常商品とは違う決済フローが必要な場合に対応するためです. 配送方法については, 現在は支払方法に紐づいていますが, 商品種別に紐づくよう変更を考えています. 商品種別に配送を紐づけることにより, クール便など通常商品とは同梱の難しい配送方法にも, 容易に対応できます. 上記のような関連にすれば, ダウンロード販売のような, 配送が存在しないケースにも対応できます. また, 支払方法は商品規格を紐づけるように考えています. ダウンロード商品の場合は, オンライン決済のみに対応するといったことも可能な設計です. まだ, 決済フローの画面遷移を制御する部分など, 多くは未着手ですが, このように考えています. |
| ECCUORE |
投稿日時: 2010/11/4 15:32
対応状況: −−−
|
長老 登録日: 2009/10/22 居住地: 東京 投稿: 248 |
Re: ダウンロード販売機能 引用：
ご回答ありがとうございます。 では、下記商品が存在した場合のケースで再度質問させていただきます。 ＜商品A＞ 商品種別：通常商品 配送方法：クール便 支払方法：オンライン決済、代引き ＜商品B＞ 商品種別：定期購読商品 配送方法：通常宅配便 支払方法：オンライン継続決済 ＜商品C＞ 商品種別：ダウンロード販売 配送方法：（配送無し） 支払方法：オンライン決済 質問１： AとBとCを同時に購入する（1トランザクションというか、1度で）ことは可能でしょうか？ 例えば、通常商品が既にカートに入っていた場合、定期購読商品をカートに入れられるか。 質問２（質問１が可能だとすれば）： AとBを同時に買うケースで、オンライン決済でカード情報入力等を２回行わせるのか、１回で済むように想定されているのか。 １回で済むように想定しているのであれば、カートを分ける必要は無い気がします。 質問３（質問１が不可能だとすれば）：カートを分ける必要が無いような気がします．．． 現在の理解では、「商品種別と配送の紐づけ」と「商品規格と支払い方法の紐づけ」の必要性は強く感じますが、カートを分ける理由がまだわからないと言った所です。 よろしくお願いします。
|
| nanasess |
投稿日時: 2010/11/4 16:07
対応状況: −−−
|
神 登録日: 2006/9/9 居住地: 投稿: 2311 |
Re: ダウンロード販売機能 引用：
この場合, カート内容確認画面では, ABC それぞれ別々の表で表示されます. 引用：
カード情報入力は2回行なわなくてはなりません. 会員登録や, 決済会社のカード番号保存機能で, 入力回数を減らすことは可能です. 引用：
1. ユーザーが異なる商品種別を選択した場合に, 同時にカートに入れられず, 商品を選択し直さなければならないといったケースへの対応 2. モジュールにより, できるだけ自由に購入フローを構築できるように といった理由から, カートを分ける仕様としています. 特に, 2 については, 同一ロジック内で条件分岐させたり, エラーを表示させて同時購入を抑制したりという制御をモジュールで行うことは難しいですが, カートを分けて, カート以降の画面を独自に構築できれば, 決済モジュールなどでも比較的容易に追加できます. ユーザーには, できるだけエラーを出さず, 外部モジュールでの柔軟性を向上させるのが主たる理由です. |
| ECCUORE |
投稿日時: 2010/11/4 22:55
対応状況: −−−
|
長老 登録日: 2009/10/22 居住地: 東京 投稿: 248 |
Re: ダウンロード販売機能 引用：
私の理解不足で、上記で説明してくださった部分が理解できておりません。 理解できるまでお付き合いいただけると幸いです。（もしかしたら、私の想像や理解よりスマートなものになるのかもと考えてます） 以下は、私の理解不足な状態での意見ですので、ご了承頂きたいと思います。 引用：
カート内容確認画面で、商品種別毎の表で表示されるのは、購入者からしたら違和感がある気がしますが、どうでしょう？ 購入確認画面等でカートの中身が商品の種別毎に表示されるケースを見たことがありませんが、一般的なUIでしょうか？ 楽天などのモールで、店舗毎のカートというのは見たことありますが。 引用：
1については、前提条件として「異なる商品種別を選択した場合に, 同時にカートに入れられない」という仕様があるようですが 異なる商品種別を同時にカートに入れられないようにする理由が、あまり見えてきません。 カートのセッションやテーブルに商品種別フィールドを追加するだけではダメでしょうか？ 仮にカートを分けたとしても、一緒だとしても、商品種別、配送方法が決済モジュールに及ぼす影響は余り無い気がしますが、いかがでしょうか？ 「お届け先指定画面」や「支払方法選択画面」で、カート内の商品種別、商品規格、配送方法を判別して、「１決済」で行う方が購入者にとってはメリットがある気がします。 ＜カートを分けないケース購入時の流れ＞ 「お届け先指定画面」 ↓ （カート内の商品→商品規格→支払方法を論理積で表示） ↓ 「支払方法選択画面」 ↓ （カート内の商品→商品種別→送料を計算して表示） ↓ 「ご入力内容のご確認画面」 ＜カートを分けるケース購入時の流れ＞ 「お届け先指定画面」 ↓ （カート内の商品→商品規格→支払方法を論理積で表示） ↓ 「支払方法選択画面」 ↓ （カート内の商品→商品種別毎に表を表示） （送料も商品種別毎に計算して表示） ↓ 「ご入力内容のご確認画面」 カートを分けてしまうと、決済までの流れを複雑にしてしまうのではないかと考えてます。 既に、決済を2回行う場合の手数料の問題などが考えられます。 今回の仕様変更は購入者にとっては、あまりメリットは無い気がします。 むしろ決済情報を2度入力する必要があるかもしれないことや、商品種別毎の確認ページなどの複雑になるUI、手数料問題などを考えるとデメリットに感じます。
|
| « 1 2 3 (4) 5 » | |
| スレッド表示 | 新しいものから | 前のトピック | 次のトピック | トップ |
