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

On Mon, 2010-03-22 at 17:52 +0100, Tony T. wrote:

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?


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.

Craig


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

Craig W. 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 W. 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

On Tue, 2010-03-23 at 03:02 +0100, Tony T. wrote:

(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

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.

On Tue, 2010-03-23 at 03:28 +0100, Tony T. wrote:

price
end

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!


I would not have a ‘price’ column in my items table at all. I might
consider having a customer ‘1’ that was say ‘retail’ and customer ‘2’
that was say ‘wholesale’ and maybe even customer ‘3’ that was Internet
so I could have all sorts of different pricing levels for each item in
addition to having customer specific pricing.

Thus you could define in the Pricing model, things like…

def self.default_price
return Price.find(:first,
:conditions => [“item_id = ? AND customer_id = ?”, item, 1]).price
end

etc.

Exploit the power of models

Craig


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

On 23 March 2010 02:15, Craig W. [email protected] wrote:

I don’t think this would work as there are quite a number of clients
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

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

Colin

On Tue, 2010-03-23 at 08:53 +0000, Colin L. wrote:

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.

id
price
customer_id

You will need an item_id also


yes

end

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


probably true and probably how I would end up doing it. It was just a
top of my head answer and the defined method could easily be converted
into a named_scope.

Craig


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

On 23 March 2010 15:08, Craig W. [email protected] wrote:

Hi Craig!
yes, you misunderstood… sorry if I wasn’t clear enough. Something like
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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs