[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[gnue-sb-discuss] Re: GNUe-SB-Discuss Digest, Vol 2, Issue 7
From: |
Kenneth D. Reiszner |
Subject: |
[gnue-sb-discuss] Re: GNUe-SB-Discuss Digest, Vol 2, Issue 7 |
Date: |
Sun, 09 Mar 2003 15:44:52 -0600 |
>
> pricing.. pricing pricing pricing..
>
> stdprice
> price1
> price2
> price3
> price4
> ... ? Is there a better way to do this?
> Is there a genericly acceptable number of price variations?
> I think 5 or less seem to be most common in my industry.
>
> I am thinking that when I setup my clients, I will want a field to
> specify which column of pricing will be used for the client as their
> standard pricing, for most it would be 'the' std price but I may want
> to set it to one of the others for a high volume client.
>
> For me, which column to use is based on the volume of a given product
> that is being purchased. Presently, I base the volume on the sum per
> catalog#, which is the item without variations (color, size) taken
> into account. So as long as someone orders a total equal or greater
> to a certain qty of Nike model#167316, I dont care what colors or
> sizes they order, I'll give them a better than std price. The actual
> 'watermark' for where those price breaks happen differs depending on
> the product. Typically it's something like stdpricing upto 23pcs,
> then Tier1 pricing until 47pcs, then Tier2 pricing until 143pcs,
> then Tier3 until.. etc. Maybe the best way to acheive that is to have
> yet another table to hold those volume watermarks per product?
>
> I have another wish list item in all this..
> It would be really nice if the system offered some level of protection
> from selling things below a certain level of profit. I mean, it would
> be nice if there were another form where I could key in values for
> markup and discounts (for the tiers) and have it use these values to
> in combination with the values of cost of goods from purchases to make
> sure that the prices are in line, probably automagically correcting
> prices where needed or at least raising a flag.
>
> Ideas? Comments? Hammers?
>
> I hope I'm not overcomplicating things, I do have a knack for that.
>
>
I currently use create a new item for each training session I give because
they are never the same which is very cumbersum. The separate table idea
sounds good to me but the sooner a complete or at least working billing system
is available means something also.
There is one thing I really hate though is trying to move data from something
that is working marginally to a new improved system that is more robust. I
like the idea of overbuilding or a clear route to transfereing data.
A user,
Kenneth D. Reiszner, Ph.D.
President
REAL, Inc.
P.O. Box 709
Lecompte, LA 71346
Ph.No. & FAX: 318-443-0426
> Mike Vincent
> Tops Embroidery Works
> Keller, Texas
> http://www.topsew.com
>
> ------------------------------------------------------------------------
> _______________________________________________
> GNUe-SB-Discuss mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnue-sb-discuss
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [gnue-sb-discuss] Re: GNUe-SB-Discuss Digest, Vol 2, Issue 7,
Kenneth D. Reiszner <=