購入フローの短縮化

[shinichi-takahashi]

購入フローのステップを短縮化する。

[shinichi-takahashi]

11月末に実施した合宿の成果物として作成途中（正常系はほぼOK、バグが残っている）のものがあるため、そちらをベースに開発していきたいと考えています。

[nobuhiko]

WIP!WIP!

[Yangsin]

短縮イメージ

お届け先の複数配送イメージ

合宿の成果をごちゃごちゃですがアップしているリポジトリ：　
　https://github.com/poego/ec-cube/tree/camp2014-ui-team

[ttsuru]

👍

[chihiro-adachi]

購入フローを整理しました。
現状の問題点やこうあるべきなど、ご意見うかがいたく。

前提

考え方

• カートでの表示と確認画面での表示はずれてもよい
• 確認画面の表示と、完了処理時のデータは同一であるべき(確認画面の表示内容がそのままDBに保存される)
• カート≠確認=完了となる

完了時の処理

• 税金や商品価格等は、確認画面の内容をそのままDBへ保存する
• 在庫は、DB上の在庫をチェック、足りなければエラーにする

画面遷移およびCRUD

https://drive.google.com/file/d/0B9GUvngXP1KGWFplZ3pkUGk0dFk/view?usp=sharing

データ定義

カート

データ構造

$cart["selected"] = $product_type_id
$cart["carts"][$product_type_id]["locked"] = true/false
$cart["carts"][$product_type_id]["pre_order_id"] = uniq id // dtb_order.order_tmp_id
$cart["carts"][$product_type_id]["items"][$product_class_id][quantity]
                                                            [product_class_entity]

• 商品種別ごとにカート情報を持つ
• selected
  • どの商品種別のカートが選択されたか。product_type_idが入る
• pre_order_id
  • dtb_order.order_tmp_idが入る
  • 購入確認側で発番しセット
• locked
  • カート画面で、購入フロー遷移時にロックする
  • 購入確認画面側では、ロック状態を確認
  • カートへの商品追加や数量変更の際にロックを外す
• items
  • カートの明細行
  • 商品規格ID単位でデータを持つ

参照：#82

関連テーブル

dtb_order_tempは利用しない
dtb_orderに確定フラグを持たせる。購入完了時にフラグ更新。

その他要検討事項

リンク型決済の画面遷移で、以下を検討必要。現状では、遷移前に在庫確保している。

• 在庫引当のタイミング
• 利用ポイント引当のタイミング

[ttsuru]

もう少しオブジェクトっぽい処理でも良いような気がします。
特に、registerなどを意図的に呼ばなくても良い方が良いのではないでしょうか。

例えば、Symfonyで使っているSessionをextendする実装もありだと思います。

[nanasess]

データ構造はオブジェクトにはしないのですね。。。

[shinichi-takahashi]

@ttsuru @nanasess
CartEntityを定義して実装していってみてますが、CartServiceから２つのカート（通常商品・ダウンロード商品）を制御するのにかなり苦戦しております。

具体的には、以下、２点の問題がぐるぐるしています。

# setPreOrderId()は、どちらのカートに作用する？
$app['eccube.service.cart']
  ->addProduct('通常商品1', 1)
  ->addProduct('DL商品2', 2);
  ->setPreOrderId($nextOrderId);

# 通常のカートを指定した後に、DL商品を追加しようとした時、どうする？
$app['eccube.service.cart']
  ->selectCart('normal')
  ->addProduct('通常商品1', 1)
  ->addProduct('DL商品2', 2);

後者の、 addProduct('DL商品') 時にDLカートに入れて、その他情報は変更しない、というのが今のところ適切かと思うのですが、

if ($typeId === self::PRODUCT_TYPE_NORMAL) {
  $this->cartNormal->addProduct(hoge, fuga);
} else {
  $this->cartDownload->addProduct(hoge, fuga);
}

このようなコードを量産することになってきます。。
何かいい方法ありませんか？

[pineray]

横からすみません。
そもそもの質問ですが、カートを分ける理由は何でしょうか？

[nanasess]

カート分けた人です。
http://svn.ec-cube.net/open_trac/ticket/823
定期購入などを考慮して、購入フローを決済モジュールなどから柔軟に分岐させたかったからですね。
カートを分けなくても、支払い方法や、購入ステップをプラグインなどで柔軟に変更できるのなら、分けなくてもいいと思います。

[nanasess]

クール便と、通常商品の同梱など、2.13 までの購入フローでは解決できないケースの業務もよくあるので、できることならカートを分けない方がいいと思います。

[nanasess]

ただ、同時購入できても、発送が別々になるケースも考慮する必要はありますね。

[nobuhiko]

