Re: [gnue-sb-discuss] Roadmap

[Mike Vincent]

On 28 Feb 2003 14:33:56 -0700
Derek Neighbors <address@hidden> wrote:

> On Thu, 2003-02-27 at 08:47, Mike Vincent wrote:
> 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.

Everything worked ok with exception to the item_category form and I
committed the small fix that got it working. And actually, I can see how
I might want to use the parent/child relationship in there, so thanx for
leaving it. =)

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

That would be so handy if it were auto populating. I entered several
products from one mfg and keying in the ref manually wasnt a big deal
until I started keying another mfg's products in where it became more 
difficult to remember where in the sequencing I was. 

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

I've been thinking a little bit about the item maintenance form.
Thinking about it in how it will be used. This form will be the glue
which ties everything together, and I also see it as a snapshot of a 
product in all it's glory. I cant help but wonder if there is a way
to back the degree of granularity off slightly. 

I'm assuming that right now, the plan for this form is to provide a 
means to create/edit a specific product or all the details which we 
need to go with the product such as UPC, unit, price, lot qtys, etc..
Exactly what all that entails is debatable I guess perhaps there 
may be a need for a seperate form for maintaining inventory and this 
form simply maintains the product.. What I see when I think of using
this form is this.. Say I am adding a new shirt to my product line, 
the shirt comes in 5 sizes and 6 color combinations. Based on my 
assumptions of how the form works, I will need to visit this form 30
times to completely add it to the line. That seems rather burdensome. 

What I've been pondering, is if instead there may be a way to
consolidate the task to one visit. For the most part I only work with
the first 3 segments of my SKU (call it a catalog# or product#) as 
knowing that much, I know what product I'm dealing with just not the
details of which color or size. 

If the item maintenance form were to allow me to 'build' my catalog#'s 
then specify a series or colors and a series of sizes, then I would 
only need to hit the form one time to manipulate a product, rather 
having to hit it for every possible variation of the product. I dont
know if that's even possible with the present day tools, I think it 
would require a multiple select list box or something. I guess it 
could also be done using a multipage form and have a bunch of entry
boxes on page 2 to pick/add colors ditto page 3 to pick/add sizes. I'm 
still not completely familiar with the abilities and limitations so 
I'm not completely sure how it could be approached. But if there were
a way, then when the product were committed the form would do the leg
work to create/change/delete the SKUs.. 

Then again, maybe this drifts away from being generic.. =/ 


-- 
Mike Vincent
Tops Embroidery Works
Keller, Texas
http://www.topsew.com