deal/group buying extension

[Stephane]

Hi,

I am currently working on a "deal" extension like groupon meaning:
- once we reach a 'minimum_quantity' the deal is validated
- there is a started_at and ended_at datetimes
- a promotion, I was thinking about using the promotion model but I
need to investigate more.

So basically I've dig through the code and my thinking is :

class Deal
belongs_to :product
belongs_to :promotion
has_and_belongs_to_many :orders
end

class Product
has_one :active_deal, :class_name => "Deal", :conditions => "active
= true"
end

There is only one "active" deal per product means started_at <
Time.now < ended_at.

So when we are adding a product to the cart, it is basically adding a
product with an active deal so the its reflects its promotion in the
item/cart price.

Any guidelines would be appreciated,

Thanks.

[Brian Quinn]

Stephane,

Sounds interesting, what do you mean by "when we reach a 'minimum_quantity' the deal is validated".

If you mean a minimum quantity of completed orders I'd suggest  the following :

- add an additional order state of something like "pending_deal", so when an checkout completes it goes to this state and only authorizes the payment.

- use a delayed job to monitor the "pending_deal" orders counts, and capture the payment if the minimum is met, or void the payment if the deadline is met. And notify the customers.

You can still use the Promotion system to actually grant the discount as it can check for products in an order before applying a discount, and it has start and end dates.

I don't think you need the Deal object.

-- 

Brian Quinn

Spree Commerce

--

You received this message because you are subscribed to the Google Groups "Spree" group.

To post to this group, send email to spree...@googlegroups.com.

To unsubscribe from this group, send email to spree-user+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/spree-user?hl=en.

[Stephane]

Brian,

Thanks for your help.

A minimum quantity in my case, is regarding the quantity of items.
A deal :
- is valid when a minimum quantity of this product have been ordered
within a given timeframe.
- consist of only one product discounted at a given price.

Lets take an example :
Product:
Tshirt A
variants: color red, blue, green
price: 50
Deal :
Deal A
minimum_quantity : 20
started_at: today
ended_at 1 weeks from now
product: Tshirt A
discount price: 30

So if a customer buys the TshirtA in red and blue, the deal A has 18
left to be valid.
The order should show a total price of 30 x 2.
I know that the price can depends on the variant, I am just assuming
that we could simplify things like this.

The deal object would allow me to :
- have a tab which list all the deals validated or not.
- trace from which deal this product has been ordered (I can have
previous deal on this product)

I was thinking about using the promotion system where we would
automatically have a 'dealpromotion' associated to our deal and would
be triggered as soon as we add any deal product in a cart.

I hope my explanation is clear enough.

Thanks !
Stephane,

> > To post to this group, send email to spree...@googlegroups.com (mailto:spree...@googlegroups.com).
> > To unsubscribe from this group, send email to spree-user+...@googlegroups.com (mailto:spree-user+...@googlegroups.com).

[Brian Quinn]

Stephane,

That exact case is currently supported by the promotions system. 

- "Promotion Rules" what mandate that certain products (or variants) must be included in the order (and the quantity of those products).

- "Promotion Actions" can apply percentage or flat rate discounts to the order.

- Promotions can have expiry dates. 

So no need for any code here.

--

Brian Quinn

Co-Founder, CTO

Spree Commerce, Inc.

http://spreecommerce.com

To post to this group, send email to spree...@googlegroups.com.

To unsubscribe from this group, send email to spree-user+...@googlegroups.com.

[Stephane]

I see but in our case, we want to have the notion of 'minimum
quantity'.
If I try to follow your previous post I would have:

Order:
- new state : pending_deal
- order is set to pending_deal state if there is at least 1 product
with a deal in the cart (we can possibly have many products with/
without deal in a cart)

DealJob:
- get all the orders with the pending_deal state containing products
with this deal.
- if deal is valid
  - capture their payments
  - notify customers
  - set deal state to complete when job finishes.
  - set order state to complete if all products with deal are complete
- if not valid
  - void payments
  - notify customers
  - set deal state to canceled when job finishes
  - set order state to canceled

Deal:
- belongs to a product
- on create push a DealJob to run after the deal ended_at
- valid when minimum_quantity is reached
- belongs_to + accepts_nested_attributes_for deal_promotion
- attributes like started_at, ended_at is delegated to promotion

DealPromotion < Promotion
- promotion rules is automatically set to "item added to cart"
- promotion actions is automatically set to "discount product"

