EC-CUBE 開発コミュニティ

> フロント機能 > ダウンロード販売機能

フロント機能

投稿者	スレッド
nanasess	投稿日時: 2010/11/5 12:43 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2313	Re: ダウンロード販売機能引用： ECCUOREさんは書きました：「お届け先指定画面」や「支払方法選択画面」で、カート内の商品種別、商品規格、配送方法を判別して、「１決済」で行う方が購入者にとってはメリットがある気がします。 ... snip カートを分けてしまうと、決済までの流れを複雑にしてしまうのではないかと考えてます。既に、決済を2回行う場合の手数料の問題などが考えられます。今回の仕様変更は購入者にとっては、あまりメリットは無い気がします。むしろ決済情報を2度入力する必要があるかもしれないことや、商品種別毎の確認ページなどの複雑になるUI、手数料問題などを考えるとデメリットに感じます。確かにおっしゃる通りなのですが, * 定期購入等の機能を後からモジュールとして追加したい * モジュールによるソースの上書きは(extends も含め)極力避けたいということを考えた場合はいかがでしょうか. 引用：＜商品A＞商品種別：通常商品配送方法：クール便支払方法：オンライン決済、代引き＜商品B＞商品種別：定期購読商品配送方法：通常宅配便支払方法：オンライン継続決済＜商品C＞商品種別：ダウンロード販売配送方法：（配送無し）支払方法：オンライン決済作り込みさえすれば, 上記の内容を1度の決済で行い, A と B に関しては個別に配送することも可能です. クール便と通常配送を別便にする場合は, 二重に送料がかかると思いますが, 作り込みで対応可能と思われます. しかし, プラグインや決済モジュールとして, 外部配送連携や, 定期購入を対応しようとした場合, 既存のソースコードを上書きしなければならず, 汎用性が損なわれてしまいます. 商品種別ごとにカートを分けてしまえば, カートの次ページの遷移先を変更するのみで, 既存のソースコードと干渉することなく, モジュール側で自由に購入フローを構築することができます. カートを分ける仕様は, フレームワークとしてのできるだけの柔軟性を考えた結果ですので, あまり一般的ではないかもしれません. プラグインや決済モジュールで, 極力既存のロジックを上書きせず, できるだけ自由に購入フローを構築できるようにと考えると, カートの中身を分けてしまい, カート以降の遷移先を決済モジュールやプラグインに移譲するのが良いと思っています.

ECCUORE	投稿日時: 2010/11/5 13:24 対応状況: −−−
長老登録日: 2009/10/22 居住地: 東京投稿: 248	Re: ダウンロード販売機能何度もお手数をおかけして申し訳ございません。引用：カートを分ける仕様は, フレームワークとしてのできるだけの柔軟性を考えた結果ですので, あまり一般的ではないかもしれません. プラグインや決済モジュールで, 極力既存のロジックを上書きせず, できるだけ自由に購入フローを構築できるようにと考えると, カートの中身を分けてしまい, カート以降の遷移先を決済モジュールやプラグインに移譲するのが良いと思っています. 今回の仕様変更に対する思想としては、UIよりも、フレームワークとしての柔軟性を重視すると言った所でしょうか。思想としては理解いたしましたが、最終的なイメージが掴めていないのが本音です。引用：しかし, プラグインや決済モジュールとして, 外部配送連携や, 定期購入を対応しようとした場合, 既存のソースコードを上書きしなければならず, 汎用性が損なわれてしまいます. 商品種別ごとにカートを分けてしまえば, カートの次ページの遷移先を変更するのみで, 既存のソースコードと干渉することなく, モジュール側で自由に購入フローを構築することができます. 上記の「モジュール側で自由に購入フローを構築する」にあるモジュールとは何を指すのかがわかりませんでした。「決済モジュール」なのか、「プラグイン的なモジュール」なのか。フローのイメージは、こんな感じでしょうか？＜カートの中に、商品種別が異なるものが含まれているケース＞「お届け先指定画面」　↓ 　（カート内の商品→商品規格→支払方法を商品種別毎に表示）　↓ 「支払方法選択画面」（商品種別が別なので、支払い方法を複数選ぶ　※Q:1）　↓ 　（カート内の商品→商品種別毎に表を表示）　（送料も商品種別毎に計算して表示）　↓ 「ご入力内容のご確認画面」　↓ 　（支払い方法の数だけ支払いを行う　※Q:2）　↓ 「例）クレジット決済画面」　↓ 「例）ペイジー決済画面」　↓ 「購入完了画面」＜＜上記イメージでの質問＞＞ Q:1　支払い方法は「支払方法選択画面」で複数選ぶように変更するのでしょうか？ Q:2　「ご入力内容のご確認画面」以降を、「モジュール側で自由に購入フローを構築する」と仰ってると思いますが　　実際には、どのようなフローになるのでしょうか？　　上記イメージですと、クレジット決済をした後に、ペイジー決済になりますがトランザクション的にどのような処理になるのでしょうか？ ---------------- EC CUORE 株式会社クオーレカスタマイズ御相談下さい。

