Re: [gnue-sb-discuss] Roadmap

[Mike Vincent]

On Tue, 25 Feb 2003 17:00:51 -0700 (MST)
"Derek Neighbors" <address@hidden> wrote:
>
> We have a new game in town, Top Sew, an enterprise looking to
> implement GNUe-SB and better yet willing to contribute to it.  We also
> have two or more interested parties that have followed GNUe and
> looking to make the jump, hopefully with GNUe SB.  I would like to
> rewrite a roadmap.
> 
> I think products is still a decent start as it is more simplistic and
> is a good building block for many of the pieces to come (inventory,
> invoicing, etc)


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

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

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

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
                

Previously I'd setup my cross references to break down the mfg's line
into my family categories as well, in an effort to keep my references to
no more than 2 digits (which worked), but in the spirit of
simplification and the fact that I'm only going to potentially add 1
digit to the number over all I've decided to simply map to mfg, rather
than family.mfg. 
                
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. 

Ref# is only unique to the mfg and maybe repeated with a different mfg.
So, a snapshot of the data in the table might look like:

id   Mfg    Model    Segment  Description  Detail
1    40     xsdt     1        Sompn        Sompn very descriptive
2    40     xsdu     2        Sompn2       ...
3    40     sdjf     3        Sompn3       .... 
4    12     T4000    1        Foo          ... 
5    9      99761    1        Bar          ...

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.


Hmm..
-- 
Mike Vincent
Tops Embroidery Works
Keller, Texas
http://www.topsew.com
(817) 683-7151

sku_family.gsd
Description: Binary data

sku_mfg.gsd
Description: Binary data

sku_pmxref.gsd
Description: Binary data

sku_color.gsd
Description: Binary data

sku_size.gsd
Description: Binary data