Question About Fixed Assets

[Adrian Crum]

Fixed Assets has the ability to maintain meter readings for the asset.
However, those meter readings can't be accessed without creating a fixed
asset maintenance.

It seems to me the meter readings link should be in the Fixed Asset sub
navigation along with Identifications, Registrations, etc.

What do you think?

-Adrian

[Adrian Crum]

Looking at this more, I don't see why anyone would even use the Meters
data the way it is set up now. It's kinda useless.

If I want to maintain meter readings on a fixed asset, I should not have
to create a fixed asset maintenance. I might want to log the copy count
on a copier, or hours used on a projector. I should be able to keep a
log of meter readings outside of creating maintenances.

On the other hand, a meter reading might trigger the creation of a fixed
asset maintenance - if that meter reading crosses a maintenance threshold.

If no one objects, I'd like to refactor the meter reading code and data
a little bit to make it more usable.

-Adrian

Adrian Crum wrote:

> Fixed Assets has the ability to maintain meter readings for the asset.
> However, those meter readings can't be accessed without creating a fixed
> asset maintenance.
>
> It seems to me the meter readings link should be in the Fixed Asset sub
> navigation along with Identifications, Registrations, etc.
>
> What do you think?
>
> -Adrian
>

[Anil Patel-3]

Idea is, Recording a meter reading that can be used for anything to do  
with maintaining asset requires schedule information. We have  
successfully used it as is and works great.

Regards
Anil  Patel

On Jun 24, 2008, at 6:42 PM, Adrian Crum wrote:

> Looking at this more, I don't see why anyone would even use the  
> Meters data the way it is set up now. It's kinda useless.
>
> If I want to maintain meter readings on a fixed asset, I should not  
> have to create a fixed asset maintenance. I might want to log the  
> copy count on a copier, or hours used on a projector. I should be  
> able to keep a log of meter readings outside of creating maintenances.
>
> On the other hand, a meter reading might trigger the creation of a  
> fixed asset maintenance - if that meter reading crosses a  
> maintenance threshold.
>
> If no one objects, I'd like to refactor the meter reading code and  
> data a little bit to make it more usable.
>
> -Adrian
>
> Adrian Crum wrote:
>> Fixed Assets has the ability to maintain meter readings for the  
>> asset. However, those meter readings can't be accessed without  
>> creating a fixed asset maintenance.
>> It seems to me the meter readings link should be in the Fixed Asset  
>> sub navigation along with Identifications, Registrations, etc.
>> What do you think?
>> -Adrian

[David E Jones]

On Jun 24, 2008, at 4:42 PM, Adrian Crum wrote:

> Looking at this more, I don't see why anyone would even use the  
> Meters data the way it is set up now. It's kinda useless.

Wow, aren't we in a friendly mood...

> If I want to maintain meter readings on a fixed asset, I should not  
> have to create a fixed asset maintenance. I might want to log the  
> copy count on a copier, or hours used on a projector. I should be  
> able to keep a log of meter readings outside of creating maintenances.
>
> On the other hand, a meter reading might trigger the creation of a  
> fixed asset maintenance - if that meter reading crosses a  
> maintenance threshold.
>
> If no one objects, I'd like to refactor the meter reading code and  
> data a little bit to make it more usable.

Is this a declaration that you're giving up on seeking to understand  
before you seek to be understood?

Either way, I look forward to hearing your thoughts on specific  
improvements.

You are correct that there is place to record an arbitrary meter  
reading... but from a business process perspective what would that  
actually be used for? When and why would that data be entered into the  
system?

-David


> Adrian Crum wrote:
>> Fixed Assets has the ability to maintain meter readings for the  
>> asset. However, those meter readings can't be accessed without  
>> creating a fixed asset maintenance.
>> It seems to me the meter readings link should be in the Fixed Asset  
>> sub navigation along with Identifications, Registrations, etc.
>> What do you think?
>> -Adrian

[Adrian Crum]

