RE: [mv] Inventory Control

["Christopher Thompson" <ct@arborinternet.com>]

******    message to minivend-users from "Christopher Thompson" <ct@arborinternet.com>     ******

I find the answer depends on what info the company needs to receive with
orders. That usually determines whether the item needs to be "T100  T-shirt,
green" or "T100green   T-shirt". I think separate SKUs are usually the most
flexible in the long run, but more work.

I have used a parent/child relationship, so you can have the parent show up
on listing pages and use the children to create select inputs or lists on
the detail page. I have also used SKUs for a group of products with
modifiers (e.g. color or size). This second method is easier, but only
really works if there are no price or shipping differences between items in
the group.

>
> ******    message to minivend-users from cfm@maine.com     ******
>
> On Thu, Oct 12, 2000 at 10:53:01PM -0400, Mike Heins wrote:
> > ******    message to minivend-users from Mike Heins
> <mikeh@minivend.com>     ******
>
> > > > I think the way to do this is to have separate SKUs.
>
> I had a discussion about that with one of our clients, head of a large
> accounting firm when he set up a catalog with us.  Ultimately, there
> are lots of different paths.  He does agree that if they are distinct
> items, use distinct SKUs.  Just what makes a distinct item in a
> minivend catalog is fuzzy (to say the least).  He was more interested
> in how product codes translated into bin layout.  We mapped that
> instead.
>
> Some people consider all tshirts one product, others consider
> XXL Green, cotton beefy a distinct SKU from XL Green,cotton beefy.
> FWIW, most of our larger clients running "real" accounting and
> inventory systems have distinct SKUs.
>
> Yes, making more products leads to grouping issues.  It seems
> to me easier to deal with them at display end than by mangling the
> products subsequently.  I'd guess that categories and product
> groups take care for the "children".  Often that translates into
> overloading product codes with meaning - another poor choice
> for long term.
>
>
> > I have thought about several ways of doing it, but the one thing I
> > insist on is that Interchange's database tables be maintainable by
> > other programs.  Modular bill of materials works, but is a
> living hell to
> > maintain and to understand. If the item structure relies on its routines
> > to maintain, it isn't usable by many people.
>
>
> --
>
> Christopher F. Miller, Publisher                             cfm@maine.com
> MaineStreet Communications, Inc         208 Portland Road, Gray, ME  04039
> 1.207.657.5078                                       http://www.maine.com/
> Database publishing, e-commerce, office/internet integration,
> Debian linux.
> -
> To unsubscribe from the list, DO NOT REPLY to this message.  Instead, send
> email with 'UNSUBSCRIBE minivend-users' in the body to
> Majordomo@minivend.com.
> Archive of past messages: http://www.minivend.com/minivend/minivend-list
>

-
To unsubscribe from the list, DO NOT REPLY to this message.  Instead, send
email with 'UNSUBSCRIBE minivend-users' in the body to Majordomo@minivend.com.
Archive of past messages: http://www.minivend.com/minivend/minivend-list