Re: [gnue-sb-discuss] Roadmap

[Mike Vincent]

On 02 Mar 2003 22:10:05 -0700
Derek Neighbors <address@hidden> wrote:

> On Sun, 2003-03-02 at 08:45, Mike Vincent wrote:
> > > 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.

Interesting approach, just add an int field to each mfg and increment it
as records are added? Works for me. I suspect this was why you were
asking about the handling of schema modifications in IRC. I dont mind
'working around it' as you put it, in this case I think it would be
trivial to go and set the sequence manually for the mfg's I've keyed
data in for.. I dont know how else we could do it but to write a script
that queried the db and insert the proper values based on the queries..
and I assume there's a way to do that using gnue-common so you could
take advantage of the db abstraction as well. Dont do it on my behalf
though =) 

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

The copy button sounds fine. I'd be content with that, especially if I 
understand you correctly, that the button would copy the last record.
As then I'd have a reminder of what color/size (in this case) I had 
just entered and change to the next option.. If rather it just copies
one record over and over, that would be fine too. 

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

Ok, back to the roadmap.. Warning, this is about to turn into a
pretty long email. =)

Once we're done setting up the product line (almost there), I want to
establish the price list. Either on it's own, or piggy backed with 
product mgmt or ...? I imagine a table with: sku, list price, Tiers
for discounted prices, and qty levels to set atermarks where discounted
prices are given. (tier 1, tier 2, tier 3, and tier 4, qty1, qty2, qty3,
qty4) perhaps (later) a provision to specify a product is 'on sale',
maybe a means of setting the duration of the sale or an end date. "This
week only, get Tier4 pricing regardless how many you order!" Just a 
thought, sales arent important (to me) at this juncture. 

>From there I intend to focus on getting my clients and vendors into the 
system. This is one of the things I'd like clarification on. What is or
will be the correlation between contact mgmt and client/vendor tables?
Seems that with some additional information such as the relationship
(client, vendor, other?) and a visible id# to use elsewhere to easily
identify them (client#, vendor#).. and perhaps a few other pieces of
information like status, company name, taxable?, balance($), notes, 
acct# (given to us by a vendor), terms, etc.. that might be all I need
to get my customers and vendors set up. 

Design Managment. Designs are a special product for us.. I thought about
cataloging them right in with the items, but I think it might be best 
to keep them seperated as the information I want to have on designs is
pretty different from what I want to have for items. They'll be
categorized in a similar fasion,D.client#.design#.width.height
which is why I want to get my clients setup first, and have a way of
identifying a client by number. I guess thinking about how (if I 
understand it correctly) we're going to keep the sequencing on the
products, the same thing could be done here. The kind of information
I need to keep on designs is:
  name (a name given to the design, "The holy goat logo" etc.)
  status (setup, processing, review, edit, rejected, approved)
  date started (when art was received)
  date created (when design was ready)
  created by   (who did the design)
  date apprpoved (date design was approved)
  approved by    (specific person who gave the approval)
  stitch count   (number of stitches in the design)
  number of colors  (number of colors in the design)
  internal design notes (production notes, etc)
  customer design notes (notes the customer gives us)
  setup cost
  price
  

Quotes.. a simple form to generate and archive quotes.
  quote#
  status
  date created
  client#
  attn
  expires
  created by
  notes

    Quote items 
    catalog# 
    description
    qty1
    price1
    qty2
    price2
    qty3
    price3

Sales.. 
  so#
  status
  date created  (date taken)
  request date  (date they want it)
  schedule date (our promise date)
  client# 
  PO/ref#
  ship via
  total  
  notes

    Line items
    lid
    so#
    line#
    sku
    qty
    price ea
  


WorkOrders.. each line item of a sales order could potentially have
several work orders assigned to it. A work order describes what design
is being put where and at what cost.
So for example, it's possibel I may order a shirt and want design
D.1.12.100.30 put on it's left chest, then the words "Free Your
Enterprise!" put on the right sleeve. This would require 2 work orders.
  wo#
  status
  lid
  client#
  design#
  location
  notes
  cost


and of course Invoices.. 
  inv#
  date
  due date
  po/ref#
  payment method
  tax
  freight
  shipping method
  tracking#
  notes
  invoice line items.. 

Purchase orders.. 
  po#
  date
  due date
  ship via
  payment method
  tax freight
  confirmation#
  etc.. 
 po line items..

I havent thought much past that.. and I think that's more than enough to
chew on.. 


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