On Sep 18, 2006, at 4:35 AM, Chris Howe wrote:
--- David E Jones <[EMAIL PROTECTED]>
wrote:
Is there a reason why this wouldn't work or that you
wouldn't want to
use what is already implemented?
The way that rental is currently implemented utilzes
the manufacturing concept of production capacity to
show availability.
Hans Bakker actually implemented the rental stuff so he knows the
details better, but to my knowledge the rental stuff does not use the
manufacturing functionality at all. On a lower level the rental and
manufacturing stuff use similar structures, like the FixedAsset and
WorkEffort entities, but related in different ways, and related to
the Product entity for representing the sale in different ways. All
you should have to do if you add capacity you just add FixedAsset
records with a clear schedule... pretty simple.
What are you seeing that looks like the rental stuff is using the
manufacturing stuff?
This is a fine way to think about
it if your "production capacity" is fixed. However,
when renting items (especially of low value) you are
constantly replenishing your stock. The processes
that calculate serialized inventory appear to do a
much better job of handling product availability.
Where it's simply updating the status of the inventory
item from "Available" to "Delivered" to "Available".
For my use rental of these items only differ from the
sale of serialized product in how you're charging the
customer and that it will be returned (the return date
is unknown). So if that's the only difference, why
handle it so radically different?
I think there are quite a few more differences than that... The
information about a rental versus sale and return of inventory is
very different and I really wouldn't want to see a bunch of rental
specific fields added to the InventoryItem, which is already complex.
I really highly recommend looking into the existing rental stuff more
and identify the specific places where the functionality is similar
to and different from what you need. I might be making a bad
assumption, but I've seen a lot of people go through this and it's
easy to try to make what you are familiar with fit into a new need
rather than going through the time and effort required to research a
new part of the existing functionality.
-David