David E Jones wrote:
>
> On Jun 24, 2008, at 4:42 PM, Adrian Crum wrote:
>
>> Looking at this more, I don't see why anyone would even use the Meters
>> data the way it is set up now. It's kinda useless.
>
> Wow, aren't we in a friendly mood...

Sorry. I didn't mean to come across that way. My apologies to Anil as well.

>> If I want to maintain meter readings on a fixed asset, I should not
>> have to create a fixed asset maintenance. I might want to log the copy
>> count on a copier, or hours used on a projector. I should be able to
>> keep a log of meter readings outside of creating maintenances.
>>
>> On the other hand, a meter reading might trigger the creation of a
>> fixed asset maintenance - if that meter reading crosses a maintenance
>> threshold.
>>
>> If no one objects, I'd like to refactor the meter reading code and
>> data a little bit to make it more usable.
>
> Is this a declaration that you're giving up on seeking to understand
> before you seek to be understood?
>
> Either way, I look forward to hearing your thoughts on specific
> improvements.
>
> You are correct that there is place to record an arbitrary meter
> reading... but from a business process perspective what would that
> actually be used for? When and why would that data be entered into the
> system?

A lathe operator records a meter reading after a production run. A
delivery driver records an odometer reading at the end of the day. An
office assistant records the copy count of a copier. I could go on...

Each meter reading could be entered without the need to create a
maintenance. In addition (as I mentioned earlier) those meter readings
could trigger the creation of a maintenance - when they cross a
maintenance threshold.

Again, I apologize for coming across so negatively.

-Adrian

[David E Jones]

On Jun 25, 2008, at 8:30 AM, Adrian Crum wrote:

>>> If I want to maintain meter readings on a fixed asset, I should  
>>> not have to create a fixed asset maintenance. I might want to log  
>>> the copy count on a copier, or hours used on a projector. I should  
>>> be able to keep a log of meter readings outside of creating  
>>> maintenances.
>>>
>>> On the other hand, a meter reading might trigger the creation of a  
>>> fixed asset maintenance - if that meter reading crosses a  
>>> maintenance threshold.
>>>
>>> If no one objects, I'd like to refactor the meter reading code and  
>>> data a little bit to make it more usable.
>> Is this a declaration that you're giving up on seeking to  
>> understand before you seek to be understood?
>> Either way, I look forward to hearing your thoughts on specific  
>> improvements.
>> You are correct that there is place to record an arbitrary meter  
>> reading... but from a business process perspective what would that  
>> actually be used for? When and why would that data be entered into  
>> the system?
>
> A lathe operator records a meter reading after a production run. A  
> delivery driver records an odometer reading at the end of the day.  
> An office assistant records the copy count of a copier. I could go  
> on...
>
> Each meter reading could be entered without the need to create a  
> maintenance. In addition (as I mentioned earlier) those meter  
> readings could trigger the creation of a maintenance - when they  
> cross a maintenance threshold.

When I was working with Anil on original requirements for this they  
didn't do arbitrary meter readings, they just wanted reports of the  
meter readings to look for when maintenance would be needed next and  
such (ie read/check the meters, but there was no need to record them  
except along with maintenance done, so they would know when the next  
maintenance needed to be done, etc).

The main reason I was thinking of where meter readings would be  
valuable is in manufacturing. You actually need that sometimes to  
determine the cost of operation the machine and associating it with  
the cost of goods produced, or at least keep track of how much the  
machine is used for different types of products, etc.

Anyway, the entity would be really simple, a lot like  
FixedAssetMaintMeter, but with a few differences, something like:

FixedAssetMeterReading
fixedAssetId*
productMeterTypeId*
readingDate*
readingReasonEnumId (could be optional; use begin reading, use end  
reading, calendar/scheduled reading, etc)
meterValue
workEffortId (if the reading was done before or after a certain work  
effort)

-David

[Adrian Crum]

David E Jones wrote:

