Re: Otros Asuntos de Inventario

[Alejandro Imass]

--- Georg Lehner <address@hidden> wrote:
> Hello Alejandro!
> 
> while my other mail still has not gone out of the
> server, I have two
> other points to discuss which arose today while I
> was explaining to
> Aldo how inventory works.
> 
> When we came to Lote's y Fecha vencimiento (I just
> do not remember the
> english term), he noticed, that maybe in the article
> data could also
> be a field for garanty time.
> 

cool.

> If we expand inventory to asset inventory than we
> could schedule
> maintainence tasks differently depending on wether
> the part is in- or
> out of garanty for example.
> 

many of the fucntions in the spec are
maintenance-biased. There is an inv-reserve field for
approved workorders or maintenance plans
(deterministic demand).

> The second problem is with Equivalence/Part List,
> etc.
> 
> Take the example of the medicaments. Health ministry
> maintains a list
> of "generic" medicaments, which HAS to be supplied
> gratis to the
> affiliates of the public health insurance. The
> hospital buys comercial
> products from different brands. We have to establish
> a relationship
> between medicaments which are equivalente to the
> generic
> article. Other example is, that we have to group
> psycofarmas,
> analgesics, antiinflamatories, etc. etc. for our
> consume-report.
> 
> 

the equivalent parts is in the model. perhaps it
should be enhanced. As soon as I have aconcrete model
we should discuss proof-of-concept scenarios and see
if the model will hold up.

> In another context It arose to me, that maintaining
> inventory parts is
> somehow equivalent to patient records (expedientes,
> ya encontré la
> palabra correcta!), yet I told you in the other
> email.
> 

Este punto realmente no lo comprendo. Quizas me lo
puedes describir mejor en nuestro idioma?

 
> Now it arises to me, that also maintaining personal
> data - which is
> the other half of the patient records, and - by the
> way - also of
> Vendor and Buyer databases - has a lot of similarity
> to inventory
> parts.
> 
> 
> Just substitute the article with the person, you
> need "serial numbers"
> to identify, but of course some "article code" could
> be the insurance
> number, which is NOT unique, as e.g. the children of
> that person
> receive also health care via her/his insurance.
> 
> So let's say, that
>       - assembled parts (part list, operations set's for
>         surgery, ...),
>       - persons and their familiar relations,
>       - and articles with a lot of imaginable kinds of
> similarities
> 
> are maintained via the master inventory system.
> 
> We have three kinds of realtion types which somehow
> subset on to
> another, but are distinct in their primary usage.
> 
> - Nested dependency lists with weights. In this case
> the weight is the
> number of parts for each list member. Node to many
> leaves relation.
> 
> 
> - Genealogic trees, where on child always has one
> natural father and
> one natural mother (with exepcion of Jesus): Leaf to
> 2 (two) nodes
> relation.
> 
> - Named indexes to form subsets of the whole set. n
> to n relations
> without hierarchy. This can be folded into 1 to n
> relations of meta
> objects.
> 
 do you think we could generalize this, into a
part-type so it can be used by all sorts of
industries? 
> 
> A simplicistic approach to generalize this is
> mapping to Part Lists:
> 
> - Bill of materials, well, hmm ... Part lists!
> 
> - Partlist of children of one person (we should
> introduce the field
> "gender" to our article description), but it costs a
> lot find out the
> parents of a child. However this has to been done
> also sometimes in
> production managment, where we want to know in which
> equipments
> appears a single part.
> 
> - Use of Partlists which are the equivalence
> category, using 0-weights
> for the items. Same problem es for genealogic trees.
> 
> Ok, what to do?
>

I see that you have some specific needs to address
ASAP. Why don't you send me a structured document with
all this. It's kind-a-hard to grasp all this in a
mail.


> 
> What I am also seeing with all this is, that we can
> get a totally
> fiddeld up Master Inventory. So it comes to my mind,
> that we could see
> master inventory like a class system (I'm virtually
> null with OO) that
> allows us to have a basic foundation which manages
> objects (articles)
> with or without "existence", locations (storeroms,
> shelfs and bins)
> their levels and level fluctuacions inside
> locations, weights
> (volumes, costs, prices), and clases of relations.
> 
> The instances of this class would become the parts
> and supply-chain
> support, Inventory of the firms equipment, Pacient
> records, a document
> managment system, Directory of natural and juridical
> persons,
> etc. etc.
> 
> See it? Is it?
> 
> Ciao,
> 
>       Jorge-León
> 
> 

Cool. I agree that Inventory should extend it's
definition to model just about anything we can "store"
or "manage" in any way. We should "objectize" in a way
that the same inventory structure can offer the user
different views (different screens) depending on the
"type" of inventory item he is managing.

For example a user is handling "equipment" type
inventory items and many "item - type" fields would
not make sense, so the screens should be rearranged
according to the type of inventory. In fact , the
system should be customizable, it should have a screen
cloning capability, and that each clone can extend
methods and attributes to handleany specific business.
People would be able to "donate" their customized
models to fit pharma, or any other vertical.


All for now.

Saludos,
Alejandro

 
> 
> 
> 
> 


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