Re: [gnue-sb-discuss] Roadmap

[Derek Neighbors]

On Sun, 2003-03-02 at 08:45, Mike Vincent wrote:

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

No problem.  If it seems useful it might be worth adding to the other
'generic' tables as well.  For now I decided to let time tell.

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

Yeah I think we will need to add that to the manufacturer table.  I
didnt read the 'auto-poplutate' requirement until after I committed
stuff in, and even then I didnt think hard about it.  Was too eager to
go to bed. :)  I will have to revisit the specification, but I think it
would need a 'sequence' for each manufacturer to load off of.

> 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 hadn't thought too much one way or another.  I wanted way to see data
and figured first users would give me a good lashing as how to optimize
its usage. ;)

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

I believe that was the goal.  That 'product' information, but not
inventory information would reside on this form.

> 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

That was the original idea.  You will help proof it is a valuable one.
:)

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

I suppose I need to think this over, but one thing I was thinking of was
a 'copy' function.  Where you basically just 'copy' a product then
change one or two fields and you have it.  So in this example you would
have to key 30 products, but really it would be create one product.  Hit
copy, change one field.  Hit copy, change one field rinse and repeat.

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

Wondering if the copy feature would solve this for you.  Especially if
entry was available in a 'grid format' for quicker data entry.

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

Hmm yes the multi select box would be another valuable approach, but you
are correct in assuming the framework as it sits today doesn't support
them.

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

I dont think so.  Others will have these needs.

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

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

signature.asc
Description: This is a digitally signed message part