> When I was working with Anil on original requirements for this they
> didn't do arbitrary meter readings, they just wanted reports of the
> meter readings to look for when maintenance would be needed next and
> such (ie read/check the meters, but there was no need to record them
> except along with maintenance done, so they would know when the next
> maintenance needed to be done, etc).
>
> The main reason I was thinking of where meter readings would be valuable
> is in manufacturing. You actually need that sometimes to determine the
> cost of operation the machine and associating it with the cost of goods
> produced, or at least keep track of how much the machine is used for
> different types of products, etc.
>
> Anyway, the entity would be really simple, a lot like
> FixedAssetMaintMeter, but with a few differences, something like:
>
> FixedAssetMeterReading
> fixedAssetId*
> productMeterTypeId*
> readingDate*
> readingReasonEnumId (could be optional; use begin reading, use end
> reading, calendar/scheduled reading, etc)
> meterValue
> workEffortId (if the reading was done before or after a certain work
> effort)

Why not add those fields to the existing entity? I did something similar
in the patch I just uploaded to Jira.

Where I work we have thousands of fixed assets that require maintenance.
Our maintenance department consists of a supervisor, four full time
maintenance workers, and some production workers who are used part time
(they wear two hats).

What we need from a fixed asset maintenance program is the ability to
set up recurring maintenances, and have them automatically assigned to
the appropriate personnel. I picture two triggers for that - timed
intervals (recurrence entries) and meter readings.

Doing meter readings after the maintenance is done is not useful here.
Our maintenance staff is very busy - they need the program to tell them
when maintenance is due.

-Adrian

[David E Jones]

On Jun 25, 2008, at 12:27 PM, Adrian Crum wrote:

> David E Jones wrote:
>> When I was working with Anil on original requirements for this they  
>> didn't do arbitrary meter readings, they just wanted reports of the  
>> meter readings to look for when maintenance would be needed next  
>> and such (ie read/check the meters, but there was no need to record  
>> them except along with maintenance done, so they would know when  
>> the next maintenance needed to be done, etc).
>> The main reason I was thinking of where meter readings would be  
>> valuable is in manufacturing. You actually need that sometimes to  
>> determine the cost of operation the machine and associating it with  
>> the cost of goods produced, or at least keep track of how much the  
>> machine is used for different types of products, etc.
>> Anyway, the entity would be really simple, a lot like  
>> FixedAssetMaintMeter, but with a few differences, something like:
>> FixedAssetMeterReading
>> fixedAssetId*
>> productMeterTypeId*
>> readingDate*
>> readingReasonEnumId (could be optional; use begin reading, use end  
>> reading, calendar/scheduled reading, etc)
>> meterValue
>> workEffortId (if the reading was done before or after a certain  
>> work effort)
>
> Why not add those fields to the existing entity? I did something  
> similar in the patch I just uploaded to Jira.
>
> Where I work we have thousands of fixed assets that require  
> maintenance. Our maintenance department consists of a supervisor,  
> four full time maintenance workers, and some production workers who  
> are used part time (they wear two hats).
>
> What we need from a fixed asset maintenance program is the ability  
> to set up recurring maintenances, and have them automatically  
> assigned to the appropriate personnel. I picture two triggers for  
> that - timed intervals (recurrence entries) and meter readings.
>
> Doing meter readings after the maintenance is done is not useful  
> here. Our maintenance staff is very busy - they need the program to  
> tell them when maintenance is due.

It sounds like the most important entities would be these then:

FixedAsset -> Product (FixedAsset is an instance of a Product)
ProductMaint (when maintenance is needed for the Product, ie each  
FixedAsset that is an instance of the Product)
FixedAssetMaint (history of maintenance)

With the ProductMaint records you can see what needs to done for the  
FixedAsset, and with the FixedAssetMaint you can look at what has been  
done and the meter readings on when it was done to determine the meter  
readings of when it will be done.

With those you can actually create a report that says when each asset  
needs maintenance next based on their previous maintenance history.

Without the maintenance history and the meter reading associated with  
maintenance, how would the system know when maintenance is needed next?

