Expand Good Idnetification

[cjhowe]

As there are several different kinds of id values for
reasons outsides of product identification and some of
those values need to be used by different entities I
would like to propose and get a bit of feedback on
expanding on the good identification model.

1) Identification entity
    a)identificationId
    b)identTypeId
    c)idValue
2) IdentificationType
    a)identTypeId
    b)description
    c)parentTypeId
    d)hasTable
3) ProductIdentification (was GoodIdentification)
    a)productId
    b)identificationId
    c)productIdentTypeId
4) ProductIdentType (was GoodIdentificationType)
    a)productIdentTypeId
    b)description
    c)parentTypeId
    d)hasTable

The following is my need for it
5) InventItemIdent
    a)identificationId
    b)inventoryItemId
    c)inventItemIdentTypeId
6) InventItemIdentType
    a)InventItemIdentTypeId
    b)description
    c)parentTypeId
    d)hasTable
7) FixedAssetIdent
    a)fixedAssetId
    b)identificationId
    c)fixedAssetIdentTypeId
8) FixedAssetIdentType
    a)fixedAssetIdentTypeId
    b)description
    c)parentTypeId
    d)hasTable

This is the easiest solution that I can come up with
for allowing rental of fixed assets that end up in
inventory from PO (think Rent-A-Center style).  The
use of "production capacity" for rental to demonstrate
quantity on hand that OpenSourceTravel uses doesn't
mesh well in my mind for renting of items that leave
the company's physical possession.

There would probably also be a FixedAssetInventoryItem
entity to accomplish this but at the moment I'm
concerned about the duplication/ability to go out of
sync of the serialized inventory that's
assigned/recorded at receiving a shipment and the
rerecording of those idValues for the fixed asset.

Any Feedback on this would be much appreciated!!

[David E Jones-2]

On Sep 16, 2006, at 8:54 AM, Chris Howe wrote:

> There would probably also be a FixedAssetInventoryItem
> entity to accomplish this but at the moment I'm
> concerned about the duplication/ability to go out of
> sync of the serialized inventory that's
> assigned/recorded at receiving a shipment and the
> rerecording of those idValues for the fixed asset.

Generally when something is purchased it is received either as a  
FixedAsset for company use, or as an InventoryItem for resale. I  
don't think we want to lose that distinction... I think it would be  
pretty confusing for users of the system, as well as make the code a  
fair but messier.

-David

[cjhowe]

This is for product rental.  It kind of falls in
between.  It's not for company use, but it's not being
offered for sale (transfer of ownership).

Fixed Assets and Inventory are terminology for
Financial accounting in the sense and distinction that
you're making.

However, inventory has a seperate meaning in regards
to product availablity.  The InventoryItem entity in
OFBiz is a product entity, not an accounting entity.
So, the available for rental of serialized inventory
falls closer to this model.


--- David E Jones <[hidden email]>
wrote:

>
> On Sep 16, 2006, at 8:54 AM, Chris Howe wrote:
>
> > There would probably also be a
> FixedAssetInventoryItem
> > entity to accomplish this but at the moment I'm
> > concerned about the duplication/ability to go out
> of
> > sync of the serialized inventory that's
> > assigned/recorded at receiving a shipment and the
> > rerecording of those idValues for the fixed asset.
>
> Generally when something is purchased it is received
> either as a  
> FixedAsset for company use, or as an InventoryItem
> for resale. I  
> don't think we want to lose that distinction... I
> think it would be  
> pretty confusing for users of the system, as well as
> make the code a  
> fair but messier.
>
> -David
>
>
>

[David E Jones-2]

The terms Fixed Asset and Inventory Item are more that just  
accounting terms, they are also operational terms.

An Inventory Item is something to be held for sale and not used. A  
Fixed Asset is meant to be kept for long term use, either directly or  
for whatever product or service is offered by the company, including  
rental of those fixed assets.

For rental of fixed assets it doesn't make sense to put them in  
inventory, that is only for items for sale. Their availability is  
best tracked through WorkEfforts, used to track availability as well  
as events (when they are busy or in use).

Is there a reason why this wouldn't work or that you wouldn't want to  
use what is already implemented?

-David


On Sep 16, 2006, at 9:46 AM, Chris Howe wrote:

