Re: [gnue-sb-discuss] Roadmap

[Derek Neighbors]

On Thu, 2003-02-27 at 08:47, Mike Vincent wrote:

> I'm excited and ready to get to work! I think if we can work out the
> schema for product management then things will start to flow right
> along. I'd mentioned before that I'd already been playing with this

I tend to agree.  As product listings is pretty basic, but its necessary
for most backend functionality.  

> a little bit. I've attached the .gsd files I created during my playing, 
> wether they're useful or not I dont know. I would attach the forms, but
> I had created them using the 0.5 tools so they wont work with the 0.4.3 
> release we'll be running with. The only ones I finished were the simple
> ones anyhow, and they were just slightly modified copies of the lu_*
> forms which are in the item mgmt directory now, IIRC. 

I have modified what you have sent here and checked into cvs. 

> I am not completely clear how to proceed after our last IRC chat where
> we decided to create 5 or 6 generic categories and use dynamic labels in
> the forms so people label them for thier specific purposes.

As discussed on IRC.  I have created an item_mfg table and a
corresponding item_mfg_model number which is nothing more than a
crossreference to preserve manufacturer model numbers.  The remaing 4
tables are completely generic segment holders: item_class,
item_category, item_group and item_type.  Note, item_category existed
before and had the ability to denote a 'parent' category.  I left this
functionality so there is a generic table that can have nested
functionality for reports.

> The system that I use to organize my products relies entirely on
> lookups, Each product is identified by a 5 segment number where the
> segments are:
> family . mfg . product (crossref) . color . size
> 
> so a number like C.14.4.20.1 could be broken down as:
> C     (Caps/Headwear)         The Family
> 14    (BigHead Caps)          The Mfg
> 4     (BHmodel# 46323)        The Mfg's model#
> 20    (red/white/blue)        The color option
> 1     (adjustable/cap)        The size

I believe all these pieces of functionality have been preserved.  All
segments are able to hold 6 alpha/numeric.  We will in the beginning NOT
zero pad this and use 'delimiters' in product numbers.  A future goal
would be to add options to 'zero pad' as well as change delimiter and/or
eliminate it.

> So my labels will be: Family, Mfg, Product, Color, & Size. 

Haven't gotten to the item_maint.gfd form just yet.  The others should
all exist. :)

> The tables and forms needed to work with family, mfg, color, and size
> data are pretty simple, and I really dont care what they're called in
> the db/code, what I've named 'segment' here would be the visible part of
> the SKU, so for the family table segment's value would be A for the
> apron family, C for the caps family, etc.
>   id
>   segment
>   description
>               
> The crossref table maps mfg.model <-> our-reference
>   id
>   mfg
>   model
>   segment             
>   description
>   detail
>               

I think I held to this acceptably.
                
> I image a form something like: (not married to this layout, though)
> 
> #########################################################
> # Mfg:   [ABC Company -]                                #
> # Model# [P324         ]                                #
> # Ref#   [12  ]                                         #
> # Desc: [                                             ] #
> # Details:                                              #
> # [                                                   } #
> # [                                                   } #
> # [                                                   } #
> # [                                                   } #
> # [                                                   } #
> #########################################################

> Where the Mfg is a dropdown, model is a regular entry
> Ref is automatically filled in after the mfg.model combo
> is known. 

This form should be there as you have pasted here.  The Mfg has a
lookup, but I dont have Ref# auto populating.

> The schema that I used when I made this system wasnt very flexible, but
> it served my purposes. I included pricing information, qty's for price
> break levels, and all sorts of other information that I now think would
> be better put into seperate table(s) such as pricelist or some such.
> That is where I stopped playing. As I thought about this I could see
> several ways to approach the schema design, and didnt want to stray too
> far from what might eventually be used in gnue-sb.

As soon as we verify all the "segment" lookup tables and get them
incorporated into an item maintenance form we can start discussing
additional fields.  Felt like we got somewhere last night.  Hopefully it
can continue.

-- 
Derek Neighbors
GNU Enterprise
http://www.gnuenterprise.org
address@hidden

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=dneighbo