With this stuff in place, then the question is do you want the system  
to tell you when maintenance will be needed for each asset, or do you  
want to enter meter readings all the time and have an alert or email  
pop out of the system to tell you that maintenance will be needed  
soon? It's that second bit that isn't necessary, ie entering meter  
readings over and over just so one day the system can tell you that  
15003 is greater than 15000... hence the simpler approach of just  
using a report that tells you when maintenance will be needed and  
people can keep an eye on it (like the ubiquitous window sticker for  
your next oil change). Wouldn't that be less work for the maint folks?

That's why I commented that outside of meter readings for maintenance  
(which is vital for maintenance management) the main other vital use  
might be for tracking cost of equipment use for manufacturing or  
something.

Either way, I highly recommend doing some analysis and design for your  
organization BEFORE trying to implement anything. And once you do look  
at implementing something, start by first understand what exists in  
the system and how you might use it, and then if you find anything  
insufficient for your needs try to think of a way to make it generic  
and reusable so that the next group who comes along has a better  
chance of being able to reuse it, and others in the community have a  
better chance of wanting to discuss it and get involved in it.

BTW, whenever we deprecate an entity in OFBiz there are certain things  
that now MUST be done or all committers should reject the patch:

1. rename the entity to deprecate by adding an "Old" prefix to it,  
then specify a table-name attribute on the entity so it still points  
to the same table in the database

2. create a new entity the replaces the old one, and comment on that  
fact

3. implement a service to move data from the old/deprecated entity to  
the new one

You'll see this pattern used in a few places. This is kind of the way  
that users in general have some sort of hope of being able to update  
from one revision of OFBiz to another.

Sorry for being the data model nazi, but of all that exists in OFBiz  
those have the greatest influence on how clean the code base is over  
time and how easy updates are, and so on. Most problems in enterprise  
systems stem from bad and inflexible data modeling practices.

It makes me tempted to open a vote for a policy of a 1 week waiting  
period after a proposal on the mailing list for all data model  
changes... these are not good things to be hasty about!

-David

[Adrian Crum]

David,

Thank you very much for the detailed reply! Now things are FINALLY
starting to make sense.

Comments inline...

David E Jones wrote:

> It sounds like the most important entities would be these then:
>
> FixedAsset -> Product (FixedAsset is an instance of a Product)
> ProductMaint (when maintenance is needed for the Product, ie each
> FixedAsset that is an instance of the Product)
> FixedAssetMaint (history of maintenance)
>
> With the ProductMaint records you can see what needs to done for the
> FixedAsset, and with the FixedAssetMaint you can look at what has been
> done and the meter readings on when it was done to determine the meter
> readings of when it will be done.
>
> With those you can actually create a report that says when each asset
> needs maintenance next based on their previous maintenance history.

This is where my confusion came in. It seemed to me that that
FixedAssetMaint was intended to fulfill the role of ProductMaint. It
wasn't clear to me what ProductMaint was used for.

> Without the maintenance history and the meter reading associated with
> maintenance, how would the system know when maintenance is needed next?

I was picturing a "next maintenance due" field, but now that you've
explained things better, I can see that it can be calculated from
existing data.

> With this stuff in place, then the question is do you want the system to
> tell you when maintenance will be needed for each asset, or do you want
> to enter meter readings all the time and have an alert or email pop out
> of the system to tell you that maintenance will be needed soon? It's
> that second bit that isn't necessary, ie entering meter readings over
> and over just so one day the system can tell you that 15003 is greater
> than 15000... hence the simpler approach of just using a report that
> tells you when maintenance will be needed and people can keep an eye on
> it (like the ubiquitous window sticker for your next oil change).
> Wouldn't that be less work for the maint folks?

Well... that would work fine if the maintenance folks were the ones
actually using the fixed asset. In our case, the oil change sticker
isn't in the maintenance worker's car, it's on a piece of equipment he
never sees until it needs to be fixed.

> That's why I commented that outside of meter readings for maintenance
> (which is vital for maintenance management) the main other vital use
> might be for tracking cost of equipment use for manufacturing or something.

