Default pricing and custom client pricing

Hi all,

I have a personal project I'm planning and I came to a small hurdle.

I want to have an item with a price that will be the default for all
clients/users. However, in my business I have some clients that are
grandfathered in to some special pricing. In the case of these
grandfathered in cases, I'll manually plug their special price in my
admin section. Then all they will see is their special pricing while the
regular users/clients see the default price.

My current thoughts are to have a separate table called custom_pricing
with fields product_id, client_id, price and then tap into that. The
product table would have product_id and price.

What is the best and simplest way to design and implement this?

Many thanks!

-Tony

Anybody have ideas, thoughts or suggestions?

-Tony

Hi all,

I have a personal project I'm planning and I came to a small hurdle.

I want to have an item with a price that will be the default for all
clients/users. However, in my business I have some clients that are
grandfathered in to some special pricing. In the case of these
grandfathered in cases, I'll manually plug their special price in my
admin section. Then all they will see is their special pricing while the
regular users/clients see the default price.

My current thoughts are to have a separate table called custom_pricing
with fields product_id, client_id, price and then tap into that. The
product table would have product_id and price.

What is the best and simplest way to design and implement this?

Craig White wrote:

I would have a table called pricing and have a column that had the
customer_id and thus you might have 2 (or more) prices for an item but
only one for a specific customer or default to the one that is not tied
to a specific customer.

Hi Craig!

I don't think this would work as there are quite a number of clients
(over 25) who currently have a different price per product. In the
future there might be additional clients with custom pricing depending
on how much volume they push.

If I were to implement your suggestion I would have to have 25+ fields
(pricing_1, pricing_2, pricing_3, etc.) which I don't think is the
correct approach for this. Did I misunderstand your suggestion?

Thanks again,
-Tony

Craig White wrote:

> I would have a table called pricing and have a column that had the
> customer_id and thus you might have 2 (or more) prices for an item but
> only one for a specific customer or default to the one that is not tied
> to a specific customer.

Hi Craig!

I don't think this would work as there are quite a number of clients
(over 25) who currently have a different price per product. In the
future there might be additional clients with custom pricing depending
on how much volume they push.

If I were to implement your suggestion I would have to have 25+ fields
(pricing_1, pricing_2, pricing_3, etc.) which I don't think is the
correct approach for this. Did I misunderstand your suggestion?

Craig White wrote:

yes, you misunderstood... sorry if I wasn't clear enough. Something like
this, definitely not tested and perhaps you can get it down to a single
query.

Class Pricing
has_one :customer
belongs_to :item

id
price
customer_id