I strongly believe we need a deal object to keep track of all this
flow, what do you think ?

Stephane.

On Feb 2, 11:01 am, Brian Quinn <br...@spreecommerce.com> wrote:
> Stephane,

> That exact case is currently supported by the promotions system.
>
> - "Promotion Rules" what mandate that certain products (or variants) must be included in the order (and the quantity of those products).
> - "Promotion Actions" can apply percentage or flat rate discounts to the order.
> - Promotions can have expiry dates.
>
> So no need for any code here.
>
> --
> Brian Quinn
>
> Co-Founder, CTO

> Spree Commerce, Inc.http://spreecommerce.com

[Brian Quinn]

I think I'm missing the point regarding what exactly the minimum quantity is.

Is it:

A) A minimum quantity PER order

B) A global minimum quantity where you need to sell X units spread over any number of separate orders (to different customers). If X isn't met no-one gets anything, when X is met everyone gets their orders confirmed?

If it's B then you do need some sort of Deal model.

--

Brian Quinn

Co-Founder, CTO

Spree Commerce, Inc.

http://spreecommerce.com

To post to this group, send email to spree...@googlegroups.com.

To unsubscribe from this group, send email to spree-user+...@googlegroups.com.

[Stephane]

Sorry for the confusion, minimum quantity is exactly B as you
explained.

Thanks I will try to follow my previous post.

I will keep this post up to date as I progress.

Stephane.

On Feb 2, 2:25 pm, Brian Quinn <br...@spreecommerce.com> wrote:
> I think I'm missing the point regarding what exactly the minimum quantity is.
>
> Is it:
>
> A) A minimum quantity PER order
>
> B) A global minimum quantity where you need to sell X units spread over any number of separate orders (to different customers). If X isn't met no-one gets anything, when X is met everyone gets their orders confirmed?
>
> If it's B then you do need some sort of Deal model.
>
> --
> Brian Quinn
>
> Co-Founder, CTO

> Spree Commerce, Inc.http://spreecommerce.com
>

[Stephane]

Brian,

I have been looking through the code about promotions, adjustment and
calculators.

Considering a promotion:
- event_name : spree.cart.content_changed
- rules : match a specific product
- action : flat rate per item with amount.

Adding the product matching this promotion rules results in an
adjustment on the order total.

So this prevents us to reflect the discount in the cart's line_item.

How would you proceed ?

Thanks,

Stephane.

> > > > > > > To post to thisgroup, send email to spree...@googlegroups.com (mailto:spree...@googlegroups.com).
> > > > > > > To unsubscribe from thisgroup, send email to spree-user+...@googlegroups.com (mailto:spree-user+...@googlegroups.com).
> > > > > > > For more options, visit thisgroupathttp://groups.google.com/group/spree-user?hl=en.

>
> > > > > --
> > > > > You received this message because you are subscribed to the Google Groups "Spree"group.

> > > > > To post to thisgroup, send email to spree...@googlegroups.com (mailto:spree...@googlegroups.com).
> > > > > To unsubscribe from thisgroup, send email to spree-user+...@googlegroups.com (mailto:spree-user+...@googlegroups.com).
> > > > > For more options, visit thisgroupathttp://groups.google.com/group/spree-user?hl=en.

>
> > > --
> > > You received this message because you are subscribed to the Google Groups "Spree"group.

> > > To post to thisgroup, send email to spree...@googlegroups.com (mailto:spree...@googlegroups.com).
> > > To unsubscribe from thisgroup, send email to spree-user+...@googlegroups.com (mailto:spree-user+...@googlegroups.com).

[Stephane]

Brian,

I have been struggling around the cart line item and variant prices.

I basically want a product to have (like amazon does) :
- List Price
- Price : real price of the product used in the cart.

Adding a field like "list_price" column to variant would be enough to
reflect a discount instead of having adjustments on the order total.

What do you think ?

Stephane.

[Brian Quinn]

Yes, adding list_price is sufficient provided everyone pays he same actual price. Using promotions would allow for additional flexibility, for different prices for different sets of users / conditions, albeit at the cost of extra complexity.

--

Brian Quinn

Co-Founder, CTO

Spree Commerce, Inc.

http://spreecommerce.com

To post to this group, send email to spree...@googlegroups.com.

To unsubscribe from this group, send email to spree-user+...@googlegroups.com.

[Ann-Caryn Cleveland]

I've been wanting to do the same. Stephane.  Would love to touch on this at the conference!

[Stephane]

