Serialized Inventory

[cjhowe]

I've been digging pretty hard into the inventory stuff
to get my rental stuff to work and I keep running into
a wall and I think this is why...


Serialied and Non-Serialized are IMO not Inventory
Types, they are the different states of a single
indicator (isSerialized) which itself is redundant
upon the existance (or null) of a serial number.  The
more flexible inventory types would be, fixed asset,
inventory, supplies and would flow much easier with
the accounting and allow the movement of these items
to be controlled regardless of inventory type by the
various services that ship and transfer.  Any feedback?

[Hans Bakker]

Hi Chris,

i have read your and davids discussion on this subject.
Inventory for rental items is currently organized on the fixed asset where the
number of rental items available can be maintained on a date level together
with a maximum per time period.

You want to connect this with the inventory of products and be able to order
products when there are not enough fixed assets to rent.

The problem here is the availability by date. This is only done on the fixed
asset level but not in the product inventory. Is perhaps the movement between
inventory items and fixed assets an option? That means some items are for
rental (= fixed asset) and same are for sale (inventory)

You could also consider when a rental request is made and there are no rental
items available, that a 'sale' request is made from inventory to the fixed
asset? Then if inventory is not enough, a purchase order can be generated.

please let me know what you think.


Regards,
Hans Bakker
ANT Websystems Co.,Ltd (http://www.antwebsystems.com)

If you want to verify that this message really originates from
from the above person, download the public key from:
http://www.antwebsystems.com/hbakkerAntwebsystems.asc


On Wednesday 27 September 2006 08:29, Chris Howe wrote:

> I've been digging pretty hard into the inventory stuff
> to get my rental stuff to work and I keep running into
> a wall and I think this is why...
>
>
> Serialied and Non-Serialized are IMO not Inventory
> Types, they are the different states of a single
> indicator (isSerialized) which itself is redundant
> upon the existance (or null) of a serial number.  The
> more flexible inventory types would be, fixed asset,
> inventory, supplies and would flow much easier with
> the accounting and allow the movement of these items
> to be controlled regardless of inventory type by the
> various services that ship and transfer.  Any feedback?

--

[cjhowe]

Thank you very much for your interest Hans, I would
greatly appreciate any additional feedback you have
for this as I'm keenly aware of your efforts in the
rental functionality.

Comments inline

--- Hans Bakker <[hidden email]> wrote:

> Hi Chris,
>
> i have read your and davids discussion on this
> subject.
> Inventory for rental items is currently organized on
> the fixed asset where the
> number of rental items available can be maintained
> on a date level together
> with a maximum per time period.
>
> You want to connect this with the inventory of
> products and be able to order
> products when there are not enough fixed assets to
> rent.
>

Not only be concerned about low/no inventory levels,
but these rental agreements are open ended. While I
like the calendar approach for the hotel industry, it
has no benefit over what a status change datetime does
in my industry.  For maximum time period dependent
transactions calendars are indeed the way to go.

> The problem here is the availability by date. This
> is only done on the fixed
> asset level but not in the product inventory.

The InventoryItem.statusId field is essentially a
denormalized field to show the most recent
InventoryStatus.statusId.  So availability is pretty
straight forward for my implementation by basing it on
status.  As far as handling the hotel scenario
consistantly with my small item rental scenario, I
think an indicator or additional InventoryItemType
would work well.

> Is
> perhaps the movement between
> inventory items and fixed assets an option? That
> means some items are for
> rental (= fixed asset) and same are for sale
> (inventory)
>

The problem I have with this approach is that all of
the great and wonderful (and ever changing) services
that regulate the movement and location of
InventoryItems end up being duplicated to work with
with FixedAssets.  These will no doubt end up out of
sync and events will be inconsistant due to the update
of one set of services and not the other.  This is
really unncessesary as there is no difference in the
shipment or transfer of a rental item from a sale
item.  The rental item is simply more likely to be
returned.

The other issue I have with FixedAssets being
manipulated for Order fullfilment is modularization.
Since the FixedAsset entity is firmly an accounting
entity, rental and order fullfillment ideally "should"
be able to "work" without the accounting component
even being loaded.  That can't be done if order
fullfillment is dependent on the accounting component.

> You could also consider when a rental request is
> made and there are no rental
> items available, that a 'sale' request is made from
> inventory to the fixed
> asset? Then if inventory is not enough, a purchase
> order can be generated.
>
> please let me know what you think.
>
>

I have no doubt that that could work, however it seems
fragile for two reasons.
One, I don't think that kind of work around would make
it back into the project so I'd be fearful that
updates would break it quite easily. And two, it's not
intuitive or acurately describing what is occuring.
So then my employer is dependent on someone knowing
the intricacies of what should be a common service.
Which is great for the demand of my services, but
coding for inventory management isn't interesting work
for me :)

Thanks Hans!


> Regards,
> Hans Bakker
> ANT Websystems Co.,Ltd
> (http://www.antwebsystems.com)
>
> If you want to verify that this message really
> originates from
> from the above person, download the public key from:
>
http://www.antwebsystems.com/hbakkerAntwebsystems.asc
>
>