def self.item_price(item, customer)
  if Price.find(:first, :conditions => ["item_id = ? AND customer_id
= ?", item, customer']) then
    return Price.find(:first, :conditions => ["item_id = ? AND
customer_id = ?", item, customer']).price
  else
    return Price.find(:first, :conditions => ["item_id = ? AND
customer_id = NULL", item]).price
  end
end

Craig

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

AH! Okay - I think I got it.

So you would just remove the price field from the item table altogether
and just put it in its own table.

Any tips or resources on the best way on how to do this? Still a bit of
a rails newbie. Thanks!

-Tony

Craig White wrote:
> yes, you misunderstood... sorry if I wasn't clear enough. Something like
> this, definitely not tested and perhaps you can get it down to a single
> query.
>
> Class Pricing
> has_one :customer
> belongs_to :item
>
> id
> price
> customer_id
>
> def self.item_price(item, customer)
> if Price.find(:first, :conditions => ["item_id = ? AND customer_id
> = ?", item, customer']) then
> return Price.find(:first, :conditions => ["item_id = ? AND
> customer_id = ?", item, customer']).price
> else
> return Price.find(:first, :conditions => ["item_id = ? AND
> customer_id = NULL", item]).price
> end
> end
>
> Craig
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.

AH! Okay - I think I got it.

So you would just remove the price field from the item table altogether
and just put it in its own table.

Any tips or resources on the best way on how to do this? Still a bit of
a rails newbie. Thanks!

Craig White wrote:

> I would have a table called pricing and have a column that had the
> customer_id and thus you might have 2 (or more) prices for an item but
> only one for a specific customer or default to the one that is not tied
> to a specific customer.

Hi Craig!

I don't think this would work as there are quite a number of clients
(over 25) who currently have a different price per product. In the
future there might be additional clients with custom pricing depending
on how much volume they push.

If I were to implement your suggestion I would have to have 25+ fields
(pricing_1, pricing_2, pricing_3, etc.) which I don't think is the
correct approach for this. Did I misunderstand your suggestion?

----
yes, you misunderstood... sorry if I wasn't clear enough. Something like
this, definitely not tested and perhaps you can get it down to a single
query.

Class Pricing
has_one :customer
belongs_to :item

Should that be belongs_to: customer rather than has_one, along with
customer has_many pricings, and item has_many pricings?
I would have used class Price rather then Pricings but that is a
matter of personal preference.

Colin

id
price
customer_id

You will need an item_id also

def self.item_price(item, customer)
if Price.find(:first, :conditions => ["item_id = ? AND customer_id
= ?", item, customer']) then
return Price.find(:first, :conditions => ["item_id = ? AND
customer_id = ?", item, customer']).price
else
return Price.find(:first, :conditions => ["item_id = ? AND
customer_id = NULL", item]).price
end
end

This could be done as a named scope which might make for a neater solution.

Colin

>> Craig White wrote:
>>
>> > I would have a table called pricing and have a column that had the
>> > customer_id and thus you might have 2 (or more) prices for an item but
>> > only one for a specific customer or default to the one that is not tied
>> > to a specific customer.
>>
>> Hi Craig!
>>
>> I don't think this would work as there are quite a number of clients
>> (over 25) who currently have a different price per product. In the
>> future there might be additional clients with custom pricing depending
>> on how much volume they push.
>>
>> If I were to implement your suggestion I would have to have 25+ fields
>> (pricing_1, pricing_2, pricing_3, etc.) which I don't think is the
>> correct approach for this. Did I misunderstand your suggestion?
> ----
> yes, you misunderstood... sorry if I wasn't clear enough. Something like
> this, definitely not tested and perhaps you can get it down to a single
> query.
>
> Class Pricing
> has_one :customer
> belongs_to :item

Should that be belongs_to: customer rather than has_one, along with
customer has_many pricings, and item has_many pricings?
I would have used class Price rather then Pricings but that is a
matter of personal preference.

>> Craig White wrote:
>>
>> > I would have a table called pricing and have a column that had the
>> > customer_id and thus you might have 2 (or more) prices for an item but
>> > only one for a specific customer or default to the one that is not tied
>> > to a specific customer.
>>
>> Hi Craig!
>>
>> I don't think this would work as there are quite a number of clients
>> (over 25) who currently have a different price per product. In the
>> future there might be additional clients with custom pricing depending
>> on how much volume they push.
>>
>> If I were to implement your suggestion I would have to have 25+ fields
>> (pricing_1, pricing_2, pricing_3, etc.) which I don't think is the
>> correct approach for this. Did I misunderstand your suggestion?
> ----
> yes, you misunderstood... sorry if I wasn't clear enough. Something like
> this, definitely not tested and perhaps you can get it down to a single
> query.
>
> Class Pricing
> has_one :customer
> belongs_to :item

Should that be belongs_to: customer rather than has_one, along with
customer has_many pricings, and item has_many pricings?
I would have used class Price rather then Pricings but that is a
matter of personal preference.

----
that's an interesting question and probably reflects on the fuzziness of
my understanding of the difference between belongs_to and has_one. While
I can clearly see that the intent is that the difference is which table
has the referencing id, I tend to think of belongs_to as a 'must' and
has_one as a 'may' and in my original answer, I was contemplating a
price for each item that was not associated with any customer. If it
were left to me, I would probably create a 'retail' customer and
actually indicated that in my follow up answer.
----

The relationships are has_many and belongs_to or has_one and
belongs_to. In both cases the belongs_to is the one with the foreign
key. In this case since Customer has_many Prices, it must be Price
belongs_to Customer.

Colin