「ビッグスタジアム」チケットの販売


10

スタジアムチケット販売を実装したい(必要)。
アイデアは、顧客に自分のチケット数を選択させることです(上限は必要かもしれませんが、これは大きな問題ではありません。カートで許可されている最大数量でこれを達成できると思います)。その後、顧客は座席マップから座席を選択する必要があります。その後、チェックアウトプロセスは通常どおりに進みます。
誰かがこれの拡張機能を知っていますか?探しましたが、自分のニーズに合うものが見つかりませんでした。あるいは、私のグーグルのスキルを改善する必要があるかもしれません。
拡張機能がない場合、それを行う方法についてのいくつかの指針は素晴らしいでしょう。
これまでの私の考えは、いくつかのカスタムオプション(セクター、列、座席番号など)を備えた「チケット」と呼ばれる製品を作成することです。
ビューページはカスタムメイドになるため、カスタムオプションは表示されません。チケットの選択はポップアップまたはオーバーレイで行われ、選択に基づいてカートに追加するときにカスタムオプションをシミュレートします。
座席表はテーブルに保存されるので、予約した座席にマークを付けることができます。スタジアムは常に同じなので、1つのマップで十分です。
これで、これでおしまいです。欠けている継ぎ目があります。どんなポインタでも素晴らしいでしょう。
[編集]
3つの属性(セクター、行、シート番号、1の数量で各組み合わせを使用できるように構成可能な製品を作成する可能性があるため、一度購入すると使用できなくなります)は、30k以上の製品(イベント)。絶対行きたくないです。私はこれを最後の絶望的な手段として保持しています。。(これは、パフォーマンスの問題が大きくなるため、もはやオプションではありません)

回答:


10

私はこのようなことをしました、そしてこれは人為的な例でありこれが実行可能な解決策であるとみなすかどうかを見るために過度に単純化されています:

数独グリッドの定義と似ていますが、数独グリッドのオープンエリアは空席です。

$section1 = <<<SECTION

A,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,
B,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-
C,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-
D,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-
E,-,-,-,-,-,-,-,-,-,-,-,-

SECTION;

そのシートチャート(数独グリッド)は製品ごとに保存されます。すべてのイベントは新製品です。グリッドは、誰かがカートに追加すると(またはビジネスルールに応じて購入すると)更新されます。

$section1 = <<<SECTION

A,-,-,x,-,-,-,-,-,x,-,-,x,x,x,x,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,
B,-,-,-,-,-,-,-,-,-,-,-,-,-,x,-,-,-,-,-,-,-,-,-,-,-,-,-
C,-,-,-,-,-,x,x,x,-,x,-,x,-,-,-,-,-,-,-,-,-
D,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-
E,-,-,-,-,-,x,-,x,-,x,-,x

SECTION;

バックエンドモデルの空席状況を分解するのは簡単explodeです。

$chart = array();

$section = trim(explode('\n', $product->getSeatingChart()));

foreach($section as $row){
    $seats = explode(',',$row);
    $rownum = array_shift($seats);
    $chart[$rownum] = $seats;
}

$chartブール値に変えることができます:

array_walk($chart,function(&$s){
    $s = $s == "-" ? true : false;
});

A14が使用可能かどうかを確認します(0インデックス付き、覚えておいてください)。

function checkAvailability($row,$seatnum){

    return $chart[$row][$seatnum-1] == true;

}

メリット:

実装は非常に単純です。座席数の属性はバックエンドモデルによって解析されます。これは基本的にカスタムEAV属性です。セクションに基づいて価格を設定することもできます。各セクションは、新しい価格の新しいSKUです。一部のイベントでは席をブロックできますが、他のイベントではできません。また、実際の在庫を持ち運ぶ必要はありません。価格設定のためにチェックアウト時に受注アイテムに数量を設定するだけです。

階層も機能するため、一括購入割引を無料で利用できます。これはカスタムオプションの問題であった可能性があります。

欠点:

実際の在庫がないため、座席の予約は最大の頭痛の種になるでしょう。これが、このメソッドがバラバラになるところです。ビジネスルールにより、チェックアウト時に座席をロック/ホールドする方法が決まります。


1
+1わあ。「Art of Magentoプログラミング」を書いた人がいるなら、これは例としてそこにある方がよいでしょう。
kalenjordan 2013

まず第一に、私はばかのように感じていると言いたいです。もちろん、価格はセクションごとに設定する必要があります。ドー!ダウサイドまでは何も見えません。私は列を持つすべてのイベントのために予約/購入議席を保持する単純なテーブルを持つことができevent_idsectorrowseatstatus。ステータスは「予約済み」、「購入済み」、「利用不可」のいずれかです。これにより、2秒前に誰かが座席を予約したことを簡単に確認できます。また、新しい商品タイプ(イベントチケット)を作成することも考えているため、商品のセットアップに問題がないことを確認します。詳細をありがとう
マリウス

あなたの答えは私の心の中にパズルのピースをまとめるために継ぎ目です。4〜5日で3万枚のチケットを販売するとサーバーに大きな負荷がかかる可能性があるため、私はまだパフォーマンスの問題を心配していますが、これは別の問題です。この拡張が完了し、顧客から「グリーンライト」が得られたら、この拡張機能をコミュニティで利用できるようにします。
マリウス

30kチケット-これはNASCARスタジアムですか?:)セクションごと、イベントごと(イベントは構成)に単一のチケット製品を使用すると、カタログのサイズが大幅に減少すると思います。小さいdbフットプリントは、うまくいけば完全にメモリに収まります...
philwinkle

1
@philwinkle私は20世紀に住んでいて、Twitterアカウントを持っていないので、電子メールを送りました。
マリウス

2

構成可能な製品は、シートが実際に利用可能または販売されたかどうかを示す唯一の指針であり、Magento製品でこれを表現することはやり過ぎのように聞こえる場合、優れたアイデアではないことに同意します。

各イベントのレコードのテーブルを含むカスタムモジュールを提案します。チケットはこのイベント用であり、イベントの作成時に、ストアでこれを表す単純な製品が作成されます。製品属性を使用して、イベントへの参照と、購入した座席を保存するために言及するフロントエンドビューページから入力されたカスタムオプションを保持できます。


ありがとう。+1。あなたの答えとphilwinkleの答えを組み合わせると、少なくとも正しい方向に進むことができます。
マリウス
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.