You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Adrian Crum <ad...@hlmksw.com> on 2008/06/24 21:44:32 UTC
Question About Fixed Assets
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
Re: Question About Fixed Assets
Posted by Anil Patel <an...@hotwaxmedia.com>.
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
Re: Question About Fixed Assets
Posted by Adrian Crum <ad...@hlmksw.com>.
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
Re: Question About Fixed Assets
Posted by David E Jones <jo...@hotwaxmedia.com>.
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" <ja...@les7arts.com>
>> From: "David E Jones" <jo...@hotwaxmedia.com>
>> [...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
>>
>
Re: Question About Fixed Assets
Posted by Jacques Le Roux <ja...@les7arts.com>.
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" <ja...@les7arts.com>
> From: "David E Jones" <jo...@hotwaxmedia.com>
> [...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
>
>
Re: Question About Fixed Assets
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "David E Jones" <jo...@hotwaxmedia.com>
[...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
Re: Question About Fixed Assets
Posted by David E Jones <jo...@hotwaxmedia.com>.
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
Re: Question About Fixed Assets
Posted by Adrian Crum <ad...@hlmksw.com>.
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
Re: Question About Fixed Assets
Posted by David E Jones <jo...@hotwaxmedia.com>.
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
Re: Question About Fixed Assets
Posted by Adrian Crum <ad...@hlmksw.com>.
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
Re: Question About Fixed Assets
Posted by David E Jones <jo...@hotwaxmedia.com>.
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
Re: Question About Fixed Assets
Posted by Adrian Crum <ad...@hlmksw.com>.
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
>