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
