Re: Inventory class proposal

[Alejandro Imass]

Thank you for your comments.
Here is a short response. More details when I submit
the spec description.

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.


--- Reinhard_Müller <address@hidden>
wrote:
> Alejandro,
> 
> Sorry for the late response. I have some additional
> proposals to the
> class diagram you sent a few days ago:
> 
> * ItemNum: varchar(12) is too short IMO. Many
> companies I know have
>   Item Numbers with 15 digits or more. I think
> varchar(20) would be
>   appropriate.

Yes. It varies very much from company to company.
Perhaps, each GNUE class should all share a common
interface that could change it's configuration. For
example there should be a change column length method,
and the object should back-up, drop, recreate, and
import automatically. This is standard in many
"customizable" applications.

> * 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 did no include them (long desc) here because these
are the kinds of stuff that are probably thought of
but are not documented or defined yet. And also, as I
mentioned earlier this is only a proof of concept.


> * Sorry but I don't understand what stkType is.
> Could you give me an
>   example? Maybe it's because of my bad English, but
> I know there are
>   others with not much better English on the list :)

Stock, Non-Stock, Special-Order, etc.

It will be used by the reorder mechanism, which by the
way is not reflected in the model, oops!

> * Does it make sense to make
> inv_itemsuppliers.claimedLeadTimeDays with
>   fractional digits?

probably not :)

> * Stock quantity (in all flavours, like min, max,
> rop, stkQty...) is
>   a hot topic. Many companies only use integer
> quantities (like pieces),
>   and other companies need even three fractional
> digits.
>   I know that two digits are not enough, because my
> current software has
>   two digits and I had to change it for some of my
> customers :)


Yes I thought about 3 digits but I wanted to keep it
simple. Anyway, it should be customizeable.

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.


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

> * I don't understand the difference between stkQty
> and cntQty in
>   inv_warehouseloc.

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.

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

BTW Distribution would be another component to Supply
Chain, which would start at a warehouse (the box is
packed and shipped at the warehouse) and ends either
at  a final customer, or at another warehouse. This
will deal w/things like cross-docking, etc...

This has not even been defined yet and I know some
people on this list have proposals for this. I have my
own, but I'm sure that many other people would have a
better model.


> However, thank you very very much for being the
> first one submitting
> a real tangible module proposal. I'm very much
> looking forward to the
> details we will get in SGML.
> 
> --
> Reinhard Müller
> GNU Enterprise
> address@hidden
> www.gnue.org
> 
> 
> _______________________________________________
> Gnue mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnue


__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.com/