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