I was thinking a single entity would provide a comprehensive meter
history of a fixed asset. If you think two entities are needed, that's fine.

It would be helpful for our maintenance workers to see all meter
readings and their purpose - to help them spot trends (production run X
seems to result in a breakdown of component Y), so I'll just have to get
that information from two sources instead of one.

> Either way, I highly recommend doing some analysis and design for your
> organization BEFORE trying to implement anything.

It bugs me when you talk down to me like that. I have a very clear
understanding of what our organization needs. What I'm struggling with
is figuring out how to get OFBiz to meet those needs.

I understand this thread got off to a rocky start, but once apologies
are made, it helps move things along better if respondents reply with
clear instructions - like the ones you just provided.

-Adrian

[Jacques Le Roux]

From: "David E Jones" <[hidden email]>
[...big snip...]

> BTW, whenever we deprecate an entity in OFBiz there are certain things  that now MUST be done or all committers should reject the
> patch:
>
> 1. rename the entity to deprecate by adding an "Old" prefix to it,  then specify a table-name attribute on the entity so it still
> points  to the same table in the database
>
> 2. create a new entity the replaces the old one, and comment on that  fact
>
> 3. implement a service to move data from the old/deprecated entity to  the new one
>
> You'll see this pattern used in a few places. This is kind of the way  that users in general have some sort of hope of being able
> to update  from one revision of OFBiz to another.
>
> -David

I will at least put these very important informations in the FAQ. But finally should not those kind of stuff being put in our Best
Practices ?

Jacques

[Jacques Le Roux]

Done : http://docs.ofbiz.org/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-Developmenttips
Which leads to
http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Contributors+Best+Practices#OFBizContributorsBestPractices-DeprecatingEntities

Jacques

From: "Jacques Le Roux" <[hidden email]>

> From: "David E Jones" <[hidden email]>
> [...big snip...]
>> BTW, whenever we deprecate an entity in OFBiz there are certain things  that now MUST be done or all committers should reject the
>> patch:
>>
>> 1. rename the entity to deprecate by adding an "Old" prefix to it,  then specify a table-name attribute on the entity so it still
>> points  to the same table in the database
>>
>> 2. create a new entity the replaces the old one, and comment on that  fact
>>
>> 3. implement a service to move data from the old/deprecated entity to  the new one
>>
>> You'll see this pattern used in a few places. This is kind of the way  that users in general have some sort of hope of being able
>> to update  from one revision of OFBiz to another.
>>
>> -David
>
> I will at least put these very important informations in the FAQ. But finally should not those kind of stuff being put in our Best
> Practices ?
>
> Jacques
>
>

[David E Jones]

Thanks Jacques. I could have sworn we had this documented somewhere,  
but I really don't remember where...

-David


On Jun 26, 2008, at 2:29 AM, Jacques Le Roux wrote:

> Done : http://docs.ofbiz.org/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-Developmenttips
> Which leads to http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Contributors+Best+Practices#OFBizContributorsBestPractices-DeprecatingEntities
>
> Jacques
>
> From: "Jacques Le Roux" <[hidden email]>
>> From: "David E Jones" <[hidden email]>
>> [...big snip...]
>>> BTW, whenever we deprecate an entity in OFBiz there are certain  
>>> things  that now MUST be done or all committers should reject the  
>>> patch:
>>>
>>> 1. rename the entity to deprecate by adding an "Old" prefix to  
>>> it,  then specify a table-name attribute on the entity so it still  
>>> points  to the same table in the database
>>>
>>> 2. create a new entity the replaces the old one, and comment on  
>>> that  fact
>>>
>>> 3. implement a service to move data from the old/deprecated entity  
>>> to  the new one
>>>
>>> You'll see this pattern used in a few places. This is kind of the  
>>> way  that users in general have some sort of hope of being able to  
>>> update  from one revision of OFBiz to another.
>>>
>>> -David
>>
>> I will at least put these very important informations in the FAQ.  
>> But finally should not those kind of stuff being put in our Best  
>> Practices ?
>>
>> Jacques
>>
>