[gnue-sb-discuss] Re: GNUe-SB-Discuss Digest, Vol 2, Issue 7

[Kenneth D. Reiszner]

>
> 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