Re: Inventory class proposal

[Reinhard Müller]

Am Die, 31 Okt 2000 14:56:01 schrieb(en) Alejandro Imass:
> First I would like to point out that this is a very
> reduced model, and I think that it's serving it's
> purpose !!! The idea is to start w/ something iron
> everything out (while it's small) and then work on the
> "mega" inventory/warehouse management tool.

Ok. This is great. Let's do it this way :)
Many of my points loose their meaning then. But again
I would have some further remarks:

> > * description: I'm not sure if varchar(50) is
> > enough. I would tend to
> >   distinguish between a "short discription"
> > (varchar(50) would be ok
> >   for that) and a "long discription", which could
> > even be a blob with
> >   formatted text.
> 
> Long descriptions are part of the original spec and
> will be added to the final model. But I think that the
> long description mechanism should be a standard GNUE
> service. What I mean by this is that each biz-object
> should be able to call a method in some standard gnue
> class, and get back a long description object
> reference.

I would even go further and say that some objects need
more than one long description. Say an inventory item
needs a description to be printed on the invoice, another
description to be printed on an offer, and yet another one
to be printed on orders. And, everyone of these must exist
in several languages.

> Just a comment, One of the things I would like to
> implement in the big model, is multiple reorder
> policies (each item has a reorder type), and that the
> reorder mechanism will be very easy to change. This is
> because I have found that companies would like some
> materials to order by min, max. Others by ROP and EOQ,
> and others by a standard QTY all the time. Our final
> module should be flexible enough to handle this.

I agree on this. Another reorder policy (and a very important one IMO) is
the "order only on special demand" :)

> > * For all things that you use varchar(12) (except
> > for the Item Number)
> >   I think varchar(8) would be sufficient. They all
> > should be only codes
> >   (so to say shortcuts), where a longer text is
> > taken from another table,
> >   like in inv_stktype.
> 
> Yes you are right. But in spanish many 8 digit codes
> are very hard to make them make sense. We can decide
> on a standard for codes (if it has not been decided
> already). I don't mind this, 8 will do OK for me.

It has not been decided, there's only the proposal of
using varchar(8) in the Module Writer's Proposal IIRC.

> there is always a calculated qty and a real physical
> qty. They are frequently different when you count your
> inventory (BTW I forgot abcType and Cycle Count
> Frequency :( ) since some material can be misplaced or
> has not been keyed into the system at that particular
> moment. The idea is that inventory can be counted and
> cntQty be filled in without worring how many the
> system says you should have. Then you run a report and
> work on the differences. This all has to do with ABC
> distribution, which by the way will be supported by
> both methods value and rotation.

Ok. This works for the "small" system. Please remind me
to talk again about inventory counting when we start the
"big" model :). I don't want to bother you now with my
ideas.

> > * From your diagram it's not clear if locationID is
> > a part of the PK of
> >   inv_warehouseloc. IMHO it should not be.
> > 
> 
> AHA !!!! Someone noticed this !!!! Cool !!!
> 
> 
> This is a very hot topic and here is my answer and I
> would like your opinion. You see this comes from the
> warehouse management experiences I've had in very
> large corporations. I've noticed that the best
> warehouse management packages us the location as the
> primary w/out caring what it has inside (it sound
> weird but it's true). You see, managing very large
> warehouses has nothing to do w/ inventory management
> (or very little). Warehouse people do not care really
> about the material but care a lot more on the
> logistics to recieve, store and dispatch.
> 
> 
> This is precisely why I've alway made the distinction
> between Inventory (which includes, costs, planning,
> purchasing, etc...) and Warehouse (which deals w/
> locations, pciking tickets, boxes, etc..). They are
> two separate businesses. And we should address the
> needs of both these customers, and give each one their
> point of view.

So we agree that LocationID should not be a primary key
in a Inventory module, but it could be in a Warehousing
module?

Thanks again,
--
Reinhard Müller
GNU Enterprise
address@hidden
www.gnue.org