[
https://issues.apache.org/jira/browse/OFBIZ-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608139#action_12608139
]
David E. Jones commented on OFBIZ-1851:
---------------------------------------
Yeah, I object a bit. I don't like the idea of killing the FixedAssetMaintMeter
entity as its role in the maintenance stuff is pretty important and this change
makes certain things difficult (or impossible?) like determining when the next
maintenance is needed.
I'd prefer to see an additional entity for general purpose readings, like this:
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)
I think it is different enough from the MaintMeter entity to justify a separate
one. There are also legacy and existing code reasons to keep them distinct.
However we model it, there is a need to have one or more meter readings
associated with a maintenance, and having a tighter data model for that is
helpful.
Even if we combined them, we should key off the readingDate and not the
meterValue. I think I see your reason for using the meterValue (it _should_
always be changing), but it might not change while time always will. For
periodic readings if the asset was not used it would be the same.
> Sandbox: Fixed Asset Meter Reading Improvement
> ----------------------------------------------
>
> Key: OFBIZ-1851
> URL: https://issues.apache.org/jira/browse/OFBIZ-1851
> Project: OFBiz
> Issue Type: Improvement
> Components: accounting
> Reporter: Adrian Crum
> Priority: Minor
> Attachments: meter_reading.patch
>
>
> The current fixed asset meter reading logic is set up to only allow a meter
> reading when a fixed asset maintenance is created. This improvement would
> remove that requirement and make the connection to a maintenance optional.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