> This is for product rental.  It kind of falls in
> between.  It's not for company use, but it's not being
> offered for sale (transfer of ownership).
>
> Fixed Assets and Inventory are terminology for
> Financial accounting in the sense and distinction that
> you're making.
>
> However, inventory has a seperate meaning in regards
> to product availablity.  The InventoryItem entity in
> OFBiz is a product entity, not an accounting entity.
> So, the available for rental of serialized inventory
> falls closer to this model.
>
>
> --- David E Jones <[hidden email]>
> wrote:
>
>>
>> On Sep 16, 2006, at 8:54 AM, Chris Howe wrote:
>>
>>> There would probably also be a
>> FixedAssetInventoryItem
>>> entity to accomplish this but at the moment I'm
>>> concerned about the duplication/ability to go out
>> of
>>> sync of the serialized inventory that's
>>> assigned/recorded at receiving a shipment and the
>>> rerecording of those idValues for the fixed asset.
>>
>> Generally when something is purchased it is received
>> either as a
>> FixedAsset for company use, or as an InventoryItem
>> for resale. I
>> don't think we want to lose that distinction... I
>> think it would be
>> pretty confusing for users of the system, as well as
>> make the code a
>> fair but messier.
>>
>> -David
>>
>>
>>
>

[cjhowe]

--- David E Jones <[hidden email]>
wrote:

>
> Is there a reason why this wouldn't work or that you
> wouldn't want to  
> use what is already implemented?
>
> -David

The way that rental is currently implemented utilzes
the manufacturing concept of production capacity to
show availability.  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?

[David E Jones-2]

On Sep 18, 2006, at 4:35 AM, Chris Howe wrote:

> --- David E Jones <[hidden email]>
> 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

[cjhowe]

--- David E Jones <[hidden email]>
wrote:

> 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

Taking another close look at the rental stuff and the
inventory stuff this is what I'm seeing:
1) Product availability for the rental items is not
calculated for the inventory sections of the order
screen.
2) You can find availability for those items by
looking at it's calendar which is based on
FixedAsset.productionCapacity (production capacity is
a manufucturing use of fixed assets, not a rental use)

3) the entity InventoryItem (correctly) has no
relationship to the accounting entities.  So its name
is not reflecting the accounting "ideology" of
separation of fixed assets, supplies and inventory.
Inventory items are simply items that are in a
facility.  Could just as easily be called Item based
on it's current implementation.

4)FixedAssets is setup in a way that doesn't allow the
Facility entities to control it (by having the foreign
key in the FixedAsset entitiy).  This keeps you from
being able to transfer a fixed asset in the same
manner that you transfer items for sale.

From my POV, the only reason why the approach was
taken to not consider FixedAssets InventoryItems is
because of the shortcut taken with the
FixedAssetProduct entity.  It should have instead been
FixedAssetItem entity and then you're selling /
renting, etc only items which in reality is what
you're doing anyway as InventoryItem is already linked
to the Product entity.  Linking FixedAsset and
InventoryItem allows you to specify the location the
fixed asset as well as specifiy what productId is
representing it for sale/rent

[Daniel Kunkel]

Chris

I think there's one other big difference in how they are handled from
the accounting point of view...

Inventory value is efficiently tracked in various raw material and work
in progress, and cost of good sold accounts. The accounting is
essentially automatic since these transactions are so common.

Rental inventory is often manually tracked in the capital expenditures
and equipment sales leaving a profit or loss from sales of capital
equipment.

I see you're in the situation of very frequently selling rental
equipment... Although there hasn't been a previous demand, I actually
see value in  automating this procedure.

I'm wondering if the datamodel wouldn't be better to track company
equipment as a special type of inventory, with connections to a calendar
for rental and asset usage. This would be somewhat similar to how a
person, or company is represented as a party.

The inventory accounting system is already setup to utilize special
accounts for various inventory items.





On Wed, 2006-09-20 at 06:14 -0700, Chris Howe wrote:

>
> --- David E Jones <[hidden email]>
> wrote:
>
>
> > 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
>
> Taking another close look at the rental stuff and the
> inventory stuff this is what I'm seeing:
> 1) Product availability for the rental items is not
> calculated for the inventory sections of the order
> screen.
> 2) You can find availability for those items by
> looking at it's calendar which is based on
> FixedAsset.productionCapacity (production capacity is
> a manufucturing use of fixed assets, not a rental use)
>
> 3) the entity InventoryItem (correctly) has no
> relationship to the accounting entities.  So its name
> is not reflecting the accounting "ideology" of
> separation of fixed assets, supplies and inventory.
> Inventory items are simply items that are in a
> facility.  Could just as easily be called Item based
> on it's current implementation.
>
> 4)FixedAssets is setup in a way that doesn't allow the
> Facility entities to control it (by having the foreign
> key in the FixedAsset entitiy).  This keeps you from
> being able to transfer a fixed asset in the same
> manner that you transfer items for sale.
>
> From my POV, the only reason why the approach was
> taken to not consider FixedAssets InventoryItems is
> because of the shortcut taken with the
> FixedAssetProduct entity.  It should have instead been
> FixedAssetItem entity and then you're selling /
> renting, etc only items which in reality is what
> you're doing anyway as InventoryItem is already linked
> to the Product entity.  Linking FixedAsset and
> InventoryItem allows you to specify the location the
> fixed asset as well as specifiy what productId is
> representing it for sale/rent