nanasess	投稿日時: 2010/11/5 14:28 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2313	Re: ダウンロード販売機能引用： ECCUOREさんは書きました：上記の「モジュール側で自由に購入フローを構築する」にあるモジュールとは何を指すのかがわかりませんでした。「決済モジュール」なのか、「プラグイン的なモジュール」なのか。決済モジュールとプラグイン両方です. 決済モジュールは, オーナーズストアからダウンロード可能なもの. プラグインは, 2.5 から新たに追加される機能です. 参考 http://svn.ec-cube.net/open_trac/ticket/494 引用：＜カートの中に、商品種別が異なるものが含まれているケース＞この場合は, 「カート内容確認画面(cart/index.php)」の時点で, 商品種別ごとにカート内の表が表示され, 「次へ」のボタンも商品種別ごとに表示されます. 引用： Q:1　支払い方法は「支払方法選択画面」で複数選ぶように変更するのでしょうか？ Q:2　「ご入力内容のご確認画面」以降を、「モジュール側で自由に購入フローを構築する」と仰ってると思いますが　　実際には、どのようなフローになるのでしょうか？　　上記イメージですと、クレジット決済をした後に、ペイジー決済になりますがトランザクション的にどのような処理になるのでしょうか？「ご入力内容のご確認画面」ではなく,「カート内容確認画面」以降の購入フローを個別に構築することになります. 従って, 「支払方法選択画面」の時点では, 商品種別に応じてフローを分岐した後になるので, 支払方法を複数選択することはありません. 複数の商品種別の商品を購入したい場合は, 一旦決済完了した後, 再度カートに戻って購入します. 毎回説明不足で申し訳ございませんが, よろしくお願い致します.

ECCUORE	投稿日時: 2010/11/5 14:52 対応状況: −−−
長老登録日: 2009/10/22 居住地: 東京投稿: 248	Re: ダウンロード販売機能引用：複数の商品種別の商品を購入したい場合は, 一旦決済完了した後, 再度カートに戻って購入します. なるほど、カート毎の決済なのですね。モヤモヤが晴れてきました。引用：この場合は, 「カート内容確認画面(cart/index.php)」の時点で, 商品種別ごとにカート内の表が表示され, 「次へ」のボタンも商品種別ごとに表示されます. ただ、その場合カートが[商品種別毎]ではなくて、[支払い種別毎]になるのでは無いでしょうか？下記のようなケースです。＜カート内に、商品AとBが存在するケース＞商品A 　商品種別：通常商品　商品規格：郵送商品　支払方法選択（郵送商品に紐づく支払い方法）：クレジットのみ商品B 　商品種別：ダウンロード商品　商品規格：ダウンロード商品　支払方法（ダウンロード商品に紐づく支払い方法）：クレジットのみ商品種別毎の決済になるのであればこのようなケースでも、クレジット決済を2回行わせるという事でよろしいでしょうか？ ---------------- EC CUORE 株式会社クオーレカスタマイズ御相談下さい。

nanasess	投稿日時: 2010/11/5 17:04 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2313	Re: ダウンロード販売機能引用： ECCUOREさんは書きました：商品種別毎の決済になるのであればこのようなケースでも、クレジット決済を2回行わせるという事でよろしいでしょうか？はい, クレジット決済を2回行います.

ECCUORE	投稿日時: 2010/11/5 17:35 対応状況: −−−
長老登録日: 2009/10/22 居住地: 東京投稿: 248	Re: ダウンロード販売機能引用：はい, クレジット決済を2回行います. やっと、仕様を完全に理解しました。仕様は理解したのですが、まだ「仕様変更をする必要性」と「購入者のユーザビリティ」を天秤にかけて考える必要があるのでは無いかとも思ってます。オーダーテーブル（受注）もカート単位で発行されるとすると、「管理者のユーザビリティ」も低下する気がしますし。個人的には、ECサイトでは「ユーザビリティ」が重要だと思いますので、今回の仕様（商品種別毎にカートを分け、決済も分かれる）は、少し残念です。 nanasess さん　ようやく仕様を理解できましたので、スッキリしました。長い間、私の拙い理解力、読解力にお付き合い頂いて、ありがとうございます。 ---------------- EC CUORE 株式会社クオーレカスタマイズ御相談下さい。