Brian,

Thanks for your suggestions.

We talked about the 'deal_pending' state for an order
So basically I am following the whole order workflow + a new state
event :

event :deal_pending do
transition :to => 'deal_pending', :from => 'complete'
end
after_transition :to => 'complete', :do => :deal_pending!, :if
=> :has_active_deal?

what should happen once a deal is complete and payments are captured ?
Should we switch orders back to a 'complete' or a new state like
'deal_complete' ?

'complete' would eventually process a payment cf

before_transition :to => 'complete' do |order|
begin
order.process_payments!
rescue Core::GatewayError
!!Spree::Config[:allow_checkout_on_gateway_error]
end
end

maybe I can skip this part if I come from 'deal_pending' state?

Thanks,
Stephane.

On Feb 12, 6:27 pm, Brian Quinn <br...@spreecommerce.com> wrote:
> Yes, adding list_price is sufficient provided everyone pays he same actual price. Using promotions would allow for additional flexibility, for different prices for different sets of users / conditions, albeit at the cost of extra complexity.
>
> --
> Brian Quinn
>
> Co-Founder, CTO

> Spree Commerce, Inc.http://spreecommerce.com

>
> On Sunday 12 February 2012 at 17:11, Stephane wrote:
>
>
>
>
>
>
>
> > Brian,
>
> > I have been struggling around the cart line item and variant prices.
>
> > I basically want a product to have (like amazon does) :
> > - List Price
> > - Price : real price of the product used in the cart.
>
> > Adding a field like "list_price" column to variant would be enough to
> > reflect a discount instead of having adjustments on the order total.
>
> > What do you think ?
>
> > Stephane.
>

> > On Feb 4, 3:11 am, Stephane <stephanebou...@gmail.com (http://gmail.com)> wrote:
> > > Brian,
>
> > > I have been looking through the code about promotions, adjustment and
> > > calculators.
>
> > > Considering a promotion:
> > > - event_name : spree.cart.content_changed
> > > - rules : match a specific product
> > > - action : flat rate per item with amount.
>
> > > Adding the product matching this promotion rules results in an
> > > adjustment on the order total.
>
> > > So this prevents us to reflect the discount in the cart's line_item.
>
> > > How would you proceed ?
>
> > > Thanks,
>
> > > Stephane.

> > > On Feb 2, 2:31 pm, Stephane <stephanebou...@gmail.com (http://gmail.com)> wrote:
>
> > > > Sorry for the confusion, minimum quantity is exactly B as you
> > > > explained.
>
> > > > Thanks I will try to follow my previous post.
>
> > > > I will keep this post up to date as I progress.
>
> > > > Stephane.
>

> ...
>
> read more »

[Brian Quinn]

So I'm thinking you'd need a Delayed Job (or some external process), that would run occasionally and check how many orders are in the "deal_pending" state.

If the order count equals the minimum required, then it would capture the payments and return each to the "completed" state.

If the deal deadline expires without reaching the minimum required orders then it would void all payments and set the orders to "cancelled"

One other tricky issue to handle is if an order contains any non-deal items. There's two ways to handle this:

1) Prevent customers mixing deal and non-deal items together. You probably only want one deal per checkout.

2) Split each order into a number of sub-orders once completed.

Option 1 is the easiest by far, but I've seen option 2 done and working, but requires a Payment Method that supports payment profiles so you can create lots of separate charges.

-- 

Brian Quinn

Spree Commerce

[Stephane]

Initially we want to manually confirm / cancel deals and also
capture / void payments.

Basically in order:

1)when a deal deadline expires, a delayed job set the deal to
'expired' state and notifies by email admin

2)admin decide manually to confirm or cancel the deal, then it notify
customers about the deal's state.

3)admin manually capture / void payments each order payment

3)admin updates variants.on_hand= attribute to changes deals product
from backordered to sold.

4)admin set shipment tracking, etc..

In the near future, I would definitely automate this process as you
suggested but we want to try out this approach to deal with edge
cases.

Assuming we have an order containing complete + canceled deals and we
are shipping an order once we have every complete deal on hand:
1) - authorize the item total during checkout
- only capture the total of complete deal (would be less than the
item_total checkout) is possible?

2) create separate payments like 1 per deal but I guess there would be
transaction fees on each of them so...

You can checkout what I've done so far : https://github.com/sbounmy/spree_deal

Please let me know if you have any suggestions.

Thanks,

Stephane.

> ...
>
> read more »