商品種別の同時に購入ができない、は定期購入には有効だと思うのであった方がいい機能だと思いますが、それとダウンロード商品は全く関係ないかなと個人的には思います

複数配送先の機能で別送・同梱を考えられるようになればそこで対応できるんじゃないでしょうか

[ttsuru]

カートを分けられるようにする機能と配送なしを別で持った方が良さそうですね。
配送計算に DeliveryService と NoDeliveryService 的なイメージでしょうか。

[shinichi-takahashi]

@nanasess

クール便と、通常商品の同梱
同時購入できても、発送が別々になるケースも考慮

• 自動配送先振り分けのロジックを入れる
• 発送が別々になる旨のアラートを出す(送料が２倍になる)
• dtb_shippmentにdeliv_idを持たせる(既存はdtb_orderにある)

上記で解決できないでしょうか？

[shinichi-takahashi]

また、DL商品について、提案です。

DL商品（配送方法「なし」が指定されている商品）の場合、カート画面を飛ばして、
都度購入画面に遷移する、ではどうでしょうか？

オーナーズストアやKindleStoreがそのつくりになっていて、
プログラム的にも考えることが減りますし、フローも合理的かと思います。

[nanasess]

できる限り柔軟に設定できる実装で、プラグインなどで、プログラムの上書きをせずに、柔軟に拡張できるのであれば、強い拘りはないです。

ただ、 if ($product_type_id == PRODUCT_TYPE_DOWNLOAD) { のような条件分岐は不具合の温床になりやすいので極力無くしたいですね。

当時は、2.4系のガチガチ密結合ロジックを無理矢理拡張して、柔軟性を求めた結果、購入フローを分けたまでなので。。。

[shinichi-takahashi]

一定の答えといえそうな結論に辿りついたので、以下の方向性で行きたいと思います。

サマリー

• 配送方法が異なる商品がカートに入っている場合、購入確認画面で、
  自動で配送方法を複数に分割し、アラートを出す
  • アラート例：カートに入っている商品は、単一の配送方法でのお届けができません。
    複数の配送情報として設定しています。
• カートに商品を追加するとき、"追加しようとする商品に紐づく支払方法"が、カート内商品と重複がなくなる場合、カートに追加できない。

前提条件

• 商品種別
  • 通常商品α
    • 配送方法：配送A, 配送B
  • 通常商品β
    • 配送方法：配送B
  • DL商品
    • 配送方法：配送なし
  • クール便商品
    • 配送方法：配送C
• 配送方法に紐づく支払方法
  • 配送A
    • カード決済、代引、銀振
  • 配送B
    • 代引
  • 配送C
    • 銀振
  • 配送なし
    • カード決済

購入ユースケース１

1. 通常商品αをカートにいれる
2. クール便商品をカートにいれる
3. 購入確認画面にすすむ
   -> 配送自動分割機能が働き、その旨のアラートが表示されている。
   ※通常商品αは配送A, B、クール便商品は配送Cが設定されており、同梱できないため。

購入ユースケース２

1. 通常商品βをカートにいれる
2. クール便商品をカートにいれる
   -> クール便商品はカートに追加されない
   ※支配方法がそれぞれ、通常商品β：配送B-代引き、クール便商品：配送C-銀振のみとなり、単一の支払い方法での購入が不可能な状態になってしまう。
   このとき、カートに入れることができないようにする。

こちらの仕様での実装を進めていきます。
仕様については、一旦ここで切らせてください。

ご意見ありがとうございました！

[nanasess]

-> クール便商品はカートに追加されない ※支配方法がそれぞれ、通常商品β：配送B-代引き、クール便商品：配送C-銀振のみとなり、単一の支払い方法での購入が不可能な状態になってしまう。 このとき、カートに入れることができないようにする。

カートを分けた経緯が、まさしくここで、

• 同時購入はできないけれど、購入中エラー表示が出るとストレスになる
• そこで「エラーにしないけど、同時購入はできないようにするためにカートを分ける」
  という結論に至ったのでした。

こういったケースも思慮済みでしたら問題ございません。

[shinichi-takahashi]

@nanasess

• 複数配送を一括で注文できること
• 支払方法の重複がない組み合わせでの購入が起きることが考えづらいこと
  この２点から、こちらの方針にたどり着きました。

エラー表示が出るとストレスになる
ボタンを変化させることで同時購入ができないように制御するなど工夫できるかと思います。
多少無理やりですが。。

こちらを立てればあちらが立たず、と堂々巡りになってしまいそうなので、
一旦、私と @chihiro-adachi で、こちらの実装をしてみます！

[shinichi-takahashi]

一旦方向性FIXして進めておりますので、本件Closeいたします。