nanasess	投稿日時: 2010/11/5 17:50 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2313	Re: ダウンロード販売機能引用： ECCUOREさんは書きました：やっと、仕様を完全に理解しました。良かったです! 引用：仕様は理解したのですが、まだ「仕様変更をする必要性」と「購入者のユーザビリティ」を天秤にかけて考える必要があるのでは無いかとも思ってます。オーダーテーブル（受注）もカート単位で発行されるとすると、「管理者のユーザビリティ」も低下する気がしますし。個人的には、ECサイトでは「ユーザビリティ」が重要だと思いますので、今回の仕様（商品種別毎にカートを分け、決済も分かれる）は、少し残念です。あくまでも, 決済モジュールやプラグインで購入フローを変更したり, 通常便とクール便での発送など, 配送が別になり送料が2重でかかるパターンに対して, 極力ソースコードを変更することなく, 設定のみで対応しやすくする変更です. ユーザービリティを考慮し, 1決済で済ませたい場合, 作り込みでは融通が利きませんが, この設計であればプラグインなどでの対応も可能だと思われます.

seasoft	投稿日時: 2010/11/7 14:22 対応状況: −−−
神登録日: 2008/6/4 居住地: 投稿: 7367	Re: ダウンロード販売機能注文履歴詳細にて下記エラーが発生するようです。 FATAL Error(256) /home/eccube/ec25d/data/class/SC_Query.php:762 https://**/ec25d/mypage/history.php?order_id=1 SERVER_ADDR: * REMOTE_ADDR: ** USER_AGENT: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.7 (KHTML, like Gecko) Chrome/7.0.517.44 Safari/534.7 SQL: SELECT od.product_id AS product_id, od.product_code AS product_code, od.product_name AS product_name, od.classcategory_name1 AS classcategory_name1,od.classcategory_name2 AS classcategory_name2, od.price AS price, od.quantity AS quantity, od.point_rate AS point_rate,CASE WHEN EXISTS(SELECT * FROM dtb_products WHERE product_id = od.product_id AND del_flg = 0 AND status = 1) THEN '1' ELSE '0' END AS enable,o.status AS status, pc.down AS down, o.payment_date AS payment_date, od.product_class_id as product_class_id, (SELECT CASE WHEN (SELECT d1.downloadable_days_unlimited FROM dtb_baseinfo d1) = 1 AND o.payment_date IS NOT NULL THEN 1 WHEN DATE(NOW()) <= DATE(o.payment_date + '30 days') THEN 1 ELSE 0 END) AS effective FROM dtb_products p, dtb_products_class pc, dtb_order_detail od, dtb_order o WHERE p.product_id = od.product_id AND pc.product_id = od.product_id AND pc.product_class_id = od.product_class_id AND od.order_id = o.order_id AND od.order_id = ? MDB2 Error: no such field prepare: [Error message: Unable to create prepared statement handle] [Last executed query: EXECUTE mdb2_statement_pgsql_130748140673193995de03b388953b42f9771eb858 ('1')] [Native message: ERROR: column pc.down does not exist LINE 1: ...EN '1' ELSE '0' END AS enable,o.status AS status, pc.down AS... ^] /home/eccube/ec25d/html/mypage/history.php 34:LC_Page_Mypage_History_Ex->process /home/eccube/ec25d/data/class_extends/page_extends/mypage/LC_Page_Mypage_History_Ex.php 56:LC_Page_Mypage_History->process /home/eccube/ec25d/data/class/pages/mypage/LC_Page_Mypage_History.php 106:LC_Page_Mypage_History->lfGetOrderDetail /home/eccube/ec25d/data/class/pages/mypage/LC_Page_Mypage_History.php 233:SC_Query->select /home/eccube/ec25d/data/class/SC_Query.php 143:SC_Query->getAll /home/eccube/ec25d/data/class/SC_Query.php 222:SC_Query->prepare /home/eccube/ec25d/data/class/SC_Query.php 759:MDB2_Driver_pgsql->prepare /home/eccube/ec25d/data/module/MDB2/Driver/pgsql.php 965:MDB2_Driver_Common->raiseError /home/eccube/ec25d/data/module/MDB2.php 1497:PEAR->raiseError /home/eccube/ec25d/data/module/PEAR.php 557:MDB2_Error->MDB2_Error /home/eccube/ec25d/data/module/MDB2.php 1009:PEAR_Error->PEAR_Error カラム名からの推測で、こちらのスレッドへ投稿させていただきました。 ---------------- Seasoft こちらでの投稿は、アイディア程度に留めさせていただいております。個別案件の作業は有償で承っております。お気軽にご相談ください。

ECCUORE	投稿日時: 2010/11/9 9:22 対応状況: −−−
長老登録日: 2009/10/22 居住地: 東京投稿: 248	Re: ダウンロード販売機能ありがとうございます。チェンジセット19659にて、修正しました。 ---------------- EC CUORE 株式会社クオーレカスタマイズ御相談下さい。

ECCUORE	投稿日時: 2011/1/18 17:54 対応状況: −−−
長老登録日: 2009/10/22 居住地: 東京投稿: 248	Re: ダウンロード販売機能とりあえず、#792ダウンロード販売機能をCloseしたいと思います。チェンジセット19957が最終変更となります。アサインされている人が、Closeにして良いのでしょうか？ ---------------- EC CUORE 株式会社クオーレカスタマイズ御相談下さい。

« 1 2 3 4 (5)